Hay dos tipos de roadmap en el mundo: los que se abren en la primera reunión trimestral y los que nadie vuelve a ver hasta que alguien pregunta en qué estamos trabajando.
Si llevas tiempo en producto, probablemente hayas vivido ambos.
El problema no es el formato. El problema es el propósito. La mayoría de los equipos construyen roadmaps para reportar, no para decidir. Y esa diferencia lo cambia todo.
Qué es (y qué no es) un roadmap
Un roadmap es una hipótesis sobre cómo llegarás de donde estás a donde quieres estar. No es una promesa. No es un backlog ordenado. No es un Gantt con nombres de features.
Es una conversación estructurada sobre prioridades.
Cuando lo tratas como un contrato, pasan cosas malas: el equipo de ventas lo usa para prometer funcionalidades, los engineers se sienten atrapados en decisiones tomadas hace seis meses, y tú pasas más tiempo explicando por qué el feature X no está listo que construyendo el producto.
Un roadmap que no puede cambiar no es un roadmap. Es una deuda técnica de decisiones.
Los tres horizontes
La estructura que más me ha funcionado divide el roadmap en tres horizontes temporales:
Horizonte 1 — Ahora (0-3 meses) Lo que estás construyendo activamente. Aquí sí hay especificidad: problemas concretos, métricas objetivo, equipos asignados. Este horizonte puede parecer un roadmap tradicional porque tiene fechas aproximadas.
Horizonte 2 — Después (3-6 meses) Lo que planeas abordar si las apuestas del H1 salen bien. Aquí hablas de problemas, no de soluciones. "Reducir fricción en el onboarding" en lugar de "rediseñar el wizard de registro".
Horizonte 3 — Más adelante (6-12 meses) Direcciones estratégicas, no features. "Expansión a mercados LATAM", "explorar monetización por uso", "infraestructura para self-serve". Esta parte del roadmap es casi completamente revisable.
Por qué funciona esto
Porque alinea la conversación al nivel correcto según el horizonte. No tiene sentido debatir el color de un botón en H3, ni hablar de "visión" cuando hay un bug crítico en H1.
Construir el roadmap sin perder la cordura
El error más común es construir el roadmap solo, en una hoja de cálculo, y luego "presentarlo" al equipo. Esto genera dos problemas: falta de ownership y falta de contexto.
El proceso que propongo es iterativo:
1. Recopilar señales (datos, feedback, deuda técnica, oportunidades)
2. Identificar los 3-5 problemas más importantes del período
3. Mapear soluciones posibles y estimar impacto vs. esfuerzo
4. Alinear con stakeholders clave ANTES de publicar
5. Publicar y revisar cada 4-6 semanas
La revisión quincenal o mensual no es opcional. Un roadmap que no se revisa se convierte en arqueología.
Cómo medir si tu roadmap funciona
No midas el cumplimiento de fechas. Mide:
- Velocidad de decisión: ¿cuánto tardas en responder "¿por qué no estamos haciendo X?"
- Sorpresas en Q: ¿cuántas veces el equipo hizo cosas que no estaban en el roadmap?
- Alineación de stakeholders: ¿tienes que repetir las mismas explicaciones en cada reunión?
Si la velocidad de decisión es alta, las sorpresas son pocas y no repites el mismo discurso cada semana, tu roadmap está funcionando.
Conclusión
Un buen roadmap no predice el futuro. Lo que hace es crear las condiciones para tomar mejores decisiones más rápido. Esa es la diferencia entre un documento que vive en Notion y uno que guía realmente el trabajo del equipo.
Empieza con los problemas, no con los features. Y revisítalo antes de que alguien te pregunte en qué estás trabajando.