Framework de product discovery para founders early-stage
La mayoría de los frameworks de product discovery están diseñados para product managers en empresas establecidas. Involucran ciclos de sprint, repositorios de investigación y reuniones de alineación cross-funcional. Los founders early-stage trabajan a una escala distinta y necesitan otro tipo de framework.
Antes de tener un equipo, un roadmap o un producto, la pregunta es si la idea vale la pena construir. El framework que responde esa pregunta tiene que ser barato, rápido y honesto sobre lo que efectivamente sabes.
Este es el framework alrededor del que construimos Scoutr.
Si quieres la teoría más amplia detrás de por qué el discovery funciona así, qué es design thinking cubre la estructura del doble diamante que sustenta todo esto.
¿Quieres correr este framework ahora mismo? Empieza tu proceso de discovery →
El principio central
El discovery es la parte del desarrollo de producto donde la mayoría de los founders pierde meses. La construcción viene después de que el trabajo de discovery está hecho; el modo de falla es invertir tiempo de construcción antes de tener evidencia de que alguien quiere el resultado.
La señal que estás buscando es comportamiento. "Lo usaría" sale gratis en una conversación, así que no carga peso. La evidencia conductual es distinta: lo que la gente paga actualmente, lo que se armaron un fin de semana, lo que toleran de su workaround actual. Esa es la data que el discovery está construido para sacar a la luz.
El framework de discovery de seis preguntas
Este framework toma de tres fuentes: The Mom Test de Rob Fitzpatrick, los consejos de YC a founders en la etapa más temprana, y The Lean Startup de Eric Ries. Está estructurado en seis preguntas porque es el mínimo necesario para tener un panorama completo sin abrumarte con investigación.
Pregunta 1: ¿Quién específicamente tiene este problema?
No "pequeñas empresas." No "profesionales ocupados." Una persona específica: su puesto de trabajo, el tamaño de su empresa, su contexto diario, y por qué este problema aparece para ellos específicamente.
Si no puedes describir a una persona real que tenga este problema, lo que tienes es una hipótesis para testear más que un usuario objetivo. Empieza ahí.
Qué buscas: Una persona específica y alcanzable cuya situación entiendes lo suficientemente bien como para encontrarla y hablar con ella.
Pregunta 2: ¿Cómo lo están resolviendo hoy?
Esta es la pregunta más importante del framework. Si el problema es real y doloroso, la gente ya está haciendo algo al respecto. Tienen un workaround. Están pagando por una solución imperfecta. Están haciendo algo manual que odian.
Esos workarounds son evidencia de demanda. Te dicen que:
- El problema es real (están lo suficientemente motivados como para rodearlo)
- Hay un mercado (ya están gastando tiempo o dinero)
- Hay una apertura (la solución actual no es suficientemente buena)
Qué buscas: Workarounds activos — especialmente los que cuestan dinero o tiempo. Cuanto más doloroso el workaround, más fuerte la señal.
Pregunta 3: ¿Hablaste con alguien que tiene este problema?
No "¿alguien tendría este problema?". ¿Tuviste realmente una conversación con una persona real que lo experimenta? ¿Lo describieron sin que lo sugirieras? ¿Usaron lenguaje emocional?
Esta pregunta existe para forzar la distinción entre suposición y evidencia. La mayoría de los founders está operando en suposiciones hasta que tiene conversaciones reales.
La vara no es una conversación; son cinco, donde el problema apareció sin que lo sugirieras, descripto en términos específicos y emocionales. Una persona despotricando puede ser un mal día. Cinco personas describiendo independientemente el mismo dolor es un patrón sobre el que vale la pena construir.
Pregunta 4: ¿Alguien ya está pagando para resolver esto?
El dinero es la señal más difícil de falsificar. Si la gente está pagando actualmente — por un competidor, por trabajo manual, por un workaround — sabes que el problema vale la pena pagar para resolverlo. La pregunta se convierte en si puedes resolverlo mejor.
Si nadie está pagando actualmente nada para abordar este problema, pregúntate por qué. A veces es porque el problema no es lo suficientemente doloroso. A veces es porque no existe ninguna solución todavía. Esas son situaciones muy diferentes.
La versión más clara de esta señal: alguien en tu segmento objetivo tiene un line item para esto en la tarjeta de la empresa. Suscripción SaaS, factura de contratista, retainer de freelancer, mantenimiento de herramienta interna — cualquier cosa donde el dinero ya se está moviendo para abordar el hueco.
Pregunta 5: ¿Qué harían si tu solución desapareciera?
Esta es una versión en tiempo futuro de la pregunta del workaround, pero formulada de manera diferente. Si tu producto dejara de existir mañana, ¿qué haría tu usuario objetivo?
Si la respuesta es "nada" o "supongo que volvería a hacerlo manualmente", el problema no es lo suficientemente agudo. Si la respuesta es "tendría que contratar a alguien", "todo nuestro proceso se rompería", o "buscaría una alternativa inmediatamente", el problema crea urgencia real.
Qué buscas: Evidencia de que el usuario está peor sin una solución y lo sabe.
Pregunta 6: ¿Por qué tú?
La pregunta real es si tienes distribución injusta o insight injusto. Conocer a las 50 personas con este problema y que ya confíen en ti cuenta como distribución injusta. Cuatro años dentro del workflow viendo el hueco que nadie más notó cuenta como insight injusto. "Soy apasionado por la productividad" no cuenta.
Si no tienes ninguna de las dos hoy, igual puedes construir, pero estás arrancando sin moat y el próximo año de tu vida va a ser ganarte uno.
Cómo usar este framework
Las seis preguntas funcionan mejor cuando se responden con honestidad, contra la evidencia que efectivamente tienes más que con las respuestas que desearías que fueran verdad.
Recorré el framework dos veces:
Primera vez: Responde cada pregunta con lo que sabes actualmente. Marca cada respuesta donde estás especulando en vez de reportando evidencia. Esas son tus prioridades de investigación.
Segunda vez: Después de dos semanas de entrevistas, investigación en comunidades y análisis de competidores, recorré el framework de nuevo. Los huecos deberían ser más pequeños. Si no lo son, esa también es información útil.
Scoutr te lleva por este framework como una conversación, haciendo preguntas de seguimiento, desafiando respuestas débiles, y produciendo un reporte estructurado al final. El reporte cubre las seis áreas, más señales competitivas, dimensionamiento de mercado y próximos pasos recomendados.
Algunas advertencias
El framework reduce el riesgo; no lo elimina. Puedes responder bien las seis preguntas y aun así construir algo que no funciona porque el mercado se mueve por debajo. El framework tampoco reemplaza al lanzamiento. En algún momento tienes que poner algo frente a usuarios reales, porque las respuestas del framework solo te llevan hasta cierto punto. El discovery tampoco termina en el lanzamiento; las preguntas solo cambian de forma.
El error más común
Los founders que recorren este framework por primera vez frecuentemente descubren que no pueden responder la Pregunta 3. Nunca hablaron realmente con alguien que tenga el problema.
Ese es el modo de falla más común en el desarrollo de productos early-stage: construir sobre suposiciones sin nunca testearlas en conversación.
Si estás en ese punto — tienes una idea pero todavía no hablaste con usuarios reales — ese es exactamente el lugar por donde empezar.