Construye el producto mínimo que prueba si el negocio funciona: las decisiones de qué incluir y qué dejar fuera, las herramientas no-code que aceleran el primer MVP y el criterio técnico que evita construir lo que nadie necesita.
Cuándo usarlo: Definir y construir el MVP que valida la hipótesis de negocio con el mínimo esfuerzo de desarrollo.
Herramienta recomendada: Claude
Eres un experto en product development en etapas tempranas de startup con experiencia en construir MVPs que validan hipótesis de negocio sin desperdiciar recursos de ingeniería. Necesito tu ayuda para definir y construir el MVP de mi proyecto: el mínimo que necesito construir para aprender si el negocio funciona antes de invertir meses en el producto completo. Mi contexto: - Idea o problema que quiero resolver: [describe el problema y la solución que tienes en mente] - Hipótesis principal a validar: [qué es lo que más necesitas saber si es verdad o no] - Usuario objetivo: [quién tiene el problema y cuánto le duele] - Recursos disponibles: [tiempo, equipo de desarrollo, presupuesto] - Fecha límite o urgencia: [tienes un plazo?] - Qué ya tienes construido o validado: [si tienes algo] Con ese contexto, dame: 1. LA HIPÓTESIS DEL NEGOCIO: QUÉS LO QUE REALMENTE NECESITAS VALIDAR Antes de hablar de lo que construir, ayúdame a formular con precisión la hipótesis de negocio que necesito validar: la hipótesis del problema (¿el problema que creo que existe realmente existe y duele lo suficiente?), la hipótesis de la solución (¿mi solución resuelve el problema mejor que las alternativas?), y la hipótesis del negocio (¿hay un modelo de negocio viable?). Para cada hipótesis, dame la pregunta exacta que necesito responder y el tipo de experimento que la valida más rápido (entrevista, encuesta, demo, prototipo, o MVP funcional). 2. QUÉ INCLUIR Y QUÉ DEJAR FUERA DEL MVP ¿Cómo decido qué construir y qué no? Dame el proceso de definición del scope del MVP: la distinción entre los requisitos que directamente validan la hipótesis (deben estar), los que mejoran la experiencia pero no son necesarios para la validación (se pueden añadir después), y los que son nice-to-have que el equipo quiere construir pero que no aportan aprendizaje (eliminados). Dame también los errores más comunes en la definición del MVP: el MVP que es demasiado grande y tarda meses, el MVP que es tan mínimo que no enseña nada, y el MVP que resuelve un problema diferente al que el cliente tiene. 3. TIPOS DE MVP SEGÚN LO QUE NECESITAS VALIDAR ¿Qué tipo de MVP debo construir para mi caso específico? Dame el análisis de los diferentes tipos de MVP y cuándo usar cada uno: el Concierge MVP (el proceso es manual, el equipo hace a mano lo que el producto haría automáticamente), el Wizard of Oz MVP (parece automatizado pero hay un humano detrás), el Landing Page MVP (prueba si hay demanda antes de construir nada), el Prototype MVP (interfaz sin backend para validar el diseño del flujo), el Piecemeal MVP (combina herramientas existentes para simular el producto), y el MVP técnico mínimo (código real pero con funcionalidades reducidas al mínimo). Cuál es el mejor para mi hipótesis. 4. HERRAMIENTAS NO-CODE QUE ACELERAN EL MVP ¿Qué herramientas no-code o low-code puedo usar para construir el MVP más rápido? Dame el mapa de herramientas por caso de uso: para landing pages y formularios de validación (Webflow, Carrd, Notion, Typeform), para apps web sin código (Bubble, Glide, Softr, AppGyver), para automatizaciones y lógica de negocio (Make/Integromat, Zapier, n8n), para bases de datos y backend (Airtable, Supabase, Firebase), para pagos (Stripe con Checkout, Gumroad), y para comunidad o membresías (Notion, Circle, Memberstack). Para mi caso específico, cuál combinación me permite validar la hipótesis en menos tiempo. 5. EL CRITERIO DE ÉXITO DEL MVP: QUÉ RESULTADOS VALIDAN O INVALIDAN ¿Cómo sé si el MVP está funcionando o no? Ayúdame a definir el criterio de éxito antes de construir el MVP, no después: la métrica que, si se cumple, confirma la hipótesis (usuarios activos, conversión, retención, NPS, disposición a pagar), el umbral concreto que define el éxito (no "muchos usuarios" sino "50 usuarios activos que usan el producto al menos 3 veces por semana en el primer mes"), y el criterio de pivote: cuándo los datos me dicen claramente que debo cambiar de dirección. Por qué definir el criterio de éxito antes de construir es crítico para aprender y no para confirmar sesgos. 6. EL PROCESO DE CONSTRUCCIÓN DEL MVP: VELOCIDAD SIN CAOS ¿Cómo organizo el proceso de construcción del MVP para ir rápido sin crear deuda técnica que paralice el crecimiento? Dame las decisiones técnicas clave en la construcción del MVP: cuándo usar frameworks y herramientas que permiten iterar rápido aunque no sean perfectamente escalables (Next.js, Laravel, Django, Firebase vs. arquitecturas distribuidas prematuras), cómo manejar la deuda técnica del MVP cuando el producto valida y empieza a crecer, y qué partes del código del MVP merece la pena hacer bien desde el principio porque serán la base del producto real. 7. DESPUÉS DEL MVP: CUÁNDO ESCALAR Y CUÁNDO PIVOTAR ¿Cómo interpreto los resultados del MVP para decidir qué hacer a continuación? Dame el framework de decisión post-MVP: las señales de que el MVP ha validado la hipótesis y es momento de escalar (retención elevada, usuarios que pagan sin presión, usuarios que recomiendan el producto, petición de features adicionales), las señales de que necesito pivotar (alta adquisición pero nula retención, usuarios que no vuelven, disposición a pagar baja, feedback que apunta a un problema diferente al que creía resolver), y cuándo el MVP simplemente necesita más tiempo para generar suficientes datos antes de decidir.