Dog Toy vs Botella de Plástico: Lo que mi perra me enseñó sobre product discovery
Hace unos meses vi a mi perra pasar cuarenta minutos jugando con una botella de agua de plástico vacía.
No era un juguete. No era algo que compré ni diseñé ni testeé. Era una botella que había terminado y tirado al piso. Ella la golpeó por el cuarto. La persiguió. La agarró, la sacudió, la soltó, y empezó de nuevo. Estaba completamente absorbida.
Mientras tanto, el juguete de perro que compré — el que tenía la tela crujiente y el squeaker y el diseño colorido — estaba en su canasta, sin tocar.
En el momento no le presté mucha atención. Pero después se convirtió en la manera más clara que conozco para explicar el error más común que cometen los founders antes de construir algo.
El juguete que nadie pidió
El juguete estaba bien hecho. Lo diseñaron personas que conocen a los perros. Se lo vendieron a personas que aman a los perros. Estaba al lado de una perra. Y aun así — nada.
La botella de plástico, en cambio, fue un accidente. Nadie la investigó. Nadie la prototipó. Nadie hizo A/B testing con la forma. Simplemente resultó ser el peso correcto, la textura correcta, el sonido correcto, la resistencia correcta cuando ella la mordía. Resolvía algo real. Algo que su cuerpo ya quería.
Esta es la diferencia entre un producto que alguien pensó que iba a funcionar y un producto que resuelve un problema que ya existe.
El juguete fue construido alrededor de suposiciones. La botella fue descubierta.
El error que cometen la mayoría de los founders
La mayoría de los founders empieza con el juguete. Tienen una idea. La piensan bien. Hablan con algunas personas que dicen "sí, eso suena útil." Construyen.
Seis meses después, lanzan. Nadie aparece.
El problema no fue la ejecución — fue que nunca confirmaron que el problema de fondo era real. Lo suficientemente real, doloroso y común como para que la gente ya estuviera haciendo algo al respecto, aunque mal.
La botella era un workaround. Mi perra tenía un problema — algo para morder, algo que hiciera ruido, algo que pudiera perseguir — y lo resolvió con lo que tenía disponible. Ese workaround es la señal de demanda.
Cuando la gente ya está resolviendo un problema con algo inadecuado, eso es evidencia. El mercado te está diciendo que el problema es real y que las soluciones existentes no son suficientes.
¿Querés mapear las señales de demanda reales alrededor de tu idea antes de construir? Corré tu idea por el flujo de discovery de Scoutr →
Qué es realmente el product discovery
El product discovery no es una fase en un sprint. No es una metodología de investigación. En el fondo, es hacerse una sola pregunta:
¿Es este problema lo suficientemente real como para que la gente ya esté sufriendo con él?
No "¿usarías esto?" — eso es la versión encuesta, y te da síes amables de personas que no te quieren decepcionar.
La pregunta real es comportamental: ¿qué está haciendo la gente ahora mismo para resolver este problema? ¿Qué planilla están manteniendo que odian? ¿Qué proceso están corriendo manualmente que debería estar automatizado? ¿Qué herramienta están hackeando para hacer algo para lo que no fue diseñada?
Esos workarounds son botellas de plástico. Son soluciones feas e imperfectas a problemas reales. Y son una de las señales de demanda más confiables que tenés disponibles antes de escribir una sola línea de código.
El error de discovery que es fácil de pasar por alto
Acá está la versión sutil del mismo error.
A veces encontrás la botella de plástico. Ves el workaround. Entendés el problema. Construís el producto. Y después construís el juguete de $18 en lugar de la botella de plástico.
Lo que quiero decir: resolvés el problema real, pero lo resolvés para la persona levemente equivocada, al precio levemente equivocado, con el packaging levemente equivocado. El insight central era correcto, pero en algún punto de la traducción de problema a producto, optimizaste para lo que parecía razonable en lugar de lo que el usuario real necesitaba.
Por eso el discovery no termina cuando empezás a construir. Continúa — en cada decisión de diseño, en cada elección de feature, en cada conversación de pricing. Siempre te estás preguntando: ¿esto todavía refleja el problema real, o me estoy alejando hacia lo que imagino que el usuario quiere?
Un framework simple que no requiere una planilla
Cuando estoy poniendo a prueba una idea, uso tres preguntas:
1. ¿Qué está haciendo la gente ahora mismo para resolver este problema? Si la respuesta es "nada" — o el problema no es real, o no es lo suficientemente doloroso. Los problemas reales se resuelven, aunque sea mal. Encontrá el workaround.
2. ¿Por qué ese workaround es doloroso? Acá es donde encontrás el espacio que puede llenar tu producto. El workaround funciona, pero ¿a qué costo? ¿Tiempo? ¿Dinero? ¿Incomodidad? ¿Fragilidad? Cuanto más específico puedas ser sobre el dolor, más claramente podés ver qué significa "mejor".
3. ¿Quién tiene este problema lo suficientemente fuerte como para pagar para resolverlo? No todo el mundo con un problema va a pagar para solucionarlo. Algunos problemas son molestos pero tolerables. Otros son bloqueantes — el trabajo no puede continuar, los ingresos están en riesgo, algo importante se rompe. Querés los bloqueantes. Ahí es donde vive la disposición a pagar.
Tres preguntas. Sin slides. Sin fase de investigación. Sin design sprint. Solo lo suficiente para saber si el problema es real antes de pasar meses construyendo una solución.
La botella ya está ahí
Lo que hace que el product discovery parezca difícil es que parece que estás buscando algo que podría no existir. ¿Y si no hay demanda? ¿Y si el problema no es real? ¿Y si hacés todo este trabajo y no encontrás nada?
Pero lo que aprendí es esto: si el problema es real, la botella ya está ahí. Alguien ya lo está resolviendo mal. Solo tenés que encontrarlo.
Las comunidades donde la gente se queja del problema. Los threads de Reddit donde comparten workarounds. Las secciones de comentarios de Hacker News donde describen cómo lo están manejando. Los avisos de trabajo que insinúan con qué está luchando una empresa. Las planillas que comparten en canales de Slack porque la solución "real" cuesta demasiado.
Las señales están por todos lados. La parte difícil no es encontrarlas — es ser honesto sobre lo que te dicen.
scoutr analiza señales reales en Reddit, Hacker News y datos de competidores para decirte si tu idea resuelve un problema real antes de que construyas algo. Probalo gratis →