En el dinámico mundo del desarrollo de producto, una de las preguntas más recurrentes es: ¿cómo integrar el Product Discovery en el roadmap de forma efectiva? ¿Es una fase formal o una actividad que ralentiza la entrega y debe gestionarse «al margen»?
Esta tensión entre investigar y la presión por entregar resultados es un desafío constante. Este post te ofrece una guía clara y un framework práctico para que tú y tu equipo podáis navegar el complejo equilibrio entre construir lo correcto y construirlo rápido, asegurando que el Product Discovery en el roadmap sea vuestro mayor aliado.
Este post se nutre del encuentro entre Alba Losada y Javier Ruiz ambos miembros de Seat Code, podéis ver toda la charla aquí:
Entendiendo el Terreno de Juego: Discovery vs. Delivery
Antes de decidir cómo organizar tu planificación, es fundamental comprender su propósito. Existen dos espacios claros en los que se mueve un equipo de producto:
- Problem Space (Espacio del Problema): Aquí el objetivo es entender en profundidad las necesidades del negocio y los problemas de los usuarios. Es el «qué» y el «porqué».
- Solution Space (Espacio de la Solución): En esta fase, el equipo diseña y construye la mejor forma de resolver los problemas identificados. Es el «cómo».
Este entendimiento nos lleva a dos procesos clave:
- Product Discovery: Es el conjunto de actividades que nos asegura que construimos el producto correcto. Se enfoca en reducir la incertidumbre.
- Product Delivery: Se centra en construir el producto correctamente. Implica el desarrollo, lanzamiento y medición del impacto.
Lejos de ser procesos lineales, Discovery y Delivery forman un ciclo continuo de aprendizaje. No se trata de hacer uno y luego el otro, sino de mantener un flujo bidireccional constante.
El Framework de 4 Pilares para un Roadmap Sólido
Cualquier iniciativa en un roadmap debe poder responder a cuatro preguntas fundamentales. Si falta una respuesta, es señal de que se necesita más Discovery.
- Objetivos: ¿Por qué hacemos esto? ¿Qué métrica queremos impactar? Aquí es donde sistemas como los OKRs son vitales.
- Problemas: ¿Qué problema específico del usuario o negocio estamos intentando solucionar? Omitir este paso es un error costoso.
- Ideas: ¿Qué posibles soluciones hemos considerado? Fomentar múltiples ideas aumenta drásticamente las posibilidades de éxito.
- Roadmap (El Plan): ¿Cuáles son los pasos concretos que vamos a seguir para implementar la solución?
Antes de que tu equipo escriba una línea de código, pregúntate si tienes claridad en estos cuatro puntos.
La Respuesta Definitiva: ¿Cómo incluir el Product Discovery en el Roadmap?
La respuesta es: depende del riesgo y la claridad.
No todos los esfuerzos de Discovery necesitan estar formalmente en el roadmap. Una entrevista rápida con un usuario no requiere planificación formal. Sin embargo, las iniciativas de investigación más grandes y estratégicas sí deben tener su lugar visible.
Este modelo mental te ayudará a decidir:
- Claridad del Problema (Baja vs. Alta): ¿Cuánto sabemos sobre el problema?
- Riesgo de la Iniciativa (Bajo vs. Alto): ¿Qué impacto tendría equivocarnos?
Esto nos da cuatro cuadrantes de actuación:
- Bajo Riesgo y Alta Claridad: ¡Adelante con el Delivery! Lanza, mide y aprende sin sobreanalizar.
- Bajo Riesgo y Baja Claridad: Haz un Research Ligero. Un benchmark o entrevistas con 5 usuarios para ganar claridad sin invertir demasiado tiempo.
- Alto Riesgo y Alta Claridad: Define la solución en detalle. Aquí los Product Requirement Documents (PRD) y la planificación técnica son cruciales.
- Alto Riesgo y Baja Claridad: Aquí es donde el Product Discovery debe estar explícitamente en el roadmap. Necesitas un Research Profundo (heavy research) que debe planificarse como cualquier otra épica.
Visualizando el Product Discovery en el Roadmap: Un Modelo Práctico
Para una integración visual, puedes usar un roadmap de «Ahora, Después, Futuro»:
- Ahora (Now): En lo que el equipo está trabajando activamente.
- Después (Next): Iniciativas priorizadas para el futuro cercano.
- Futuro (Later): Ideas y oportunidades a explorar.
- Completado (Done): Lo que ya se ha entregado.
- Descartado (Discarded): ¡La columna del aprendizaje! Ideas que, tras el Discovery, se demostró que no eran viables. Es una prueba de una cultura de producto madura.
En este modelo, las iniciativas de investigación se gestionan como Épicas de Discovery, conviviendo en el mismo tablero con las de Delivery. Esta es la forma más transparente de gestionar el Product Discovery en el roadmap.
Claves para Madurar tu Cultura de Producto
El camino hacia una cultura de producto equilibrada implica madurez organizacional e individual.
- Madurez Organizacional: Las empresas deben evolucionar de la intuición a las decisiones basadas en datos. Para ello, es crucial invertir en perfiles como UX Researchers o Data Scientists.
- Madurez del Equipo: El equipo debe tener una mentalidad de aprendizaje y apoyarse en expertos. Involucrarse en la investigación es clave, pero sin reemplazar el rigor de los especialistas en decisiones de alto riesgo.
Mencionar en este punto el concepto de Continuous Discovery Habits de Teresa Torres.
El Equilibrio Estratégico del Product Discovery en el Roadmap
Integrar el Product Discovery en el roadmap no es una cuestión de «sí» o «no», sino de «cuándo» y «cómo». La clave del éxito reside en tratar el descubrimiento como una herramienta estratégica para reducir la incertidumbre, especialmente en iniciativas de alto riesgo.
Al adoptar estos frameworks, los equipos toman decisiones más informadas y se aseguran de que no solo entregan funcionalidades, sino que resuelven problemas reales. Tratar el Product Discovery en el roadmap como un ciudadano de primera clase es el paso definitivo hacia la excelencia.
Preguntas Frecuentes (FAQ)
¿Toda la investigación debe estar planificada en el roadmap?
No. Solo las iniciativas de investigación grandes y estratégicas («heavy research») que requieren recursos y tiempo deben tratarse como ítems formales en el roadmap.
¿Quién es el responsable de buscar los problemas a resolver?
Es una responsabilidad compartida, pero el Product Manager actúa como el principal organizador, centralizando y priorizando los insights de todas las fuentes.
¿Cuánto tiempo debería dedicar un PM al Discovery vs. Delivery?
Un buen punto de partida es un reparto del 50/50. Para lograrlo, es fundamental empoderar al equipo de desarrollo para que se autoorganice en el Delivery.
¿Cómo convenzo a mi empresa de la necesidad del Discovery?
Enmarca el Discovery como el método más eficaz para alcanzar los objetivos de negocio (reducir costes, aumentar ingresos), minimizando el riesgo de construir algo que nadie usará.
¿Quieres seguir avanzando en el rol del Product Manager? Te animamos a que eches un vistazo a nuestro curso Digital Product Manager 😃