Casi nadie fracasa por escribir mal el código. Fracasan por escribirlo demasiado pronto.
Es un patrón que se repite. Alguien invierte seis meses, a veces más, en construir un producto que funciona de maravilla. Está bien programado, se ve bien, hace lo que promete. Y no lo quiere nadie. El problema no estaba en el desarrollo. Estaba en todo lo que no se preguntó antes de empezar a desarrollar.
Por eso, cuando un fundador llega con ganas de construir, lo primero que hacemos es frenarle. Se sienta y responde a siete preguntas. Ninguna va de tecnología. Todas van de lo mismo: si existe alguien ahí fuera con un problema de verdad y dispuesto a pagar por quitárselo de encima.
Si te cuesta responder alguna, buena señal. Significa que la has encontrado a tiempo, mientras arreglarla todavía es barato.
1. ¿Qué problema resuelves?
Ojo, la pregunta no es qué producto quieres construir. Es qué dolor concreto le quitas a alguien.
Son cosas distintas y se confunden constantemente. «Una app para gestionar equipos» es un producto. «Los mandos intermedios pierden dos horas cada lunes recomponiendo a mano lo que su equipo hizo la semana anterior» es un problema. Si tu respuesta no cabe en una frase que otra persona entienda a la primera, todavía no lo tienes claro del todo.
2. ¿Quién lo tiene?
Un perfil concreto: sector, cargo, situación en la que está cuando el problema aparece.
La respuesta que más deberías temer es «todo el mundo». No porque sea ambiciosa, sino porque casi siempre es la respuesta de quien aún no ha hablado con nadie. Cuando has tenido diez conversaciones reales, dejas de hablar de «todo el mundo» y empiezas a hablar de «responsables de operaciones en empresas de logística de menos de cincuenta personas». Eso ya se puede buscar. Eso ya se puede vender.
3. ¿Cuánto le duele?
No todos los problemas valen lo mismo. Hay molestias con las que la gente convive sin más, y hay cosas que le quitan el sueño.
La pregunta incómoda es en cuál de las dos categorías cae el tuyo. Si el problema no arde, nadie va a pagar por apagarlo. Va a asentir cuando se lo cuentes, te va a decir que qué buena idea, y no va a soltar un euro. Un problema tibio es la forma más educada que tiene el mercado de decirte que no.
4. ¿Qué hace hoy para resolverlo?
Todo el que tiene un problema real ya está haciendo algo para apañárselo. Un Excel infinito, un becario dedicado a copiar y pegar, tres apps distintas pegadas con celo.
Esa chapuza es tu mejor noticia. Quiere decir que el dolor es suficiente como para haberse buscado la vida. Y ahí tienes, además, contra qué compites de verdad: no contra otra startup, sino contra el apaño que ya le funciona a medias. Si preguntas y descubres que hoy no hace absolutamente nada, plantéate en serio si le duele tanto como pensabas.
5. ¿Cuánto pagaría?
Esta se pregunta mal casi siempre. Se pregunta en abstracto, «¿pagarías por algo así?», y la respuesta educada es que sí.
Ponle una cifra encima de la mesa. Una concreta. «¿Pagarías 200 euros al mes por esto?» separa a quien tiene el problema de quien solo te está dando conversación. «Me interesa» no es un precio, y un «sí» sin número detrás no te sirve para construir un negocio.
6. ¿Por qué canal llegas a él?
Aunque tengas la mejor solución del mundo, si no sabes por dónde alcanzar a quien la necesita, no existe.
Esta es la pregunta que más se salta y la que más caro se paga después. ¿Dónde está esa persona? ¿Qué lee, a quién escucha, en qué momento estaría abierta a escucharte? Un canal es lo que te permite llegar a tu cliente de forma repetible, sin depender de que un día tuviste suerte en una comida. Sin eso, tener la solución da bastante igual.
7. ¿Cuánta gente hay así?
Y por último, el número. Cuántas personas encajan de verdad en el perfil que has descrito.
Es la pregunta que da más pereza porque toca hacer cuentas en vez de soñar, pero conviene hacerla antes de enamorarse de la idea. Diez clientes ideales no son un mercado, son diez conversaciones buenas. Necesitas saber si detrás hay cien, mil o cien mil, porque eso cambia por completo si esto es un proyecto o un pasatiempo caro.
Ninguna es sobre código
Vuelve a leerlas. Ninguna de las siete habla de tecnología, de stack, de si usar tal framework o tal otro. Todas hablan de si hay negocio debajo.
Y esa es justo la razón por la que funcionan. Responderlas con honestidad te dice, antes de gastar un euro en producto, si alguien tiene el problema y pagaría por resolverlo. Si fallas una, la arreglas. Si las fallas todas, no has fracasado: acabas de ahorrarte seis meses de tu vida y bastante dinero.
Guárdalas para tu próxima idea. Mejor aún, respóndelas antes de la próxima idea.
