Un framework simple 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.
Eso no es lo que necesitan los founders early-stage.
Antes de tener un equipo, un roadmap o un producto, necesitás responder una pregunta: ¿vale la pena construir esto? Eso requiere un tipo diferente de framework — uno construido para velocidad, honestidad y cero suposiciones.
Este es el framework alrededor del que construimos Scoutr.
¿Querés correr este framework ahora mismo? Empezá tu proceso de discovery →
El principio central
La mayoría de los founders fracasa no porque no pueden construir, sino porque construyen lo que no corresponde. Tienen una idea, se enamoran de la solución, y pasan meses construyendo algo que el mercado no necesita.
El antídoto es simple pero incómodo: retrasar la construcción todo lo posible, y usar ese tiempo recopilando evidencia.
Evidencia, no opiniones. Evidencia significa comportamiento — qué hacen actualmente las personas, qué pagan actualmente, qué toleran actualmente. Las opiniones ("lo usaría," "suena copado") no son evidencia.
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 podés describir a una persona real que tenga este problema, no tenés un usuario objetivo — tenés una hipótesis. Empezá ahí.
Qué buscás: Una persona específica y alcanzable cuya situación entendés 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é buscás: 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.
Qué buscás: Al menos cinco conversaciones donde el problema apareció sin que lo sugirieras, descripto en términos específicos y emocionales. Los patrones en múltiples conversaciones son significativos. Las anécdotas individuales no lo son.
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 — sabés que el problema vale la pena pagar para resolverlo. La pregunta se convierte en si podés resolverlo mejor.
Si nadie está pagando actualmente nada para abordar este problema, preguntate 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.
Qué buscás: Evidencia de gasto actual — suscripciones, costos de contratistas, herramientas internas — en tu segmento objetivo.
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," eso es una señal de que 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," eso dice algo diferente.
Qué buscás: Evidencia de que el problema crea urgencia — que el usuario está peor sin una solución y lo sabe.
Pregunta 6: ¿Por qué sos la persona indicada para resolver esto?
Esta no es una pregunta de confianza. Es una pregunta de distribución e insight. ¿Entendés algo sobre este problema que otros no entienden? ¿Tenés acceso a usuarios que otros no tienen? ¿Hay alguna razón por la que serías mejor resolviendo esto que alguien que acaba de ver la misma oportunidad?
Las ventajas injustas en startups early-stage suelen venir de experiencia en el dominio, distribución o insight único sobre el problema. Si no tenés una de estas, eso no significa que no debas construir — pero es algo relevante para entender sobre tu posición.
Qué buscás: Una respuesta específica, no una genérica. "Trabajé en este espacio durante cinco años" es un comienzo. "Conozco a las 50 personas que tienen este problema y ya confían en mí" es más fuerte.
Cómo usar este framework
Las seis preguntas funcionan mejor cuando se responden honestamente — no con las respuestas que desearías que fueran verdad, sino con la evidencia que realmente tenés.
Recorré el framework dos veces:
Primera vez: Respondé cada pregunta con lo que sabés actualmente. Marcá 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.
Lo que este framework no es
No es un sustituto para construir. En algún momento, tenés que lanzar algo y ver cómo los usuarios reales interactúan con ello. El framework existe para asegurarte de que estás construyendo lo correcto — no para darte razones infinitas para postergar.
No es una garantía. Podés responder bien las seis preguntas y aun así construir algo que no funciona. Los mercados son inciertos. El framework reduce el riesgo; no lo elimina.
No es algo de una sola vez. El discovery continúa después de que lanzás. Las preguntas cambian, pero la disciplina de hacerlas no.
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 — tenés una idea, pero todavía no hablaste con usuarios reales — ese es exactamente el lugar por dónde empezar.