Cómo Validar un Problema Antes de Construir tu App (El Primer Paso de Verdad)
La mayoría de founders se lanzan directamente al modo solución. Tienen una idea, empiezan a esbozar pantallas, piden presupuestos a developers y solo mucho después — normalmente cuando el producto ya está construido y nadie lo usa — se hacen la pregunta que deberían haber hecho primero: *¿este problema existe de verdad, a la escala que asumí, para las personas que asumí?*
Por eso CB Insights, en su análisis actualizado de 2024 sobre 431 startups fallidas respaldadas por venture capital, concluyó que el poor product-market fit sigue siendo la principal causa de fracaso de startups, con un 43%. Las startups no fracasaron porque se quedaron sin dinero, aunque muchas lo hicieron. Se quedaron sin dinero porque construyeron algo que el mercado no quería lo suficiente como para pagar.
La solución no es mejor ejecución. Es mejor secuencia: valida el problema antes de construir la solución.
Validación de Problema vs. Validación de Idea: Una Distinción que Importa
La mayoría de founders creen que están validando cuando presentan su idea a amigos y reciben reacciones positivas. Eso no es validación. Es teatro de investigación de mercado.
La validación de idea pregunta: "¿Usará la gente esto?" Es prospectiva e hipotética. Las personas son malas prediciendo su comportamiento futuro, lo que hace que las respuestas sean poco fiables.
La validación de problema pregunta: "¿Existe este dolor hoy? ¿Con qué frecuencia? ¿Qué está haciendo la gente al respecto? ¿Qué les cuesta?" Es retrospectiva y concreta. Las personas son mucho más precisas cuando describen lo que ya les ha ocurrido.
Tu objetivo en las primeras dos a cuatro semanas no es validar tu solución. Es validar que el problema es real, frecuente, doloroso y actualmente lo suficientemente no resuelto como para que la gente pague por una respuesta mejor.
Las Seis Preguntas que Separan un Problema Real de una Conversación Amable
Cuando te sientes con un usuario potencial, resiste la tentación de explicar tu idea. En cambio, pregunta sobre su experiencia con el dominio del problema. Estas seis preguntas producen la señal más útil:
- Cuéntame la última vez que esto fue un problema para ti. (Fuerza un recuerdo específico, no una opinión general.)
- ¿Con qué frecuencia ocurre esto? (La frecuencia determina si vale la pena resolverlo.)
- ¿Qué has intentado para resolverlo? (Revela las soluciones actuales y su calidad.)
- ¿Qué te costó eso — en tiempo, dinero o frustración? (Cuantifica el dolor.)
- ¿Qué pasaría si no pudieras resolverlo en absoluto? (Prueba cuánto les importa.)
- ¿Has pagado alguna vez por una solución, aunque sea parcial? (La señal más clara de todas.)
No les estás pidiendo que evalúen tu idea. Estás escuchando la forma del problema.
¿Cuántas Conversaciones Necesitas?
La investigación de producttalk.org y los datos de Pillar VC sugieren que para productos B2C, normalmente alcanzas la saturación de patrones — el punto en el que las nuevas entrevistas dejan de producir nuevos insights — entre la entrevista 12 y 15. Para productos B2B, el número es mayor: 25 a 30 conversaciones, porque el panorama de decisiones es más complejo y varía más según el tamaño de la empresa, el rol y la industria.
El objetivo no es un número fijo. El objetivo es la saturación. Cuando tres entrevistas consecutivas no producen nada que no hayas oído antes, tienes suficiente para formar una hipótesis sólida.
La Trampa de la Amabilidad: Por Qué el Feedback Positivo No Es Validación
El resultado más peligroso de las entrevistas de problema son los falsos positivos. Las personas son naturalmente amables. Cuando describes un problema, muchos estarán de acuerdo en que suena molesto. Cuando describes una solución, muchos dirán que suena útil. Nada de esto significa que la vayan a usar, y casi nada significa que vayan a pagar por ella.
Aquí están las señales que significan algo, ordenadas de más débil a más fuerte:
Débil (no las cuentes): - "Eso suena muy interesante." - "Probablemente lo usaría." - "Mucha gente que conozco tiene ese problema." - "Mantenme informado."
Más fuerte (presta atención): - Describen una instancia específica y reciente del problema sin necesidad de preguntarlo. - Ya tienen una solución provisional, por torpe que sea — esto significa que el problema es lo suficientemente real como para que se hayan molestado en arreglarlo ellos mismos. - Te preguntan cuándo estará disponible. - Se ofrecen a presentarte a otras personas que tienen el mismo problema.
Más fuerte (trátalo como señal positiva sólida): - Actualmente pagan por una solución parcial y no están satisfechos. - Se ofrecen a pagarte ahora, antes de que hayas construido nada. - Cambian su comportamiento basándose en la conversación.
Tabla de Señales Positivas vs. Negativas
| Lo que dicen | Lo que significa |
|---|---|
| "Suena interesante" | Señal negativa — amable, no validado |
| "Actualmente pago X€ por una solución peor" | Señal positiva — dolor real, gasto real |
| "Quizás algún día" | Señal negativa — baja urgencia |
| "¿Cuándo me puedo apuntar?" | Señal positiva — alta urgencia |
| "Le conté tu idea a mi colega" | Señal positiva — ya está evangelizando |
| "He probado tres cosas y ninguna funciona" | Señal positiva — problema activo, mercado insatisfecho |
Del Problema Validado al Siguiente Paso
Has validado el problema. Tienes 15 conversaciones de insights con patrones consistentes. Sabes que el problema es real, frecuente y lo suficientemente caro como para que la gente ya esté pagando por soluciones imperfectas.
Ahora la pregunta es: ¿cuál es la versión más pequeña que puedes construir para testar tu solución? Ahí es donde empieza la definición del alcance del MVP — y es una habilidad precisa, no una suposición.
---
*El Módulo 1 de Appsademia cubre la validación de problemas e ideas en detalle — incluyendo el framework exacto de entrevistas, cómo reclutar participantes y cómo convertir tus hallazgos en un brief de MVP que tu desarrollador pueda usar. Acceso único, €79.*