Producto mínimo viable (MVP): qué es y cómo crearlo

Un producto mínimo viable (MVP, del inglés minimum viable product; también PMV) es la primera versión de un producto que ya pueden usar clientes reales, con lo justo para resolver un problema y comprobar si alguien lo quiere. Sirve para aprender del mercado antes de invertir en la versión completa.

En esta guía verás de dónde viene la idea, qué tipos de MVP hay, cómo se hace uno paso a paso y cómo salieron al mercado Wallapop, Typeform o Spotahome. La escribo desde la práctica: en Do My MVP construimos MVPs con precio y plazo cerrados.

¿Qué es un producto mínimo viable?

Es la versión más pequeña de tu producto con la que puedes aprender algo cierto sobre tus clientes. Las dos palabras importan:

• Mínimo: hace una sola cosa, la que necesitas para saber si tu idea funciona. Todo lo demás espera.
• Viable: funciona de verdad. Alguien puede usarlo sin que se lo expliques y, si tu modelo lo pide, pagar.

El término lo acuñó Frank Robinson en 2001 y lo popularizaron Steve Blank y Eric Ries, que lo convirtió en la pieza central de The Lean Startup (2011) (Wikipedia). Los dos lo entendían algo distinto: para Robinson era un producto real del tamaño justo; para Ries, un experimento para aprender con el menor esfuerzo. En la práctica, un buen MVP es las dos cosas.

Lean: de la fábrica a las startups

Ries tomó la palabra lean de la fabricación ajustada (lean manufacturing), el sistema con el que Toyota organizó sus fábricas: producir solo lo que el cliente pide, eliminar todo lo que no aporta valor y mejorar en ciclos cortos (Wikipedia). El MVP es esa misma idea aplicada a un producto nuevo: no fabricar funciones que nadie ha pedido. Cómo se aplica el método completo lo explico en la guía de Lean Startup.

Trabajé desarrollando software de lean manufacturing en mlean, una plataforma de mejora continua que usan más de 500 fábricas, con clientes como Coca-Cola. Allí lo vi a diario: en una planta, producir lo que nadie ha pedido se llama desperdicio y se nota enseguida, en forma de stock acumulado en el almacén. En software no se ve, pero existe igual: semanas de trabajo en funciones que nadie usa. Por eso en Do My MVP los proyectos empiezan recortando.

¿Qué es un MVP en proyectos?

En gestión de proyectos y en metodologías ágiles como Scrum, el MVP es el primer incremento que se entrega a usuarios reales: lo mínimo que aporta valor y permite recoger opiniones. No es el primer sprint ni una demo interna. Es lo primero que sale fuera y se usa.

¿Para qué sirve un MVP?

Un MVP sirve para comprobar si alguien quiere tu producto antes de gastar meses y decenas de miles de euros en construirlo entero. En concreto, sirve para:

• Validar la demanda. Comprobar con hechos, no con encuestas, que hay gente dispuesta a usar o pagar tu solución.
• Aprender rápido. Ver qué hacen los primeros usuarios, qué ignoran y qué echan de menos.
• Limitar el riesgo. Si la idea no funciona, lo sabes con una fracción del presupuesto.

Ries lo resume en un ciclo: construir, medir, aprender. El MVP es la primera vuelta de ese ciclo, y cuanto antes la des, antes empiezas a decidir con datos.

Diferencia entre prototipo, MVP y producto final

Un prototipo sirve para ver y probar la idea; un MVP, para validarla con clientes reales, y el producto final, para crecer. Se confunden a menudo, y la confusión sale cara: quien pide «un MVP» y espera un producto final acaba pagando el producto final.

Un prototipo se enseña. Un MVP se usa. Si antes de todo eso necesitas saber si algo es técnicamente posible, lo que buscas es una prueba de concepto.

Tipos de MVP

Hay cinco tipos principales de MVP: la landing de prueba, el vídeo, el concierge, el mago de Oz y el de una sola función. No todos llevan código, y cada uno te permite comprobar una cosa distinta:

Los tres primeros miden interés: alguien dice que le gustaría. Solo los dos últimos miden comportamiento: alguien usa el producto o paga. Para decidir si inviertes, lo segundo vale mucho más. Lo que cuesta construir uno según quién lo haga lo detallo en cuánto cuesta un MVP en España.

¿Y el no-code?

Hace unos años era la forma barata de tener un MVP. Hoy casi nunca compensa. Con la inteligencia artificial, escribir código cuesta mucho menos que antes, y el ahorro del no-code ya no paga sus límites: dependes de la plataforma, el precio sube con cada usuario y, cuando el producto funciona, toca rehacerlo desde cero.

Lo caro de un MVP ya es decidir qué construir y mantenerlo en producción, y eso no lo resuelve ninguna plataforma. Si todavía no sabes si hay interés, tampoco necesitas no-code: una landing o un concierge te lo dicen antes y más barato. Dónde sí encaja lo cuento en qué son el no-code y el low-code.

