CB Insights publica un análisis anual de por qué fracasan las startups. Durante años, la razón número uno ha sido la misma: «no hay necesidad de mercado». No la mala ejecución. No quedarse sin dinero. No un mal equipo. El producto simplemente no resolvía un problema que a la gente le importara lo suficiente como para cambiar su comportamiento.
Esa estadística es asombrosa cuando se considera cuánto esfuerzo se invierte en construir productos. Los equipos pasan meses — a veces años — diseñando sistemas, escribiendo código, debatiendo sobre arquitectura y perfeccionando flujos. Y la razón más común por la que fracasan es que nadie preguntó si todo eso estaba resolviendo un problema real.
Crear productos que la gente realmente quiere no es un talento. Es una disciplina. Tiene un método, y ese método puede aprenderse.
El error de producto más común es enamorarse de una solución antes de comprender profundamente el problema. Esto es casi universal entre los fundadores primerizos y sorprendentemente común entre los experimentados. El patrón es siempre el mismo: alguien tiene una idea, le parece convincente y empieza a construir. El cliente es una ocurrencia tardía — alguien a quien convencer, no a quien entender.
El antídoto no es complicado, pero requiere disciplina: dedica más tiempo al problema del que crees necesario, antes de considerar soluciones en absoluto. Habla con personas que tienen el problema. Obsérvales trabajar. Comprende las soluciones provisionales que utilizan hoy y por qué esas soluciones son imperfectas. Solo entonces tendrás suficiente contexto para diseñar algo que realmente encaje.
El buen desarrollo de producto no es una línea recta — es un ciclo. Cada iteración en el ciclo es una oportunidad de reemplazar suposiciones por evidencia. Los equipos que crean productos que la gente quiere son los que completan este ciclo rápida y frecuentemente.
El ciclo no es una formalidad. Cada etapa tiene un resultado específico que se convierte en la entrada de la siguiente. Saltarse etapas — lo más habitual es pasar directamente del Problema a Construir — es lo que produce productos que no dan en el blanco.
No todos los problemas merecen resolverse. Un buen problema de producto tiene tres cualidades: es frecuente (afecta a las personas a menudo, no raramente), es intenso (la gente lo siente lo suficiente como para querer alivio) y las soluciones existentes son genuinamente inadecuadas (no solo ligeramente diferentes de lo que construirías).
El error es optimizar para la primera cualidad e ignorar las dos últimas. «La gente pierde el tiempo en reuniones» es frecuente. Pero si el dolor es bajo — si la gente ha encontrado soluciones provisionales suficientemente buenas — el problema puede no merecer la pena resolverse comercialmente. Y si ya existen doce herramientas haciendo lo que quieres hacer, necesitas una razón muy específica para que la tuya sea elegida.
La investigación tiene mala reputación en los círculos de producto — se asocia con consultoras lentas, informes voluminosos y hallazgos que nadie lee. Eso es un fallo de ejecución, no de la práctica. La buena investigación de producto es rápida, específica y cambia lo que construyes.
El objetivo de la investigación no es confirmar que el problema es real. Ya deberías creer eso antes de invertir mucho en investigación. El objetivo es comprender el problema lo suficientemente bien como para saber cómo se ve una buena solución: quién específicamente tiene el problema, en qué contexto, qué han probado ya, qué palabras usan para describirlo y cómo sería «resuelto» para ellos.
Una hipótesis es una predicción específica y falsable sobre lo que crees que es verdad. Fuerza la claridad. Si no puedes escribir una hipótesis clara, aún no comprendes el problema lo suficientemente bien como para construir una solución.
Una hipótesis de producto útil tiene tres partes:
La señal es la parte más importante — y la más frecuentemente omitida. Sin una señal predeterminada, cada experimento «funcionó más o menos». Los equipos encuentran maneras de interpretar los datos ambiguos favorablemente. Una hipótesis sin una condición de falsificación es simplemente un deseo.
La fase de construcción es donde la mayoría de los equipos pasan demasiado tiempo. El objetivo no es construir el producto — es construir lo mínimo que te dará señal sobre tu hipótesis. Estos son objetivos diferentes y producen resultados muy distintos.
Para la mayoría de las hipótesis en etapas tempranas, el mínimo es mucho menos de lo que los equipos piensan. ¿Puedes hacer manualmente lo que haría el software, para diez personas, para probar si valoran el resultado? ¿Puedes conectar herramientas existentes y probar el flujo de trabajo antes de construir nueva infraestructura? ¿Puedes esbozar un prototipo y revisarlo con cinco usuarios antes de escribir cualquier código?
La disciplina aquí es preguntar, antes de construir cualquier cosa: «¿Qué estoy intentando aprender?» y «¿Cuál es lo mínimo que me permitiría aprenderlo?» La respuesta casi siempre es más pequeña de lo que el equipo quiere construir.
Después del lanzamiento — ya sea un prototipo, un piloto manual o una funcionalidad desplegada — la fase de medición es donde los equipos se engañan más comúnmente. Preguntan a los usuarios si les gustó. Los usuarios dicen que sí. El equipo marca el experimento como validado.
El sentimiento no es señal. La única señal fiable es el comportamiento: ¿hizo la gente lo que tenía que hacer? ¿Volvieron? ¿Pagaron? ¿Lo contaron a alguien?
Para la medición cuantitativa, instrumenta antes de lanzar. Sabe qué acciones específicas estás rastreando. Establece un umbral de antemano — «consideraremos esto validado si el X% de los usuarios completa Y dentro de Z días». Para la medición cualitativa, realiza entrevistas de seguimiento estructuradas, no encuestas de satisfacción abiertas.
La fase de aprendizaje consiste en actualizar tu modelo mental del usuario y el problema, no solo en decidir qué construir a continuación. Los equipos que se saltan este paso recopilan datos pero no acumulan comprensión. Ejecutan rápidamente pero no mejoran su juicio con el tiempo.
Una buena sesión de aprendizaje pregunta: ¿Qué predijimos? ¿Qué ocurrió realmente? ¿Qué nos dice la brecha sobre nuestras suposiciones? ¿Cuál es ahora la cosa más importante que no sabemos?
El resultado de la fase de aprendizaje es una definición del problema más nítida, una hipótesis revisada o — si el experimento claramente fracasó — una decisión de seguir una dirección completamente diferente. Todos estos resultados son valiosos. El peor resultado es la ambigüedad: «aprendimos algunas cosas pero no estamos seguros de qué hacer a continuación». Eso es una señal de que el experimento no fue suficientemente específico.
El desarrollo de producto nunca llega a una etapa en la que dejes de ejecutar este ciclo. Las preguntas cambian — al principio estás validando si el problema es real; más tarde estás validando si un elemento específico de la solución está funcionando — pero la estructura es siempre la misma. Observar, hipotetizar, probar, aprender.
Los equipos que crean productos que la gente quiere no son los que tienen el insight inicial más ingenioso. Son los que completan el ciclo más rápido y con más honestidad. La velocidad de aprendizaje, no la velocidad de envío, es la ventaja competitiva.