Cómo definir el alcance de tu MVP

Definir el alcance es la decisión que más impacto tiene en el coste, el plazo y el éxito de un MVP. Y, sin embargo, es donde más se falla. La tentación de incluir "solo una cosa más" es constante, y cada concesión alarga el desarrollo y diluye el foco. Un alcance bien definido es lo que separa un MVP que se lanza en semanas de uno que nunca llega.

El reto no es decidir qué incluir, sino tener el criterio para dejar fuera todo lo demás sin sentir que el producto queda cojo. En este artículo explicamos cómo acotar el alcance a partir del resultado que quieres validar, cómo distinguir lo imprescindible de lo deseable y cómo defender esas decisiones cuando aparezca la presión por añadir.

Empieza por el resultado, no por las funciones

El error habitual es hacer una lista de funcionalidades y recortarla. El enfoque correcto es partir del resultado que quieres validar: qué tiene que conseguir el usuario para que tu hipótesis se confirme. Una vez tienes ese resultado claro, cada funcionalidad se justifica por si contribuye a él o no. Las que no, no entran.

Este cambio de orden es decisivo. Cuando partes de funciones, todo parece necesario. Cuando partes del resultado, la mayoría se revelan como deseables pero prescindibles. El alcance deja de ser una negociación emocional y pasa a ser una decisión lógica.

Separa lo imprescindible de lo deseable

Toda funcionalidad cae en una de tres categorías, y conviene clasificarlas explícitamente antes de programar nada. Esa clasificación es la herramienta que usarás para decir que no cuando aparezca la presión.

• Imprescindible: sin esto, el usuario no consigue el resultado y la hipótesis no se valida.
• Deseable: mejora la experiencia, pero el producto funciona sin ello.
• Futuro: tiene sentido solo si el MVP demuestra que vale la pena seguir.
• Ruido: parece buena idea pero no contribuye al resultado; descártalo sin contemplaciones.

Defiende el alcance una vez decidido

Definir el alcance es la mitad del trabajo; la otra mitad es protegerlo. Durante el desarrollo aparecerán peticiones nuevas, casi siempre razonables por separado. La disciplina está en anotarlas para la siguiente fase en lugar de meterlas en esta. Un cajón de ideas futuras bien gestionado calma la ansiedad de dejar cosas fuera sin comprometer el plazo.

Cuando una petición parezca imprescindible a mitad de camino, vuelve a la pregunta original: ¿el usuario consigue el resultado sin esto? Si la respuesta es sí, espera. Casi siempre lo es.