Ocho semanas caben cuando recortas el alcance antes de escribir código. Un equipo que abre el editor en la primera reunión gasta esas semanas en funcionalidades que nadie pidió, arquitectura fuera del presupuesto y flujos que no calzan con el recorrido de quien compra.
Marty Cagan insiste en Inspired (Wiley, 2017) que el equipo valide el problema antes de discutir la solución. Quien empieza por la lista de features gasta el plazo construyendo la respuesta a la pregunta equivocada.
Semanas 1 y 2: definir antes de escribir
La tentación es abrir el editor en la primera reunión. Resiste. Las dos primeras semanas producen cuatro respuestas por escrito:
- Hipótesis central: qué validas y qué número comprueba la validación
- Usuario real: el perfil que instala la primera versión, sin "todos los clientes potenciales"
- Flujo mínimo: el camino desde cero hasta el momento en que el producto sirve, con el resto recortado
- Dependencias críticas: integraciones, APIs externas y autenticación que bloquean el resto cuando se dejan para después
Rob Fitzpatrick trata la primera respuesta en The Mom Test (2013): preguntas por la vida de quien compra, no por la idea. Esas cuatro respuestas se vuelven el alcance escrito de las seis semanas siguientes.
Semanas 3 y 4: arquitectura que aguanta el lanzamiento
Las decisiones de esta fase fijan el costo de cada sprint hasta el día del lanzamiento:
- Elige la stack que el equipo domina. Ocho semanas no absorben la curva de aprendizaje de un framework nuevo.
- Quédate en el monolito. Un monolito cortado por dominio escala más allá de donde llega la mayoría de los MVPs, y Martin Fowler defiende el mismo orden en "MonolithFirst" (2015).
- Enciende observabilidad en la semana 1: logs, rastreo de errores y métricas de uso. La semana 7 corre con esos datos.
- Automatiza el deploy el día 1: un pipeline simple quita errores manuales y acorta el lead time, el indicador que Forsgren, Humble y Kim asocian a la entrega rápida en Accelerate (2018).
Semanas 5 y 6: el flujo central
Con la base lista, entregas el flujo mapeado en la semana 1 y nada más. Cada pedido fuera de él va a una lista aparte, el backlog de validación post-lanzamiento. "El cliente va a querer esto" enuncia una hipótesis, y la hipótesis que el MVP existe para probar está en la primera página del documento de alcance.
La lista aparte guarda las ideas y deja la entrega en paz.
Semana 7: estabilizar
Pasas la semana sin agregar nada: pruebas manuales del flujo central, corrección de bugs, chequeo de rendimiento en red real, revisión de seguridad. La semana existe para que la lista de bugs conocidos esté escrita antes del día del lanzamiento.
Semana 8: lanzar instrumentado
El lanzamiento abre la fase de aprendizaje, y aprender exige datos. Enciendes analytics de producto, rastreo de conversión en el flujo central y canal de feedback con los primeros usuarios. Eric Ries describe el ciclo construir-medir-aprender en The Lean Startup (Crown Business, 2011).
Sin esos tres instrumentos, publicas y repites la misma apuesta.
Qué hace el liderazgo técnico en un MVP
La mayoría de los MVPs muere por alcance descontrolado, y el alcance es problema de liderazgo técnico. Alguien tiene que decir que no a la feature de la semana 5 que empuja el lanzamiento, elegir una arquitectura que no se vuelva reescritura en noviembre y mantener al equipo dentro del flujo mapeado.
Liderazgo técnico sénior, interno o con consultoría corta, mantiene un MVP de ocho semanas entregando un producto que el equipo puede mantener después.
