Define el MVP de tu producto con la funcionalidad mínima que valida la hipótesis central sin desperdiciar tiempo de desarrollo. Con el proceso para identificar qué es mínimo y qué es viable, las técnicas para validar antes de construir y cómo saber cuándo el MVP está listo.
Cuándo usarlo: MVP, producto mínimo viable, validación, lean startup, product management
Herramienta recomendada: Claude
Eres un Product Manager con experiencia lanzando MVPs en startups que han pasado de "construyamos todo" a "validemos con lo mínimo necesario" reduciendo el time-to-market de 9 meses a 6-8 semanas. Contexto: - Idea de producto: [describe] - Hipótesis central: [qué asumes que es cierto sobre el problema y la solución] - Usuario objetivo: [describe] - Recursos disponibles: [1 dev / equipo de 3 / sin dev (no-code) / agencia] - Estado actual: [idea sin desarrollar / prototipo / MVP en desarrollo / MVP lanzado sin tracción] ## Definición del MVP — [Producto] ### 🧠 La confusión sobre el MVP (y la definición que importa) **Lo que el MVP NO es:** - La versión reducida del producto completo - Un prototipo de baja calidad - Un producto con bugs que "ya mejoraremos después" **Lo que el MVP SÍ es:** La versión del producto que permite aprender lo máximo sobre el problema y la solución con el mínimo esfuerzo. El objetivo del MVP no es lanzar — es aprender. **La pregunta que define el MVP:** "¿Cuál es la hipótesis más importante que este producto debe validar?" Todo lo que no valida esa hipótesis no va en el MVP. ### 🔍 El proceso para definir qué va en el MVP (y qué no) **Paso 1 — Escribe la hipótesis central:** "Creemos que [el usuario X] tiene el problema Y. Creemos que la solución Z resuelve ese problema. Lo sabremos cuando [el indicador de validación]." Ejemplo: "Creemos que los freelancers de diseño tienen dificultad para hacer seguimiento de sus proyectos y cobros. Creemos que una app simple de gestión de proyectos y facturación lo resuelve. Lo sabremos cuando 50 freelancers la usen activamente durante 30 días y el 70% facture a través de la app." **Paso 2 — Lista todas las funcionalidades "posibles":** Sin limitación — todo lo que el producto podría hacer. **Paso 3 — Clasifica cada funcionalidad:** ``` ESENCIAL: sin esto, no puedo probar la hipótesis central IMPORTANTE: añade valor, pero el MVP funciona sin esto DESEABLE: sería ideal, pero no es necesario para la validación DEFER: para versiones futuras Regla: solo lo ESENCIAL va en el MVP ``` **Paso 4 — La pregunta de eliminación:** Para cada funcionalidad "esencial" pregunta: "¿Puedo validar la hipótesis sin esto? ¿Puedo hacerlo manualmente en lugar de construirlo?" Si la respuesta es sí → no lo construyas, hazlo manualmente. ### 🔧 Las técnicas para validar antes de construir **El "Mago de Oz":** El usuario cree que está usando un sistema automatizado, pero hay una persona detrás haciendo el trabajo manualmente. Validación sin una sola línea de código. **El Smoke Test:** Crea una landing page que describe el producto que aún no existe. Añade un formulario de registro o un botón de compra. Si nadie se registra → el problema no era tan grande como pensabas. Si hay registros → tienes demanda antes de construir. **El concierge:** Ofreces el servicio manualmente para los primeros clientes. Si vendes software de gestión → ofrécete a gestionar el proceso tú mismo en Excel por €X/mes. Si hay disposición a pagar → hay mercado. **El prototipo en Figma:** Diseña los flujos clave en alta fidelidad sin código. Haz user testing con el prototipo. Aprenderás el 80% de lo que aprenderías con el producto real, sin construirlo. ### 📐 Las feature flags: cómo lanzar el MVP a un subset de usuarios La estrategia de rollout progresivo que permite validar con usuarios reales sin arriesgar toda la base de usuarios.