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 impresionante cuando se considera cuánto esfuerzo se mete 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 entender a fondo 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 buenísima 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: dediquen más tiempo al problema del que creen necesario, antes de considerar soluciones. Hablen con personas que tienen el problema. Obsérvenlas trabajar. Entiendan los arreglos temporales que usan hoy y por qué esos arreglos son imperfectos. Solo entonces tienen 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ápido y seguido.
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 común es pasar directo del Problema a Construir — es lo que produce productos que no dan en el blanco.
No todos los problemas valen la pena resolverse. Un buen problema de producto tiene tres cualidades: es frecuente (afecta a las personas seguido, no rara vez), es intenso (la gente lo siente suficiente como para querer alivio) y las soluciones existentes son genuinamente inadecuadas (no solo un poco diferentes de lo que construirían).
El error es optimizar para la primera cualidad e ignorar las otras dos. "La gente pierde el tiempo en juntas" es frecuente. Pero si el dolor es bajo — si la gente encontró soluciones temporales suficientemente buenas — el problema puede no valer la pena resolverse comercialmente. Y si ya existen doce herramientas haciendo lo que quieren hacer, necesitan una razón muy específica para que la suya sea elegida.
La investigación tiene mala reputación en los círculos de producto — se asocia con consultoras lentas, informes gruesos 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 construyen.
El objetivo de la investigación no es confirmar que el problema es real. Ya deberían creer eso antes de invertir mucho en investigación. El objetivo es entender 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 creen que es verdad. Fuerza la claridad. Si no pueden escribir una hipótesis clara, aún no entienden 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 que más seguido se omite. Sin una señal predeterminada, cada experimento "más o menos funcionó". 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 les dará señal sobre su hipótesis. Estos son objetivos diferentes y producen resultados muy distintos.
Para la mayoría de las hipótesis en etapas tempranas, lo mínimo es mucho menos de lo que los equipos piensan. ¿Pueden hacer manualmente lo que haría el software, para diez personas, para probar si valoran el resultado? ¿Pueden conectar herramientas existentes y probar el flujo de trabajo antes de construir nueva infraestructura? ¿Pueden esbozar un prototipo y revisarlo con cinco usuarios antes de escribir cualquier código?
La disciplina acá 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 más seguido se engañan. Le 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 confiable es el comportamiento: ¿hizo la gente lo que tenía que hacer? ¿Volvieron? ¿Pagaron? ¿Lo contaron a alguien?
Para la medición cuantitativa, instrumenten antes de lanzar. Sepan qué acciones específicas están rastreando. Establezcan 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, realicen entrevistas de seguimiento estructuradas, no encuestas de satisfacción abiertas.
La fase de aprendizaje consiste en actualizar su 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ápido pero no mejoran su criterio con el tiempo.
Una buena sesión de aprendizaje pregunta: ¿Qué predijimos? ¿Qué pasó 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 clara, 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 señal de que el experimento no fue suficientemente específico.
El desarrollo de producto nunca llega a una etapa donde dejen de correr este ciclo. Las preguntas cambian — al inicio están validando si el problema es real; más adelante están 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 entrega, es la ventaja competitiva real.