El origen: por qué surgió el Dual Track

Dual Track fue popularizado por Jeff Patton. Surgió de observar un patrón problemático: equipos que construían con excelencia técnica productos que nadie necesitaba. El Dual Track no fue concebido como un proceso formal con etapas y entregables, sino como una forma de pensar sobre el trabajo de producto: investigar y construir de forma continua y solapada, no secuencial.

En Continuous Discovery Habits Teresa Torres es explícita sobre la naturaleza del discovery: no es una fase previa al desarrollo, sino una actividad semanal, ligera, integrada en el ritmo del equipo. Su investigación con cientos de equipos de producto reveló que los equipos más efectivos no hacen "sprints de discovery" ni esperan semanas para validar ideas. Hacen discovery cada semana, con actividades pequeñas y enfocadas.

El problema surge cuando las organizaciones, con buena intención pero sin entender el espíritu original, convierten el Dual Track en un proceso pesado. Muchas organizaciones aplican nuevas prácticas sobre viejos procesos de gobernanza, creando híbridos disfuncionales que conservan lo peor de ambos mundos.

Las trampas más comunes: cuando Dual Track se convierte en dual burocracia

La trampa del backlog infinito de discovery

"Tenemos 47 hipótesis en el backlog de discovery que necesitamos validar antes de empezar a construir." Esta frase revela una comprensión fundamental errónea del discovery: no es una actividad que se "completa" antes de pasar a delivery.

Cuando convertimos discovery en un inventario de actividades pendientes, estamos recreando exactamente el problema que queríamos resolver: acumulación de trabajo no validado. La diferencia es que antes acumulábamos funcionalidades; ahora acumulamos investigaciones.

El discovery efectivo, según Torres, tiene tres características clave:

• Es continuo: sucede semanalmente, no en sprints dedicados.
• Es ligero: cada actividad de discovery puede completarse en días, no semanas.
• Es orientado a decisiones: cada actividad de discovery tiene una decisión específica asociada.

Cuando el backlog de discovery crece sin control, es señal de que estamos confundiendo actividad con progreso. No necesitamos validar todas las hipótesis posibles; necesitamos validar las asunciones más riesgosas de nuestra apuesta actual.

La trampa de los entregables de discovery

"¿Cuándo estará listo el documento de discovery para revisión?" Esta pregunta refleja otra trampa común: convertir discovery en una fase con sus propios entregables formales. Informes de investigación, presentaciones de hallazgos, documentos de especificación "validados"... todo lo que supuestamente debíamos evitar.

El valor del discovery no está en los documentos que produce, sino en el entendimiento compartido que genera en el equipo. Los artefactos de discovery (mapas de oportunidad, journey maps, prototipos) son herramientas de pensamiento y conversación, no entregables. Cuando los equipos pasan más tiempo preparando presentaciones sobre research que haciendo research, el problema no es de capacidad del equipo, sino de dinámica organizacional. La organización ha creado, implícitamente, incentivos para performar investigación en lugar de investigar.

La trampa de la aprobación secuencial

"Completamos el discovery, ahora esperamos aprobación para pasar a delivery." Esta frase revela quizás la trampa más peligrosa: mantener un modelo de aprobación por etapas disfrazado de lenguaje ágil.

El modelo de equipos verdaderamente empoderados no requiere aprobación para cada iniciativa, porque han establecido de antemano el problema que deben resolver y los resultados que deben lograr. El equipo tiene autonomía para descubrir cómo resolver el problema, no para decidir qué problema resolver.

Cuando discovery requiere aprobación formal antes de proceder a delivery, estamos diciendo implícitamente que no confiamos en el criterio del equipo. Y si no confiamos en su criterio, ¿por qué tenemos un proceso de discovery que depende totalmente de su capacidad de juicio?

Principios para un Dual Track pragmático

Entonces, ¿cómo aplicamos Dual Track de forma que añada valor sin añadir burocracia? Varios principios parecen ser constantes en equipos que lo hacen bien.

Principio 1: Discovery es sobre reducir riesgo

El propósito del discovery no es responder todas las preguntas posibles, sino reducir los riesgos más importantes de nuestra apuesta actual. Esto requiere ser explícitos sobre qué estamos asumiendo y qué tan catastrófico sería estar equivocados.

