METODOLOGÍA

MVP

Minimum Viable Product

La versión más pequeña del producto que te permite aprender si la idea está equivocada. No la más pequeña que se envía, la más pequeña que enseña.

Última revisión: 2026-05-24 porKevin Riedl wiki ↗

La palabra „viable" en MVP hace todo el trabajo, y casi todo el mundo la entiende mal. Viable no significa „una versión reducida del producto final". Viable significa „suficiente para probar la hipótesis de que vale la pena construirlo". Una landing page con lista de espera puede ser un MVP. Un producto funcional con tres features puede ser peor MVP que la landing page.

Error más común: construir el MVP que imaginabas hace seis meses en vez del MVP que prueba la suposición más incierta de esta semana. Cada semana cambia qué suposición habría que probar. La mayoría de MVPs son obsoletos antes de enviarse.

La fase de discovery de Wavect existe en parte para arreglar esto. Antes de poner alcance al MVP, nombramos la hipótesis que debe probar. Si la hipótesis es „los usuarios quieren la feature X", el MVP no es una feature X pulida, sino la forma más barata de averiguarlo.

// FAQ

Preguntas frecuentes

Preguntas frecuentes

Construir el MVP que imaginabas hace seis meses, no el que prueba la suposición más incierta de hoy. La hipótesis cambia cada semana; el alcance suele fijarse al inicio y no se vuelve a cuestionar. Resultado: envías un MVP de algo que ya sabes y no del riesgo que importa.
Un prototipo prueba la viabilidad técnica (¿se puede construir?). Un MVP prueba la hipótesis de mercado (¿alguien lo quiere?). Mezclarlos hace que pongas usuarios delante de un prototipo y aprendas dos cosas mezcladas; o que pulas un prototipo en un MVP y desperdicies meses.
Lo más corto posible que aún produzca aprendizaje. Si supera tres meses sin contacto real con usuarios, no es un MVP, es un producto reducido. Una landing page con waitlist en una semana suele aprender más que un build de tres meses con cinco features.