Qué resuelve el discovery (y qué no)
Discovery existe para responder cuatro preguntas antes de invertir semanas de desarrollo: ¿el problema es real?, ¿la solución aporta valor?, ¿la persona puede usarla?, ¿el negocio la sostiene? Marty Cagan y Teresa Torres describen esta práctica como continua: pequeñas apuestas, evidencia rápida y decisiones frecuentes.
Lo que discovery no resuelve: no te da certeza, no elimina la política interna de la organización y no reemplaza tu criterio. Reduce el costo de equivocarte, no la incomodidad de descubrir que estabas equivocado.
El ciclo real: hipótesis, evidencia, decisión
Un ciclo de discovery sano es corto y explícito. Se escribe la hipótesis antes de mirar los datos, se define qué resultado la invalidaría y se decide con lo aprendido, no con lo que ya se quería hacer.
- Enmarca el resultado buscado (outcome), no la funcionalidad pedida (output).
- Escribe la hipótesis con un criterio de invalidación: qué evidencia te haría cambiar de opinión.
- Elige el método más barato que responda la pregunta: entrevista, prototipo, prueba de humo, análisis de datos existentes.
- Documenta la decisión y el motivo: sin esa memoria, el equipo repite la misma discusión cada mes.
Punto de partida
- Sin discovery
- Feature pedida
- Con discovery continuo
- Problema y resultado esperado
Evidencia
- Sin discovery
- Opinión del más senior
- Con discovery continuo
- Usuarios, datos y experimentos
Riesgo
- Sin discovery
- Se descubre al lanzar
- Con discovery continuo
- Se descubre en días
Conversación
- Sin discovery
- Defender el roadmap
- Con discovery continuo
- Compartir lo aprendido
Stakeholders: donde el discovery se cae de verdad
La mayoría de PMs no pierde el discovery en la investigación: lo pierde en la reunión. La evidencia dice una cosa, el stakeholder ya comprometió la feature con un cliente y el PM elige entre tener razón o conservar la relación.
Ahí el trabajo deja de ser metodológico y pasa a ser humano: sostener una conversación difícil sin pelear, mostrar evidencia sin humillar a quien se equivocó, negociar alcance sin autoridad formal. Eso no se aprende leyendo: se practica.
- Separa el dato de la interpretación: primero acuerden qué muestra la evidencia.
- Ofrece una alternativa más pequeña antes de negar la solicitud completa.
- Nombra el riesgo en términos del negocio de tu interlocutor, no del tuyo.
- Pide un criterio de decisión compartido: qué resultado haría que ambos cambien de rumbo.
Los cuatro patrones que arruinan un buen discovery
Con equipos de producto en Lima aparecen casi siempre los mismos cuatro: sesgo de confirmación (solo ves lo que confirma tu hipótesis), apego a la solución (defiendes tu idea, no el problema), incomodidad con la incertidumbre (decides rápido para dejar de sentirla) e influencia sin autoridad (cedes ante quien tiene más poder en la sala).
Son patrones de comportamiento, no de conocimiento. Por eso reconocerlos en una lista no basta: hay que verlos apareciendo en ti mientras decides bajo presión.
Dónde practicarlo con casos reales
RECO Product Lab es un taller presencial en Lima para PM, PO, UX y Growth: una simulación donde tu hipótesis se cae con datos y un stakeholder ya prometió la feature. No hay slides de frameworks: hay decisiones tuyas y observación de lo que aparece en ti.
Si quieres ver primero cómo se ve esa conversación, lee la conversación real entre un PM y un stakeholder. Y si te interesa llevarlo a tu equipo completo, existe la versión In Company.
Product Discovery con IA: qué cambia y qué no
La IA acelera lo mecánico: sintetizar entrevistas, agrupar feedback, redactar hipótesis, generar variantes de prototipo. Eso libera tiempo real de discovery.
Lo que no cambia: decidir qué pregunta vale la pena responder, sostener la conversación con quien no quiere escuchar la evidencia y asumir la responsabilidad de la decisión. La IA te da más opciones; el criterio sigue siendo tuyo.
Preguntas frecuentes
¿Qué es Product Discovery en pocas palabras?
Es el trabajo continuo de reducir incertidumbre antes de construir: formular hipótesis, buscar evidencia con usuarios y datos, y decidir con lo aprendido. No es una fase inicial ni un documento, es una práctica permanente del equipo.
¿Cuál es la diferencia entre discovery y delivery?
Discovery responde qué vale la pena construir y por qué; delivery se ocupa de construirlo bien. En equipos maduros ocurren en paralelo y de forma continua, no en fases separadas.
¿Cuánto dura un ciclo de discovery?
Días, no meses. Si una hipótesis necesita semanas para probarse, casi siempre está mal formulada: conviene partirla en una pregunta más pequeña que se pueda responder con evidencia barata.
¿Qué hago si el stakeholder ya prometió la feature?
Acuerden primero qué muestra la evidencia, luego ofrece una versión más pequeña que permita aprender sin romper el compromiso, y nombra el riesgo en términos del negocio de esa persona. La habilidad clave es sostener la conversación sin pelear ni ceder por completo.
¿Dónde puedo practicar Product Discovery en Lima?
En RECO Product Lab, taller presencial de RECOProgramando para PM, PO, UX y Growth: una simulación donde practicas hipótesis, experimentación y conversaciones con stakeholders con casos reales, no con teoría.