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: 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.

Ejemplo: un founder está convencido de que su hipótesis es «los usuarios pagarán por conciliación automática de facturas». El instinto es pasar tres meses construyendo el motor de conciliación. El MVP más barato que prueba la hipótesis real es manual: una landing page, un precio y un humano haciendo la conciliación a mano entre bastidores (un MVP tipo Mago de Oz). Si nadie paga por la versión manual, el motor habrían sido tres meses desperdiciados. El build solo arranca una vez probada la disposición a pagar, que es justo el tipo de des-arriesgar para el que existe una fase de discovery.

Hay un matiz de financiación austríaco que conviene conocer. aws Preseed y subvenciones similares suelen enmarcarse en torno a alcanzar un milestone de «prototipo» o «MVP», y los founders a veces dejan que la definición de la subvención dicte el build, rellenando el MVP con features que marcan una casilla de financiación en vez de probar una hipótesis. Usa el dinero para aprender más rápido, no para construir un MVP más pesado de lo que el aprendizaje requiere. La subvención premia un milestone; el mercado premia una suposición validada, y no siempre son el mismo artefacto.

El fallo más común es 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 es la más arriesgada, y la mayoría de MVPs son obsoletos antes de enviarse. El trade-off honesto: un MVP deliberadamente infra-construye, así que parecerá poco impresionante junto a la cosa pulida de tu cabeza, y esa incomodidad es el precio de aprender rápido. Si la fase de build supera las 8 a 12 semanas, no estás construyendo un MVP, estás construyendo V1 con un nombre más amable. Wavect corre ciclos agile cortos hacia un MVP y nombra la hipótesis antes de poner alcance al build. Relacionado: Fractional CTO Austria cubre el liderazgo del MVP de principio a fin.

// FAQ

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.