¿Cómo se hace un MVP? Paso a paso

Un MVP se hace en siete pasos: escribir la hipótesis, elegir la única acción que tiene que salir bien, recortar la lista de funciones, decidir cómo medir, construir lo justo, salir a vender y decidir con los datos.

1. Escribe tu hipótesis en una frase

Qué crees que pasará, para quién y cuánto valdría. Por ejemplo: «Las clínicas de fisioterapia pagarían 30 euros por cubrir una baja en menos de 24 horas». Si no cabe en una frase, todavía no está listo para construirse.

2. Elige la única acción que tiene que salir bien

Reservar, comprar, publicar, encargar. Una. Es la que demuestra tu hipótesis, y todo el MVP gira alrededor de ella.

3. Haz la lista completa y recorta

Apunta todo lo que te gustaría que tuviera el producto. Después, separa lo que hace falta para esa única acción de todo lo demás. Lo que se queda fuera no se pierde: va a una lista para la versión dos. Este paso es el más difícil y el que más dinero ahorra.

4. Decide cómo vas a medir antes de construir

Una métrica, un umbral y un plazo. «El 70 % de los turnos se cubren en menos de 24 horas durante las primeras ocho semanas.» Si lo decides después de lanzar, cualquier resultado te parecerá bueno.

5. Construye lo justo, pero bien hecho

«Mínimo» se refiere al alcance, no a la calidad. Si el producto falla, no sabrás si los usuarios se van por la idea o por los errores.

La tecnología debe dejarte crecer sin rehacerlo todo y costar poco mientras validas. Lo que usamos nosotros:

• Nuxt con Bun para la web: una sola base de código que funciona en ordenador y en móvil.
• Django, con Django REST Framework o Django Ninja, para el backend. Es maduro, seguro y trae un panel de administración que ahorra semanas.
• Rust solo para las piezas que necesitan mucho rendimiento.
• PostgreSQL como base de datos. Si el producto crece mucho, PgDog reparte la carga entre varios servidores.
• Stripe para cobrar. Si vendes fuera de España, Polar, que actúa como vendedor (merchant of record) y se encarga del IVA de cada país.
• Servidores en Hetzner o netcup en lugar de AWS o Google Cloud. Para un MVP cuestan una fracción y sobran. Si el producto escala, montamos y gestionamos Kubernetes sobre servidores dedicados del mismo tipo de proveedor.

6. Sal a vender

Es el paso más importante de todos. Un MVP no se valida solo: nadie va a encontrarlo por casualidad, y si no lo vendes, no aprendes nada. El producto es secundario; lo que decide si tu idea sale adelante es tu capacidad de venderla.

Llama, escribe, visita, enseña el producto a quien tiene el problema y pide que pague. Diez clientes que tienen el problema valen más que mil visitas. Busca a tus early adopters y evita que sean solo amigos y familia: te dirán que les encanta y no volverán a entrar. Para que las conversaciones te den datos y no cumplidos, sigue las reglas de The Mom Test.

7. Decide: seguir, cambiar o parar

Llegado el plazo, mira la métrica. Si se cumple, construye la versión dos con lo que has aprendido. Si se cumple a medias, habla con los usuarios antes de tocar el código. Si no se cumple, cambia de enfoque (lo que en el mundo startup llaman pivotar) o para. Parar a tiempo también es un buen resultado. Y si se cumple ciclo tras ciclo, vas camino del product-market fit.

Un ejemplo

Una fisioterapeuta con clínica propia detecta un problema: cuando alguien del equipo se pone de baja, las clínicas pierden citas porque no encuentran sustituto a tiempo. Su idea inicial es una app con perfiles, valoraciones, chat, calendario, pagos entre clínicas y fisioterapeutas, facturación automática y versiones para iPhone y Android.

Su hipótesis es la del paso 1, y la acción que tiene que salir bien es que una clínica publique un turno y un fisioterapeuta lo acepte. Con eso, el recorte queda así:

Se construye en seis semanas: una para cerrar el alcance y probar un prototipo, cuatro de desarrollo y una de pruebas y lanzamiento. Se lanza con diez clínicas conocidas y unos cuarenta fisioterapeutas de la ciudad, y se miden dos cosas durante ocho semanas: qué porcentaje de turnos se cubre en menos de 24 horas (objetivo: 70 %) y cuántas clínicas repiten el segundo mes (objetivo: cinco de diez).

Lo interesante es lo que se decide con cada resultado:

• Se cumplen las dos: la versión dos añade el pago automático y una segunda ciudad.
• Se cubren los turnos pero las clínicas no repiten: el problema es el precio o la frecuencia. Toca hablar con ellas antes de programar nada más.
• No se cubren los turnos: faltan fisioterapeutas disponibles. Es otro problema, y quizá no se resuelve con software.

