EMPRENDIMIENTO
Cómo definir un MVP sin construir de más
Un MVP no es una versión barata del producto final. Es el mínimo conjunto de capacidades que permite validar una hipótesis relevante.
Empieza por la hipótesis, no por las funcionalidades
La primera pregunta no debería ser qué funcionalidades tendrá la aplicación. Debería ser qué comportamiento, necesidad o disposición a pagar necesitas validar para justificar seguir invirtiendo.
Cuando el MVP nace desde una lista de funcionalidades, el alcance crece antes de que exista evidencia de valor.
Define el problema con precisión
- Quién tiene el problema.
- En qué contexto aparece.
- Cómo lo resuelve actualmente.
- Qué fricción o coste existe hoy.
- Qué resultado sería suficientemente valioso como para cambiar de comportamiento.
MoSCoW sirve si eres exigente con el Must
Clasificar todo como Must elimina el valor de priorizar. Un Must debería ser aquello sin lo que no puedes validar la propuesta de valor o completar el flujo principal del usuario.
Should y Could no son funcionalidades descartadas: son decisiones conscientemente aplazadas para proteger velocidad y aprendizaje.
Una buena primera versión tiene también fuera de alcance
Especificar qué no vas a construir es tan importante como definir qué entra. Reduce ambigüedad con proveedores, evita expectativas implícitas y protege la fecha objetivo.
El MVP termina cuando puedes aprender algo relevante, no cuando has reproducido el producto que imaginas a tres años.