Ocho semanas parece poco. Es poco, si no eres quirúrgico en cada decisión. Haz menos, mejor, con más claridad sobre lo que importa para validar la hipótesis de producto.
La mayoría de los MVPs que fracasan no fracasan por falta de velocidad. Fracasan porque el equipo construyó cosas equivocadas, funcionalidades que el usuario no pidió, arquitectura que no cabe en el presupuesto, flujos que no mapean la jornada real. Un buen MVP empieza con rigor de alcance, no con código.
Semana 1-2: Definición, no desarrollo
La primera tentación es abrir el editor y empezar a construir. Resiste. Las dos primeras semanas deben ser casi enteramente de definición:
- ¿Cuál es la hipótesis central del producto? Qué estás intentando validar, y cómo sabrás si lo validaste.
- ¿Quién es el usuario real del MVP? No "todos los clientes potenciales", qué perfil específico va a usar la primera versión.
- ¿Cuál es el flujo mínimo que entrega valor? Mapea la jornada desde cero hasta el "aha moment". Todo fuera de ese flujo queda fuera.
- ¿Cuáles son las dependencias críticas? Integraciones, APIs externas, autenticación, qué puede bloquear todo si no se resuelve pronto.
Con esas respuestas, tienes el mapa. Sin ellas, tienes prisa.
Semana 3-4: Arquitectura y fundación
La velocidad sostenible empieza aquí. Las decisiones de arquitectura tomadas en esta fase definen el costo de cada sprint hasta el lanzamiento, y durante mucho tiempo después.
Algunas decisiones prácticas que marcan la diferencia:
- Elige tecnología que el equipo ya domina. Un MVP no es el momento de aprender un nuevo framework. Usa lo que conoces bien y muévete rápido.
- Evita la sobreingeniería. Un monolito bien hecho escala mucho más allá de donde llegan la mayoría de los MVPs. Microsservicios desde cero son un pasivo de 8 semanas, no un activo.
- Invierte en observabilidad desde el inicio. Logging básico, rastreo de errores, métricas de uso. Lo vas a necesitar en la semana 7 cuando algo se rompa en producción.
- Automatiza el deploy desde el día 1. Un CI/CD simple desde el inicio ahorra horas cada semana y reduce el riesgo de error manual en el lanzamiento.
Semana 5-6: Construcción del flujo central
Con la fundación en su lugar, el foco es entregar el flujo mínimo mapeado en la semana 1. La disciplina aquí es saber decir no.
Toda feature que no está en el flujo central es candidata a recorte. "Pero el cliente va a querer esto" es una hipótesis, y la hipótesis que el MVP existe para probar es otra. Añadir features no validadas aumenta el alcance, aumenta el riesgo y retrasa el lanzamiento.
Un patrón útil: toda sugerencia de feature entra en una lista separada, el backlog de validación post-lanzamiento. Así mantienes las ideas sin bloquear la entrega.
Semana 7: Estabilización y calidad
Una semana entera dedicada a no añadir nada nuevo, solo garantizar que lo que existe funciona bien. Tests manuales exhaustivos del flujo central. Corrección de bugs. Rendimiento en condiciones reales. Revisión de seguridad básica.
Lanzar con bugs conocidos es a veces una elección estratégica válida. Lanzar sin saber que existen bugs es incompetencia.
Semana 8: Lanzamiento e instrumentación
El lanzamiento no es el fin, es el comienzo de la fase de aprendizaje. Para que cumpla ese papel, necesitas suficiente instrumentación para saber qué hacen los usuarios, dónde abandonan, qué está funcionando.
Analytics básico de producto, rastreo de conversión en el flujo central, canal de feedback directo con los primeros usuarios. Sin eso, lanzas, pero no aprendes.
El papel del liderazgo técnico en el MVP
Los MVPs fracasan por problemas técnicos con menos frecuencia de lo que parece. La mayoría fracasa por falta de disciplina de alcance, y la disciplina de alcance es liderazgo técnico.
¿Quién garantiza que el equipo está construyendo lo correcto, y no solo construyendo rápido? ¿Quién hace las elecciones de arquitectura que permiten escalar después, sin reescribir todo? ¿Quién dice no a la feature de la semana 5 que va a retrasar el lanzamiento?
Tener un liderazgo técnico sénior, sea interno o como consultoría de corto plazo, es lo que separa un MVP que se convierte en producto de un MVP que se convierte en deuda técnica con usuarios.