En los tres casos, la fundadora decide con datos tras dos meses y medio, en lugar de descubrirlo tras un año construyendo la app completa.

Ejemplos de producto mínimo viable en España

Las empresas más conocidas empezaron con versiones que hoy parecerían precarias.

Wallapop: una app en menos de mes y medio

En 2013, cuatro personas construyeron la primera versión de Wallapop en menos de mes y medio, con 30.000 euros para aguantar seis meses. Para que la app no saliera vacía, Agustín Gómez y su primo llenaron el catálogo con fotos hechas en mercadillos. El día del lanzamiento fue la app número uno en la App Store (elDiario.es, El Español).

Spotahome: nueve pisos y un botón que no funcionaba

En 2014, Spotahome arrancó con una web de nueve pisos cerca del IE, en Madrid, que los propios fundadores habían grabado en vídeo. Ni el botón de reservar ni la pasarela de pago funcionaban: los formularios acababan en una llamada. La primera reserva llegó el mismo día: un inquilino japonés que no había visto el piso y pagó en efectivo (ForoMarketing, El Español).

Typeform: un encargo convertido en producto

Typeform nació de un trabajo para un cliente: un formulario que hacía una pregunta cada vez, para las pantallas de la Roca Gallery de Barcelona. David Okuniev y Robert Muñoz vieron que la idea funcionaba y tardaron año y medio en convertirla en producto, primero con una alfa por invitación y en 2013 con una beta abierta (EU-Startups, Zapier).

Civitatis: un anuncio que se convirtió en negocio

Alberto Gutiérrez empezó en 2008 con guías de viaje gratuitas que se pagaban con publicidad. En 2009 un guía de Praga quiso anunciarse; en lugar de venderle un anuncio, publicaron sus visitas a comisión y al día siguiente se vendió una. En 2013, Civitatis ya era una tienda completa de actividades (Diario de Valladolid).

Holded: una herramienta hecha para uno mismo

Bernat Ripoll se programó una aplicación de facturación muy simple para su trabajo como autónomo y la compartió en Facebook, donde la vio Javi Fondevila, su futuro socio. La primera versión de Holded salió en enero de 2016, hecha a tiempo parcial, y llegó a 600 empresas sin gastar en publicidad (ViaEmpresa).

Fuera de España: Dropbox, Zappos y Airbnb

• Dropbox publicó en 2008 un vídeo de cómo funcionaba su producto, que ya tenía un prototipo detrás. La lista de espera pasó de 5.000 a 75.000 personas en un día (TechCrunch).
• Zappos empezó en 1999 con fotos de zapatos de una tienda de Sunnyvale. Cuando alguien compraba, el fundador iba a la tienda, los compraba a precio normal y los enviaba (Fortune).
• Airbnb alojó a sus tres primeros huéspedes en 2007, en tres colchones hinchables del piso de los fundadores en San Francisco, durante una conferencia de diseño (Airbnb).

Qué tienen en común

• Hacían una sola cosa: vender algo de segunda mano, reservar un piso, responder un formulario.
• Resolvían a mano todo lo que no era esa cosa: fotos en mercadillos, reservas por teléfono, zapatos comprados en tienda.
• Llegaron a clientes reales en semanas, no en años.
• Ninguno esperó a tener el producto completo para saber si había demanda.

Errores habituales al crear un MVP

1. Construir la versión tres. Si tu MVP tarda seis meses, ya no es un MVP. Vuelve al paso 3 y recorta.
2. Confundir mínimo con mal hecho. Un producto lleno de errores no valida nada: los usuarios se van y no sabes por qué.
3. No decidir qué medir. Sin métrica ni umbral, no hay forma de saber si el MVP ha funcionado.
4. Probarlo solo con conocidos. Las opiniones de amigos no son datos. Busca gente que tenga el problema y no te deba nada.
5. Montar infraestructura de gran empresa. Un MVP no necesita la arquitectura de una empresa con millones de usuarios. Necesita poder llegar a ella sin rehacerse.
6. Esperar a que se venda solo. Lanzar y sentarse a mirar las estadísticas no es validar. Si no sales a vender, el MVP no te dirá nada.
7. No quedarte con el código. Si el repositorio y el servidor no están a tu nombre, el producto no es tuyo.

En resumen

• Un producto mínimo viable es la primera versión de tu producto que pueden usar clientes reales, con lo justo para comprobar si tu idea funciona.
• No es un prototipo: funciona de verdad y puede cobrar.
• Se hace con una hipótesis, una única acción, un recorte sin piedad y una métrica decidida antes de lanzar.
• Lo más importante es vender. El producto es secundario: sin ventas, el MVP no valida nada.
• Wallapop, Spotahome o Typeform empezaron con versiones mínimas y resolvieron a mano todo lo demás.

Si ya tienes clara tu hipótesis y quieres construir el MVP, mira cómo trabajamos y cuánto cuesta.