Tabla de contenidos
- Introducción
- 1. ¿Qué necesitas validar con este MVP y qué métricas te dirán si lo has conseguido?
- 2. ¿Quién es tu usuario y qué problema concreto tiene?
- 3. ¿Tienes ya usuarios potenciales con los que hablar antes de construir?
- 4. ¿Cuál es tu presupuesto real?
- 5. ¿Qué significa para ti que el MVP haya funcionado?
- El coste de no hacerse estas preguntas
- Checklist antes de escribir código
- Conclusión
Introducción
He hablado con cientos de founders. La mayoría llega con un proyecto brillante en la cabeza, meses de trabajo previo, ilusión, un plan de negocio muy pensado.
Y lo primero que hago es pedirles que esperen.
Antes de escribir una sola línea de código, necesito hacerles cinco preguntas. No son preguntas sobre tecnología. No importa si van a necesitar una app o una web, si el backend será en Node o en Python, cómo se va a escalar la base de datos.
Todo eso viene después.
Lo primero que debo entender es si realmente están listos para construir. Porque la mayoría de los MVPs que fracasan no fracasan por el código o por decisiones técnicas. Fracasan porque nunca respondieron estas cinco preguntas honestamente.
Y eso no se ve hasta que ya es demasiado tarde.
1. ¿Qué necesitas validar con este MVP y qué métricas te dirán si lo has conseguido?
Esta es la pregunta más importante. Y la que menos founders responden bien.
La mayoría dice: "Quiero validar que la gente necesita mi producto." Eso no es lo suficientemente específico.
Lo que necesitas es una hipótesis. Concreta. Falsable. Con un número.
No es: "Los usuarios lo van a usar."
Es: "Dentro de 6 semanas, 50 usuarios activos harán tres búsquedas semanales en promedio y al menos 20% de ellos pagarán 9€ mensuales."
Eso es una métrica. Eso te dice si fracasaste o si lograste validar.
Sin esta respuesta, tu MVP no tiene un fin claro. Y está condenado a fracasar. Porque a los tres meses de trabajo, no va a saber si se supone que tienes que pivotar, iterar más, o parar completamente.
La métrica es lo que distingue entre un MVP que valida y uno que solo consume recursos.
Pregúntate:
- ¿Cuál es el número exacto que me diría "esto funcionó"?
- ¿En cuánto tiempo espero alcanzar ese número?
- ¿De dónde va a venir ese número? (usuarios, ingresos, retención, actividad, algo más)
Si no puedes responder esas tres preguntas de forma muy clara, no estás listo.
2. ¿Quién es tu usuario y qué problema concreto tiene?
He visto infinidad de presentaciones brillantes de productos. El founder describe la solución de maravilla. Todo suena genial.
Y luego pregunto: "¿Cuál es el problema que le vas a solucionar?"
Y la respuesta es vaga. O describe el problema del founder, no el del usuario.
Un usuario real tiene un problema concreto. No un problema general. Un problema que le duele. Que le cuesta dinero. O tiempo. O les hace fracasar.
Si tu usuario es "diseñadores gráficos" y tu problema es "necesitan una herramienta para colaborar", eso es demasiado amplio.
Si tu usuario es "diseñadores gráficos freelance que trabajan con 5+ clientes simultáneos" y tu problema es "pierden 3 horas semanales resolviendo feedback de múltiples clientes en canales diferentes (email, Slack, WhatsApp, Drive comments)", entonces tienes algo específico.
El problema específico es lo que te permite construir un MVP enfocado. Es lo que te permite descartar funcionalidades que no aportan. Y es lo que te permite hablar con usuarios potenciales de forma honesta.
Sin esta claridad, tu MVP va a tener de todo un poco. Y al final no va a resolver nada para nadie.
3. ¿Tienes ya usuarios potenciales con los que hablar antes de construir?
Esta es la pregunta que más rechazo veo.
"¿Por qué necesito usuarios antes de construir? El MVP es para validar con usuarios."
Técnicamente es verdad. Pero que no haya usuarios es una señal de alerta enorme.
Si no puedes encontrar ni 5 personas fuera de tu familia que digan "sí, ese problema me duele, me gustaría probarlo cuando esté listo", hay un problema.
Construir a ciegas es probablemente el error más caro que puedes cometer en esta fase. Pasarás 3 meses construyendo algo, y cuando lo lances, descubrirás que nadie lo quería.
Lo que necesitas antes de escribir código es contacto con usuarios potenciales. No necesita ser formal. No necesita ser una encuesta de 50 personas. Necesita ser conversaciones reales con gente que vive el problema.
Si no puedes encontrar esas 5 personas en tu red, quizás el problema no es lo suficientemente universal.
Y eso es información valiosa. Mejor saberlo ahora.
4. ¿Cuál es tu presupuesto real?
No el que te gustaría tener. El que tienes realmente.
Y el que tienes que dedicar completamente al MVP. No dinero que esperas que salga de otros lados. Dinero que tienes ahora mismo.
Porque sin ese dato es imposible priorizar lo que entra en cada fase y lo que tiene que esperar.
Un MVP con 5.000€ es muy diferente de un MVP con 50.000€.
Con 5.000€ probablemente no puedas hacer un producto pulido. Puedes hacer algo funcional que resuelva el problema. Y eso está bien. Es un MVP.
Con 50.000€ puedes darle más vueltas. Puedes hacer un producto con mejor UX. Puedes hacer un mejor onboarding.
Pero el presupuesto realmente determina qué es posible construir. Y eso determina qué puedes validar.
Si tu presupuesto es 5.000€ y tu plan requiere 30.000€, entonces no tienes un plan. Tienes una fantasía.
Necesitas ajustar el scope. O conseguir más presupuesto.
Pero la mayoría de founders nunca hace esta conversación. Así que a los dos meses se quedan sin dinero. Y el MVP queda a mitad.
5. ¿Qué significa para ti que el MVP haya funcionado?
He visto casos donde un founder consideraba validado su producto con 30 usuarios. Y otros que con 30.000 no eran capaces de seguir vivos.
La diferencia no está en el número. Está en si ese número confirma o rechaza la hipótesis.
Sin una respuesta clara a esta pregunta, el MVP no tiene un fin claro. Está condenado al fracaso.
Porque a los 4 meses, cuando hayas gastado tu presupuesto y tengas datos, no va a saber si fue un éxito o un fracaso. Y eso es dinero perdido.
Lo que necesitas es una definición clara de qué significa éxito.
No en términos generales. En números.
"MVP funcionó" podría significar:
- 50 usuarios activos en 6 semanas
- Tasa de retención semanal de al menos 30%
- Al menos 5 usuarios dispuestos a pagar antes de la fecha X
- 100+ clicks a "llamar para demo" en dos semanas
- 10 cartas de intención de compra
Lo que sea. Pero tiene que ser una métrica. Un número. Algo que puedas medir objetivamente.
Si no tienes esa definición, cuando termines el MVP, no va a saber si pivotar, iterar o parar.
El coste de no hacerse estas preguntas
Llevo años viéndolo. Founders que construyen durante meses sin responder estas preguntas. Gastan dinero, tiempo, energía.
Y cuando por fin lanzan, descubren que:
- El problema que resolvieron no es el que el usuario tenía
- Los usuarios no están dispuestos a pagar
- El producto tiene cien funcionalidades pero ninguna resuelve nada bien
- No hay una forma clara de decir si funcionó o no
Y a ese punto, el MVP está muerto. Y todo el dinero se fue.
La mayoría de proyectos que fracasan no fracasan por el código.
Fracasan porque nadie hizo estas preguntas antes de empezar.
Y cuando se hacen tarde, el coste ya no es técnico. Es tiempo, dinero y oportunidades perdidas.
Checklist antes de escribir código
Antes de que empieces a construir tu MVP, siéntate y responde estas cinco preguntas honestamente:
- ¿Cuál es la métrica exacta que te dirá si validaste tu hipótesis?
- ¿Quién es tu usuario exactamente y cuál es su problema específico?
- ¿Tienes ya contacto con al menos 5 usuarios potenciales?
- ¿Cuál es tu presupuesto real disponible ahora mismo?
- ¿Qué número exacto te dirá "el MVP funcionó"?
Si puedes responder estas cinco preguntas de forma clara, concreta y honesta, probablemente estés listo para construir.
Si no puedes, quizás todavía no lo estás.
Y reconocerlo ahora es mejor que averiguarlo en seis meses cuando el dinero se acabó.
Conclusión
Hace años alguien me dijo: "La diferencia entre un startup que funciona y uno que fracasa no es la idea. Es la ejecución."
Probablemente sea verdad.
Pero yo creo que hay algo antes que la ejecución. Hay una claridad sobre qué exactamente estás intentando lograr.
Si tu MVP es vago, va a fracasar. Pero no por el código. Por falta de enfoque.
Estas cinco preguntas son lo que te da ese enfoque.
Si necesitas ayuda para responder estas preguntas antes de empezar a construir, o necesitas una auditoría técnica para evaluar si tu MVP es viable, podemos hablar sin compromisos. Tengo un marco que te ayuda a validar tu idea en menos de una semana.
No es un proceso largo. Es una conversación honesta sobre si realmente estás listo.