Torres propone el concepto de assumption mapping: identificar las asunciones detrás de tu idea, mapearlas según importancia y nivel de certeza, y validar primero las que son importantes y sobre las que tienes poca certeza. Esto significa que algunas asunciones deliberadamente no se validan, porque son de bajo riesgo o porque ya tenemos suficiente evidencia.

Este enfoque requiere conversaciones adultas sobre riesgo aceptable. ¿Estamos dispuestos a construir algo con 80% de confianza en lugar de esperar a tener 95%? La respuesta depende del coste de estar equivocados. El nivel de certeza que buscas debe ser proporcional a la irreversibilidad de la decisión.

Principio 2: El mejor entregable de discovery es código en producción

Esta idea, promovida por equipos de producto maduros, invierte la relación típica entre discovery y delivery. En lugar de hacer discovery completo antes de construir nada, construyes la cantidad mínima necesaria para aprender.

El concepto de MVP ha sido malinterpretado sistemáticamente. Un MVP no es una versión reducida de tu visión completa; es el experimento más pequeño que puedes hacer para validar tu asunción más riesgosa. A veces ese experimento requiere código. A veces requiere una landing page. A veces requiere solo una conversación.

Esto no significa "construir rápido y romper cosas" sin pensar. Significa que el código en producción puede ser un instrumento de discovery, si está diseñado para aprender. Feature flags, despliegues parciales, y una buena telemetría permiten tratar el código como hipótesis verificables.

Principio 3: La sincronización entre tracks es conversación

En equipos donde Dual Track funciona bien, la conexión entre discovery y delivery no son documentos de handoff, sino conversaciones frecuentes donde todo el equipo (incluido tech) participa en discovery, y todos entienden qué estamos intentando aprender.

La calidad de la colaboración en equipos complejos depende fundamentalmente de la frecuencia y calidad de las conversaciones, no de la exhaustividad de la documentación. Los equipos efectivos tienen rituales ligeros pero consistentes donde comparten aprendizajes, ajustan dirección, y toman decisiones juntos.

Jeff Gothelf y Josh Seiden (2016) proponen un modelo donde el equipo completo participa en actividades de discovery, cada uno desde su perspectiva. El desarrollador que participa en entrevistas de usuario no solo entiende mejor el problema; también puede identificar soluciones técnicas que el PM o diseñador no habían considerado.

Esto requiere cambiar de "discovery es trabajo del PM/diseñador" a "discovery es responsabilidad del equipo, con diferentes roles contribuyendo diferente expertise." Cuando un desarrollador dice "no entiendo por qué estamos construyendo esto", no es un problema de comunicación; es un síntoma de que no participó en el proceso de descubrimiento.

Principio 4: Entrega valor a usuarios, no actividades a stakeholders

Una señal clara de que Dual Track se ha vuelto burocrático es cuando el equipo reporta sobre actividades realizadas ("hicimos 12 entrevistas, 3 prototipos, 2 tests de usabilidad") en lugar de sobre decisiones tomadas y valor entregado.

Los equipos de producto existen para resolver problemas de usuarios de forma que generen valor al negocio. Todo lo demás (ceremonias, artefactos, procesos) es instrumental. Cuando el proceso se convierte en el fin, hemos perdido el norte.

John Cutler propone un test simple: si tu stakeholder principal desapareciera durante dos semanas, ¿seguiríais avanzando de forma significativa o os quedaríais bloqueados esperando aprobaciones? Si lo segundo, vuestro proceso está optimizado para gobernanza, no para resultados.

Dual Track sin burocracia

Entonces, ¿cómo se ve esto en la práctica diaria? Algunos patrones observables:

• Los lunes el equipo revisa juntos qué aprendieron la semana anterior y qué pregunta intentarán responder esta semana. No es una reunión formal de planificación de discovery; es una conversación de 30 minutos donde alguien comparte "esta semana voy a hacer 5 entrevistas para entender si (asunción X) es cierta, ¿alguien quiere unirse?" La participación es voluntaria pero la información es transparente.
• Las actividades de discovery son pequeñas y frecuentes, no grandes y ocasionales. En lugar de "vamos a hacer un mes de research antes de decidir", es "vamos a hablar con 3 usuarios esta semana para clarificar (duda específica)."
• El código se despliega frecuentemente, pero no todo está visible para todos los usuarios. Feature flags y técnicas de release progresivo permiten que el código llegue a producción sin exposición masiva. Esto permite validar con subgrupos de usuarios antes de decidir si algo se escala o se abandona.
• Los aprendizajes de discovery se capturan donde el equipo ya trabaja. No hay un "repositorio de insights" separado que nadie consulta. Los aprendizajes están en comentarios de user stories, en notas de refinamiento, en la herramienta de gestión que el equipo usa diariamente. La documentación es just-in-time y suficiente, no comprehensiva y adelantada.
• El equipo puede explicar en dos minutos qué están intentando aprender y por qué importa. Esta claridad no viene de un documento exhaustivo, sino de conversaciones frecuentes donde han refinado su entendimiento colectivo. Si alguien nuevo se une al equipo, cualquier miembro puede contextualizar sin reenviar 15 documentos.

