Un MVP (producto mínimo viable) es la versión más simple de un producto que permite probar una hipótesis de negocio con usuarios reales, con la menor inversión de tiempo y dinero posible. No es una versión incompleta del producto final: es un experimento diseñado para aprender, no para vender.
Qué es un MVP y por qué no es "hacer menos"
El concepto lo acuñó el ingeniero Frank Robinson a fines de los noventa, pero fue Eric Ries quien lo instaló en el vocabulario startup con "The Lean Startup" y con un post previo en su blog, donde lo definió como "esa versión de un producto nuevo que permite a un equipo recolectar la máxima cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo posible", según su guía original sobre el MVP.
Ojo con la trampa más común: un MVP no es "la app completa pero con menos funciones". Es el experimento más barato que responde la pregunta más riesgosa de tu negocio. Si tu hipótesis es que la gente va a pagar por lavar autos a domicilio en quince minutos, no necesitas una app: necesitas un número de WhatsApp, una planilla y tres autos reales agendados esta semana.
Ese dato es el argumento de fondo para construir un MVP: la mayoría de las startups no mueren por construir mal, mueren por construir algo que nadie necesitaba, y lo descubren demasiado tarde y demasiado caro.
MVP, prototipo y prueba de concepto: en qué se diferencian
Los tres términos se usan como sinónimos y no lo son. Cada uno responde una pregunta distinta, en un momento distinto del proceso.
| Concepto | Qué pregunta responde | Quién lo prueba | Ejemplo |
|---|---|---|---|
| Prueba de concepto (POC) | ¿Es técnicamente posible construir esto? | Tu propio equipo | Un script interno que confirma que se puede automatizar una tarea |
| Prototipo | ¿La experiencia de uso funciona antes de programar? | Usuarios en pruebas controladas | Una maqueta clickeable en Figma, sin lógica real detrás |
| MVP | ¿El mercado usa o paga por esto en condiciones reales? | Usuarios reales, en su contexto real | Una landing con botón de compra que activa un proceso manual |
La confusión más cara ocurre cuando un equipo se salta la prueba de concepto y el prototipo, y construye directo el MVP con tecnología que todavía no confirmó que funciona. El orden importa: primero factibilidad, después experiencia de uso, al final validación de mercado.
Los tipos de MVP que puedes construir
No todo MVP necesita código. Estos son los formatos más usados, de menor a mayor inversión.
| Tipo de MVP | Cómo funciona | Cuándo usarlo |
|---|---|---|
| Concierge | Tú mismo entregas el servicio a mano, sin automatizar nada | El riesgo está en el proceso, no en si hay demanda |
| Mago de Oz | El usuario ve una interfaz simple, pero atrás hay personas operando manualmente | Automatizar es caro y quieres validar primero si hay demanda |
| Landing page con lista de espera | Una página describe el producto y mide cuánta gente deja su correo o paga un depósito | Quieres medir interés antes de construir nada |
| Video explicativo | Un video muestra cómo funcionaría el producto, aunque todavía no exista | Explicar es más barato que construir, especialmente en productos complejos |
| Producto de una sola función | Se construye solo la función central, sin las secundarias | Ya confirmaste demanda y necesitas medir uso real |
El caso del video explicativo lo popularizó Dropbox, que antes de construir su producto grabó un video mostrando cómo funcionaría la sincronización de archivos y midió cuánta gente se inscribía para probarlo. No gastaron en infraestructura hasta confirmar que había interés real.
Cómo lanzar tu primer MVP: el proceso paso a paso
- Escribe la hipótesis, en una frase: "creemos que [segmento] va a [acción] porque [razón]".
- Identifica el riesgo más grande: ¿nadie lo quiere, no saben usarlo, o no puedes construirlo a tiempo?
- Elige el tipo de MVP más barato que resuelva ese riesgo específico, según la tabla anterior.
- Define la métrica de éxito antes de lanzar, no después de ver los resultados.
- Lánzalo a un grupo acotado y real, no a "todo el mundo" ni solo a tu círculo cercano.
- Mide, aprende y decide: seguir, ajustar la hipótesis o parar. Este ciclo de construir, medir y aprender es el corazón del método que Ries describe en su libro.
MVP en Chile y LatAm: validar antes de gastar el cheque que no vas a tener dos veces
Las rondas pre-semilla en Chile y LatAm suelen ser más chicas que en Estados Unidos o Europa, así que cada peso gastado en construir algo que nadie pidió pesa más. ¿Para qué programar seis meses una app si puedes confirmar la hipótesis con un grupo de WhatsApp en una semana?
Dos startups chilenas conocidas partieron así: NotCo probó decenas de fórmulas de productos plant-based en lotes pequeños antes de escalar producción, y Cornershop arrancó operando pedidos de supermercado de forma manual en un puñado de comunas de Santiago antes de construir la app completa. En ambos casos, la tecnología llegó después de confirmar que el problema era real.
Antes de definir qué vas a probar con tu MVP, conviene tener claro tu modelo de negocio completo: el Canvas ordena las hipótesis de valor, canal y costos, y el MVP es la herramienta para probar la más riesgosa de todas primero. Otras startups latinoamericanas, como Aviva en México o Addi en Colombia, tuvieron que demostrar tracción real con usuarios antes de levantar las rondas que hoy las financian.
Errores comunes al construir un MVP
- Construir "un poco de todo" en vez de probar una sola hipótesis a la vez.
- No definir de antemano qué resultado cuenta como validación, y ajustar el criterio después de ver los números.
- Probarlo solo con amigos y familia, que no representan al mercado real y rara vez dicen que no.
- Convertir el MVP en el producto final sin iterar, arrastrando decisiones tomadas para una prueba rápida.
- Automatizar procesos antes de confirmar que existe demanda suficiente para justificar la inversión.
Qué hacer con esto: cómo lanzar tu MVP esta semana
- Escribe tu hipótesis en una frase, con segmento, acción y razón.
- Elige el tipo de MVP más barato de la tabla que resuelve tu riesgo principal.
- Define la métrica de éxito antes de lanzar, no después.
- Consigue entre 10 y 20 usuarios reales, no beta testers que ya son tus amigos.
- Fija una fecha límite de una a dos semanas para decidir si sigues, ajustas o paras.
Preguntas frecuentes sobre el MVP
¿Qué significa MVP en producto?
En gestión de producto, MVP significa producto mínimo viable (minimum viable product): la versión más simple de un producto que permite aprender de usuarios reales con la menor inversión posible, no la primera versión reducida del producto final.
¿Cómo se hace un MVP paso a paso?
Se escribe la hipótesis a probar, se identifica el riesgo más grande del negocio, se elige el formato de MVP más barato que responde esa pregunta (concierge, mago de Oz, landing, video o una sola función) y se mide con una métrica definida antes de lanzar.
¿Es lo mismo un MVP que un producto mínimo viable?
Sí, son el mismo concepto: MVP es la sigla en inglés de minimum viable product, y "producto mínimo viable" es su traducción directa al español. Ambos términos se usan indistintamente en el ecosistema startup.
¿Cuánto se demora en construir un MVP?
Depende del riesgo que estés probando, no de cuánto producto quieras mostrar. Un MVP tipo concierge o landing page puede estar listo en días; uno que requiere una sola función programada suele tomar entre dos y seis semanas si el equipo se mantiene disciplinado en no agregar features de más.
