Product discovery: Difference between revisions
Created page with "{{Meta-bok|min=5}} El '''product discovery''' (descubrimiento de producto) es el proceso continuo de investigar, validar y aprender sobre los problemas de los usuarios y las oportunidades de negocio antes de comprometer recursos en la construcción de una solución. Su objetivo no es definir qué construir: es reducir la incertidumbre sobre si lo que se va a construir merece construirse. El término fue popularizado por Marty Cagan (''Inspired'', 2017) y Teresa Torres (..." |
No edit summary |
||
| Line 33: | Line 33: | ||
'''Tratar el discovery como una fase que se hace al inicio del proyecto y luego se cierra.''' El discovery continuo de Torres propone una cadencia semanal de entrevistas con usuarios como práctica estable, no como actividad puntual. Los mercados cambian y las hipótesis de producto se invalidan. Un equipo que hizo discovery hace seis meses y lleva meses en delivery puro está acumulando riesgo de desalineamiento con las necesidades reales del usuario. | '''Tratar el discovery como una fase que se hace al inicio del proyecto y luego se cierra.''' El discovery continuo de Torres propone una cadencia semanal de entrevistas con usuarios como práctica estable, no como actividad puntual. Los mercados cambian y las hipótesis de producto se invalidan. Un equipo que hizo discovery hace seis meses y lleva meses en delivery puro está acumulando riesgo de desalineamiento con las necesidades reales del usuario. | ||
</div> | </div> | ||
== Recursos == | |||
<div class="bok-recurso"> | |||
🏦 [https://scrummanager.com/skillarena/customer-discovery '''Discovery y validación con clientes''']<span class="detalle">Skill Arena · Scrum Manager</span> | |||
</div> | |||
== Referencias == | == Referencias == | ||
Latest revision as of 10:53, 20 May 2026
El product discovery (descubrimiento de producto) es el proceso continuo de investigar, validar y aprender sobre los problemas de los usuarios y las oportunidades de negocio antes de comprometer recursos en la construcción de una solución. Su objetivo no es definir qué construir: es reducir la incertidumbre sobre si lo que se va a construir merece construirse.
El término fue popularizado por Marty Cagan (Inspired, 2017) y Teresa Torres (Continuous Discovery Habits, 2021), quienes proponen que el discovery no es una fase previa al desarrollo sino una actividad continua paralela a la entrega.
Discovery vs. delivery
- Discovery (descubrimiento): ¿qué problema merece resolverse? ¿Esta solución funcionará? ¿Es valiosa para el usuario y viable para el negocio?
- Delivery (entrega): construir la solución acordada con calidad y fiabilidad.
El modelo dual-track agile propone ejecutar ambos en paralelo: mientras un track entrega el trabajo comprometido, el otro investiga las oportunidades del siguiente ciclo.
El ciclo de descubrimiento
El discovery sigue un flujo iterativo:
- Enmarcar el problema: separar el síntoma de la causa raíz. Formular el reto desde la perspectiva del usuario, no desde la solución. Herramienta: Jobs to Be Done.
- Mapear supuestos: listar explícitamente los supuestos que subyacen a la solución propuesta (deseabilidad, viabilidad, factibilidad) y priorizarlos por impacto e incertidumbre.
- Diseñar el experimento: elegir el método más eficiente para validar el supuesto más crítico — entrevista, prototipo, MVP de aprendizaje o test A/B.
- Evaluar la evidencia: analizar resultados con escepticismo, distinguiendo patrones de ruido y correlación de causalidad.
- Decidir: perseverar, iterar, pivotar o parar, capturando el aprendizaje independientemente del resultado.
Herramientas habituales
- Interview snapshots para acumular aprendizaje de entrevistas con usuarios.
- Árbol de soluciones de oportunidades para organizar oportunidades, soluciones y experimentos.
- Mapa de historias para conectar el discovery con el backlog.
- Mínimo Producto Viable para validar hipótesis con el mínimo esfuerzo.
Error frecuente
Tratar el discovery como una fase que se hace al inicio del proyecto y luego se cierra. El discovery continuo de Torres propone una cadencia semanal de entrevistas con usuarios como práctica estable, no como actividad puntual. Los mercados cambian y las hipótesis de producto se invalidan. Un equipo que hizo discovery hace seis meses y lleva meses en delivery puro está acumulando riesgo de desalineamiento con las necesidades reales del usuario.
Recursos
🏦 Discovery y validación con clientesSkill Arena · Scrum Manager
Referencias
- Cagan, Marty. (2017). Inspired: How to Create Tech Products Customers Love. Wiley.
- Torres, Teresa. (2021). Continuous Discovery Habits. Product Talk LLC.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.