Las conversaciones difíciles que esto requiere

Implementar Dual Track pragmáticamente requiere conversaciones organizacionales incómodas sobre confianza, control y responsabilidad.

Conversación 1: sobre la autonomía real del equipo

Si el equipo debe pedir permiso en cada transición de discovery a delivery, no son equipos empowered; son feature teams con jerga ágil. Esto no es criticar a la organización; es ser honestos sobre el contrato actual. Los equipos empoderados tienen autonomía sobre el cómo (la solución) pero no sobre el qué (el problema) ni sobre el por qué (los resultados esperados).

¿Está tu organización realmente dispuesta a dar esa autonomía? ¿O prefieres un modelo de validación por etapas donde reduces riesgo mediante supervisión? Ambos modelos son válidos para diferentes contextos, pero intentar hacer uno mientras dices que haces el otro genera confusión y frustración.

Conversación 2: sobre el pace y la paciencia

El discovery efectivo a veces significa ir más lento al principio para ir más rápido después. Esto choca con culturas organizacionales que miden progreso por output visible.

Esta conversación es especialmente difícil cuando hay presión comercial, compromisos con clientes, o roadmaps públicos. ¿Cómo concilias "necesitamos aprender antes de comprometer" con "ya vendimos esto para Q3"? No hay respuesta fácil, pero fingir que no existe la tensión solo la empeora.

Conversación 3: sobre qué significa "basado en evidencia"

Muchas organizaciones dicen que quieren decisiones basadas en datos, pero en la práctica esperan que los datos confirmen lo que ya decidieron. El discovery genuino significa estar dispuesto a cambiar de dirección cuando la evidencia contradice tu intuición inicial.

Esto requiere madurez organizacional para aceptar el coste de oportunidad de pivots. Si cada cambio de dirección se interpreta como fracaso del equipo en lugar de aprendizaje valioso del sistema, los equipos aprenderán rápidamente a hacer discovery performativo: investigar solo lo suficiente para justificar lo que ya querían hacer.

Proceso como instrumento, no como identidad

El Dual Track, como cualquier práctica de producto, es un instrumento para lograr mejores resultados, no una identidad. Cuando equipos o organizaciones se vuelven religiosos sobre "hacer discovery correctamente," han perdido el espíritu original.

Si tu implementación de Dual Track se siente burocrática, probablemente lo es. La pregunta entonces no es "¿cómo hacemos más discovery?" sino "¿qué problema estamos intentando resolver con discovery?" Si la respuesta es "cubrir nuestra responsabilidad" o "cumplir con el proceso," estamos optimizando para lo equivocado.

El Dual Track efectivo es casi invisible desde fuera. No hay grandes ceremonias ni entregables formales. Hay equipos que hablan regularmente con usuarios, que construyen pequeño y validan rápido, que ajustan dirección cuando aprenden algo nuevo, y que entregan soluciones que funcionan porque entendieron el problema primero.

Bibliografía

• Cagan, M.
  • (2017). Inspired: How to Create Tech Products Customers Love. Wiley.
  • (2020). Empowered: Ordinary People, Extraordinary Products. Wiley.
• Edmondson, A. (2019). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley.
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
• Gothelf, J., & Seiden, J.
  • (2016). Lean UX: Designing Great Products with Agile Teams (2nd ed.). O'Reilly Media.
  • (2017). "Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously". Harvard Business Review Press.
• Olsen, D. (2015). The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback. Wiley.
• Patton, J. (2014). User Story Mapping: Discover the Whole Story, Build the Right Product. O'Reilly Media.
• Perri, M. (2019). Escaping the Build Trap: How Effective Product Management Creates Real Value. O'Reilly Media.
• Ries, E. (2017). *The Startup Way: How Modern Companies Use Entrepreneurial Management to Transform Culture and Drive Long-Term
• Growth*. Currency.
• Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.