¿Cómo hacer el Product Discovery con Scrum?
Tiempo de lectura: 5 minutos
La mayoría de las iniciativas de producto no fallan por problemas de delivery (construir bien lo que se ha decidido), sino de discovery (decidir qué merece la pena construir). Aquí tienes un modelo práctico para hacer Product Discovery sin salirte de Scrum.
El problema
El Product Discovery es la actividad para descubrir cuál es el producto que de verdad necesitan los usuarios — la palabra "descubrir" no es casual: al principio no lo sabemos, y solo lo confirmamos validándolo con ellos. Junto al Discovery (hacer las cosas correctas) está el Product Delivery: definir, construir y validar el producto (hacer las cosas bien).
El problema habitual es que los equipos dedican casi todo su esfuerzo al delivery y muy poco al discovery. Como regla aproximada, el 80% del riesgo de no entregar el producto que el usuario necesita se puede mitigar dedicando solo un 20% del esfuerzo total a descubrir bien el problema antes de construir; el 20% de riesgo restante se reduce entregando dentro del Sprint y validando con métricas reales una vez el incremento está en manos del usuario.
Herramientas
No hace falta reinventar el proceso: hay herramientas de sobra para estructurar el discovery en cada etapa.
- Para la estrategia de partida, el Lean Canvas ayuda a explicitar en una sola página el problema, el segmento de cliente y la propuesta de valor que se quiere validar.
- Para entender al usuario, el Empathy Map Canvas, el Value Proposition Canvas y el Customer Journey Map permiten pasar de suposiciones a hipótesis concretas sobre necesidades, dolores y momentos clave de uso.
- Para decidir qué construir primero, modelos de priorización como 40-40-20 o el Value Creation Canvas ayudan a repartir esfuerzo entre valor para el cliente, para el negocio y aprendizaje.
- Y el modelo AFI (Assumptions - Faith - Ignorance, o similar) ayuda a hacer explícitas las suposiciones más arriesgadas antes de invertir en construirlas.
Todas estas herramientas comparten el mismo propósito: convertir opiniones internas en evidencias validadas con el usuario, antes de que el coste de equivocarse sea alto.
Modelo lógico
El discovery no es una fase que se hace una vez al principio del producto y se olvida: se repite durante todo su ciclo de vida (lo que a veces se representa con la llamada Truth Curve, la curva de certeza que va creciendo Sprint a Sprint conforme validamos más). Y se puede hacer en paralelo al desarrollo — es el llamado Dual-Track Agile: una línea de discovery, permanentemente uno o dos pasos por delante, y una línea de delivery que construye lo ya validado.
La clave para que este modelo funcione dentro de Scrum es definir objetivos ligados a outcomes del usuario y no solo a funcionalidades entregadas — el llamado Project Logic Model: en vez de medir "cuántas historias hemos cerrado", medir si el resultado que buscábamos en el usuario realmente ha ocurrido. Así el discovery deja de ser una fase aislada previa al Sprint y se convierte en parte del propio flujo de trabajo del Equipo Scrum.
Si quieres profundizar en cómo conectar discovery, estrategia y validación en el día a día de tu producto, sigue con qué son la estrategia, el descubrimiento y la validación en producto digital. El curso Professional Scrum Product Owner y el taller de Product Discovery & Validation Skills de Scrum.org profundizan en estas técnicas de forma práctica.