Guía para construir un roadmap que la gente realmente use
Un roadmap que nadie consulta es un documento de planificación fallido. Esta guía explica cómo construir un roadmap que funcione como herramienta de alineación, no como promesa de entrega.
El roadmap tiene mala fama en muchos equipos, y la tiene por razones concretas. Promete cosas que luego no se cumplen. Se convierte en un documento político más que estratégico. Lo actualiza el PM pero nadie más lo consulta. O peor, lo consultan para pedir cuentas sobre lo que no se entregó en la fecha acordada.
Esos problemas no son inevitables. Vienen de cómo se construye el roadmap y para qué se usa.
Para qué sirve un roadmap
Antes de hablar de cómo construirlo, hay que tener claro para qué sirve.
Un roadmap bien construido sirve para:
Comunicar dirección estratégica. Hacia dónde va el producto en los próximos meses y por qué. No todas las decisiones, sino las más importantes.
Facilitar la alineación. El roadmap es el artefacto que permite que stakeholders de distintas áreas entiendan qué prioridades ha tomado producto y puedan planificar su trabajo en consecuencia.
Generar conversaciones de trade-off. El roadmap visible hace explícito que hacer X implica no hacer Y. Eso facilita conversaciones que sin el roadmap suelen darse más tarde, cuando los costes son mayores.
Un roadmap no sirve para comprometerse con fechas de entrega específicas. No sirve para capturar todas las ideas del backlog. No sirve para demostrar que el equipo está ocupado.
Los tres tipos de roadmap más comunes
Roadmap por funcionalidades con fechas
El más extendido y el más problemático. Especifica qué funcionalidades se entregarán en qué período. Genera las expectativas más concretas y cumple las menos.
Es útil en contextos muy específicos: lanzamientos con fecha fija (fecha legal, evento de industria) donde el alcance está bien definido y el equipo tiene alta confianza en las estimaciones. Fuera de ese contexto, las fechas crean compromisos que se incumplen sistemáticamente.
Roadmap por outcomes (now/next/later)
El más honesto. En lugar de comprometerse con funcionalidades y fechas, comunica los outcomes que el equipo está tratando de generar en tres horizontes temporales:
Ahora: En qué trabaja el equipo activamente. Nivel de detalle alto, alta confianza.
Próximo: Qué abordará el equipo cuando termine lo que tiene ahora. Nivel de detalle moderado, confianza razonable.
Más adelante: Dirección estratégica sin compromisos de tiempo. Ideas validadas pero sin fecha.
Este formato es más honesto porque refleja el gradiente real de certeza. Lo que está en “ahora” tiene alta confianza. Lo que está en “más adelante” es una hipótesis sobre el futuro.
Roadmap por temas estratégicos
Organiza el trabajo por áreas de enfoque estratégico en lugar de por funcionalidades. “Reducir fricción en el onboarding”, “Aumentar el valor para el segmento enterprise”, “Mejorar la estabilidad del sistema”.
Útil para comunicar con dirección y stakeholders de negocio que necesitan entender la dirección pero no necesitan el nivel de detalle de las funcionalidades.
Cómo construir el roadmap
Paso 1: Define los outcomes que persigues
El roadmap tiene que conectar con los objetivos del período. Si tienes OKRs, los Key Results son el punto de partida. Si no, define explícitamente qué resultados de usuario o de negocio quieres generar.
Sin esa conexión, el roadmap es una lista de trabajo sin contexto estratégico.
Paso 2: Identifica las iniciativas con mayor impacto potencial
Para cada outcome, identifica las dos o tres iniciativas con mayor potencial de impacto. No el listado completo del backlog. Las que, si funcionan, generarían el cambio más significativo en el outcome que persigues.
Este paso requiere haber hecho discovery. Las iniciativas que van al roadmap deben tener un nivel mínimo de validación: evidencia de que el problema existe, algún nivel de confirmación de que la solución es viable y deseable.
Paso 3: Ordénalas por horizonte de confianza
Now/next/later no es solo una cuestión de tiempo. Es una cuestión de confianza.
En “ahora” van las iniciativas que tienen criterios de aceptación claros, validación suficiente y estimación técnica razonada.
En “próximo” van las que tienen validación del problema pero todavía necesitan diseño y refinamiento antes del desarrollo.
En “más adelante” van las que tienen evidencia de oportunidad pero no se ha determinado la solución.
Paso 4: Define qué no está en el roadmap y por qué
Esta es la parte que más se omite. Las decisiones de exclusión son tan importantes como las de inclusión. Hacer explícito qué no está en el roadmap este período, y por qué, previene conversaciones repetidas sobre las mismas iniciativas descartadas.
Paso 5: Establece el ciclo de revisión
El roadmap tiene una fecha de caducidad. Las prioridades cambian, el contexto cambia, los aprendizajes de discovery cambian lo que sabemos. Un roadmap que no se revisa periódicamente se convierte en un documento estático desconectado de la realidad.
La frecuencia de revisión depende del ritmo de cambio del contexto. En etapas tempranas de producto, puede ser mensual. En productos más maduros, trimestral.
Errores frecuentes al presentar el roadmap
Presentarlo sin contexto. El roadmap sin los objetivos que persigue es una lista de funcionalidades sin sentido. Siempre presentarlo junto con los outcomes que intenta generar.
Comprometerse con fechas en el “más adelante”. Si algo está en “más adelante”, no tiene fecha. Si alguien pide una fecha para algo en ese horizonte, la respuesta honesta es que la fecha depende de los aprendizajes que se generen en el trabajo previo.
No actualizar cuando cambia la prioridad. Si algo se pospone o se cancela, el roadmap tiene que reflejarlo. Un roadmap desactualizado erosiona la confianza en el proceso.
Usar el mismo formato para audiencias distintas. El nivel de detalle del roadmap para el equipo técnico es diferente al de la dirección ejecutiva. Tener versiones adaptadas a cada audiencia no es duplicar trabajo, es respetar que cada audiencia necesita información diferente.
Las opiniones expresadas son personales y no representan la posición de ninguna organización.