- Actualizado: octubre 12, 2026
Cómo hacer un roadmap de producto: pasos, formatos y ejemplo
Saber cómo hacer un roadmap de producto es una de las habilidades que más separa a un equipo que avanza con rumbo de uno que corre de pedido en pedido. Un buen roadmap no es una lista de funcionalidades con fechas: es un documento que explica qué problemas vas a resolver, en qué orden y por qué, y que cualquiera en la empresa puede leer en cinco minutos 🗺️
Respuesta corta: para hacer un roadmap de producto, parte de la visión y de dos o tres objetivos medibles, reúne evidencia de usuarios y del negocio, conviértela en problemas a resolver, priorízalos con un criterio explícito y ordénalos en un formato simple como Now/Next/Later. Luego compártelo con cada audiencia y revísalo cada mes o cada trimestre.
En esta guía vas a ver qué es (y qué no es) un roadmap de producto, los formatos más usados con una tabla comparativa, un método de siete pasos, un ejemplo completo en formato Now/Next/Later, el caso real de Basecamp con su método Shape Up, cómo usar la inteligencia artificial para resumir feedback y priorizar sin delegarle la decisión, y un ejercicio para armar tu primer roadmap en una semana.
¿Quieres aprender a construir y defender un roadmap con IA como copiloto?
Qué es un roadmap de producto
Un roadmap de producto (u hoja de ruta de producto) es una representación visual y de alto nivel de hacia dónde va un producto y de las apuestas que el equipo hará para llegar ahí. Responde a tres preguntas: ¿qué queremos lograr?, ¿qué problemas vamos a atacar para lograrlo? y ¿en qué orden?
Su dueño suele ser el product manager, aunque se construye con diseño, ingeniería, ventas, soporte y dirección. Sirve a la vez como herramienta de decisión (obliga a elegir) y de comunicación (alinea a toda la empresa sobre las prioridades).
Un roadmap no es un diagrama de Gantt
El error más extendido es confundir el roadmap con un cronograma: una fila por funcionalidad, una barra por mes y una fecha de entrega para cada cosa. Ese formato tiene sentido en un proyecto con alcance cerrado, pero en un producto digital genera dos problemas. El primero es la falsa precisión: nadie sabe hoy cuánto tardará algo que se construirá dentro de nueve meses. El segundo es que fija soluciones antes de entender el problema.
Marty Cagan, fundador del Silicon Valley Product Group, lo resumió en 2015 en su artículo The Alternative to Roadmaps: los roadmaps típicos le dicen al equipo qué hacer, cuando lo útil es decirle qué resultado necesitas y cómo se medirá. Su frase clave fue «todo se trata del resultado y no del entregable» (outcome rather than output). Por eso, en esta guía vamos a tratar el roadmap como una apuesta ordenada de problemas a resolver, no como una promesa de fechas.
Roadmap, backlog y plan de proyecto: en qué se diferencian
Estos tres artefactos conviven en casi cualquier equipo de producto y se confunden con facilidad. La diferencia está en el nivel de detalle y en el horizonte:
| Aspecto | Roadmap de producto | Backlog | Plan de proyecto |
|---|---|---|---|
| Pregunta que responde | ¿Qué problemas atacamos y en qué orden? | ¿Qué tareas concretas hace el equipo después? | ¿Cómo entregamos este alcance a tiempo y en presupuesto? |
| Nivel de detalle | Alto: temas, objetivos, iniciativas | Bajo: historias de usuario, bugs, tareas | Medio: entregables, hitos, dependencias |
| Horizonte | De un trimestre a un año | Las próximas semanas | La duración del proyecto |
| Audiencia | Toda la empresa y, a veces, clientes | El equipo de desarrollo | Equipo, sponsor y proveedores |
| Cómo se mide | Por resultados (retención, activación, ingresos) | Por trabajo terminado | Por plazos, costes y alcance cumplidos |
| Cada cuánto cambia | Revisión mensual o trimestral | Cada sprint o cada semana | Con control de cambios formal |
Si vienes del mundo de proyectos, te ayudará repasar qué hace un project manager: el plan de proyecto sigue siendo útil, solo que vive un nivel más abajo que el roadmap.
Formatos de roadmap de producto: cuál elegir
No existe un formato único. Elige según la madurez del producto, el tipo de empresa y quién va a leerlo.
| Formato | Cómo se ve | Ventaja | Riesgo | Cuándo usarlo |
|---|---|---|---|---|
| Por fechas (timeline) | Funcionalidades sobre un calendario mensual o trimestral | Fácil de entender para ventas y dirección | Falsa precisión y compromisos imposibles | Cuando hay fechas externas reales (regulación, un evento, un contrato) |
| Por temas u objetivos | Columnas o filas por objetivo («mejorar la retención») | Conecta el trabajo con la estrategia | Puede quedar abstracto si no baja a iniciativas | Empresas que trabajan con OKR |
| Now / Next / Later | Tres columnas: ahora, después, más adelante | Comunica prioridades sin inventar fechas | Hay que explicarlo a quien espera un calendario | Startups y equipos ágiles; productos con mucha incertidumbre |
| Por resultados (outcome-based) | Cada fila es un resultado medible y sus apuestas | Mide el éxito por impacto, no por entregas | Exige buenas métricas y disciplina | Equipos de producto maduros |
El formato Now / Next / Later
Lo creó Janna Bastow, cofundadora de ProdPad y de la comunidad Mind the Product, quien cuenta que la primera versión la bosquejó en 2012 junto a su socio Simon Cast con las columnas «Current / Near Term / Future», que ya funcionaban como el Now/Next/Later actual. La idea nació de una frustración concreta: los roadmaps con línea de tiempo obligan a fijar plazos y le quitan al equipo la flexibilidad que necesita para hacer bien su trabajo. Sus tres columnas funcionan así:
- Now (ahora): lo que el equipo está trabajando o empezará de inmediato. Está bien definido y con detalle.
- Next (después): lo que viene cuando termine lo actual. Se sabe qué problema es, pero tiene menos detalle.
- Later (más adelante): grandes bloques que importan para la estrategia y están en el radar, sin desglosar todavía.
La regla implícita es poderosa: cuanto más lejos, menos detalle. Eso evita el trabajo inútil de especificar hoy cosas que quizá nunca se hagan.
Cómo hacer un roadmap de producto en 7 pasos
Este es el método que puedes seguir tanto si lanzas un producto nuevo como si heredas uno que ya tiene usuarios.
Paso 1. Escribe la visión en una frase
Antes de hablar de funcionalidades, define para quién es el producto y qué cambio quieres provocar en su vida. Ejemplo: «Que cualquier persona que vive sola pueda planificar las comidas de la semana en diez minutos y sin desperdiciar comida». Si no puedes escribirla en una frase, el roadmap va a ser una lista de deseos.
Paso 2. Elige dos o tres objetivos medibles
Traduce la visión en metas para el próximo período. Lo ideal es usar el lenguaje de los OKR: un objetivo cualitativo y resultados clave con número. Por ejemplo, «que los usuarios nuevos se queden» con el resultado clave «subir la retención a 30 días del 18 % al 25 %». Menos objetivos significa más foco; si tienes siete, en realidad no tienes ninguno.
Paso 3. Reúne evidencia, no opiniones
Junta todo lo que te dice algo sobre los usuarios y el negocio: entrevistas, tickets de soporte, reseñas en las tiendas de apps, pedidos de ventas, datos de uso y métricas del embudo. Aquí la IA es una gran aliada para agrupar cientos de comentarios por tema (lo vemos más abajo). Un marco útil para leer esa evidencia es Jobs to Be Done: pregúntate qué «trabajo» intenta resolver la persona cuando usa tu producto.
Paso 4. Convierte pedidos en problemas
«Quiero exportar a Excel» es una solución; el problema puede ser «necesito mostrarle a mi jefe cuánto gastamos este mes». Reescribe cada pedido como un problema del usuario y agrupa los que se repiten. Esta es la parte que distingue un roadmap de producto de una lista de pedidos: las filas del roadmap son problemas u oportunidades, no funcionalidades cerradas.
Paso 5. Prioriza con un criterio explícito
Usa un marco que puedas explicar. Uno de los más difundidos es RICE, que Sean McBride publicó en el blog de Intercom: Reach (cuántas personas impacta en un período), Impact (en una escala de 3 = masivo, 2 = alto, 1 = medio, 0,5 = bajo y 0,25 = mínimo), Confidence (100 % alta, 80 % media, 50 % baja) y Effort (en personas-mes). La fórmula es (alcance × impacto × confianza) ÷ esfuerzo. El propio McBride advierte que la puntuación no debe usarse como una regla rígida: dependencias o requisitos del mercado pueden justificar priorizar algo con menos puntos. Si necesitas algo más simple para empezar, una matriz impacto/esfuerzo o la lógica de la matriz de Eisenhower también sirven.
Paso 6. Ordena en el formato elegido
Coloca en Now solo lo que el equipo puede abordar de verdad con su capacidad actual. En Next, lo siguiente en la lista priorizada. En Later, los grandes temas estratégicos. Para cada elemento anota tres cosas: el problema, el objetivo al que contribuye y la métrica con la que sabrás si funcionó. Si una apuesta es grande e incierta, considera empezar por un producto mínimo viable que valide la idea antes de comprometer meses de trabajo.
Paso 7. Compártelo, mídelo y revísalo
Presenta el roadmap a cada audiencia (más abajo verás cómo adaptarlo), publica dónde vive la versión vigente y fija una cadencia de revisión: mensual para startups, trimestral para empresas más grandes. En cada revisión pregunta qué aprendiste, qué métricas se movieron y qué elementos suben, bajan o salen. Un roadmap que no cambia nunca es una señal de que nadie lo está usando.
Ejemplo de roadmap de producto en formato Now / Next / Later
Para que lo veas aplicado, este es un ejemplo ilustrativo (no es una empresa real) de una app de planificación de comidas con el objetivo trimestral «que los usuarios nuevos se queden», medido con la retención a 30 días.
| Columna | Problema a resolver | Evidencia | Métrica de éxito |
|---|---|---|---|
| Now | Los usuarios nuevos no saben qué cocinar la primera semana | El 40 % de los tickets de la primera semana preguntan por recetas iniciales | % de usuarios que planifican su primera semana completa |
| Now | La lista de compras no se puede compartir con la pareja | Pedido repetido en entrevistas y reseñas | Listas compartidas por usuario activo |
| Next | Se tira comida porque el plan no considera lo que ya hay en la nevera | Siete de diez entrevistados lo mencionan | Recetas generadas a partir de ingredientes disponibles |
| Next | Planificar para dietas especiales lleva demasiado tiempo | Segmento creciente en las encuestas | Retención a 30 días de ese segmento |
| Later | Comprar los ingredientes sin salir de la app | Hipótesis estratégica, sin validar | A definir tras un piloto |
| Later | Llegar a familias con niños | Oportunidad de mercado detectada por ventas | A definir |
Fíjate en tres detalles: ninguna fila tiene fecha, todas describen un problema (no una pantalla) y la columna Later admite métricas «a definir». Los porcentajes del ejemplo son inventados para ilustrar; en tu roadmap deben salir de tus propios datos.
Caso real: Basecamp, Shape Up y las apuestas de seis semanas
Uno de los ejemplos más documentados de cómo planificar un producto sin un roadmap largo y rígido es el de Basecamp (la empresa hoy se llama 37signals). En 2019, Ryan Singer, estratega de producto de la compañía, publicó el libro Shape Up, que se puede leer gratis en basecamp.com/shapeup y que describe cómo trabaja la compañía.
Estos son sus elementos centrales, tal como los cuenta el libro:
- Ciclos de seis semanas. Según Singer, seis semanas es tiempo suficiente para terminar algo significativo y lo bastante corto como para ver el final desde el principio.
- Dos semanas de enfriamiento (cool-down). Después de cada ciclo hay dos semanas para tareas sueltas, corrección de errores y la reunión en la que se decide qué viene.
- Apuestas, no backlogs. En lugar de una lista central de pendientes, el equipo «apuesta» por proyectos ya definidos a grandes rasgos (shaped). Singer describe los backlogs como un gran peso que no necesitan cargar: decenas y luego cientos de tareas que todos saben que nunca tendrán tiempo de hacer.
- Una mesa de apuestas pequeña. En Basecamp la integraban el CEO (que tiene la última palabra sobre el producto), el CTO, un programador sénior y el propio Singer como estratega de producto, y la reunión rara vez duraba más de una o dos horas.
- Apostar solo un ciclo por delante. El libro insiste en que es importante comprometerse solo con el próximo ciclo, para dejar margen de respuesta ante lo que surja.
- Un «cortacircuitos». Si un equipo no termina en el tiempo apostado, por defecto el proyecto no recibe una extensión. Así se limita el riesgo de que una apuesta se coma meses.
¿Y qué pasa con las ideas que no se eligen? Según el libro, se dejan ir: no hay que guardarlas en ningún lado. Cada área (soporte, producto, programación) puede llevar su propia lista, pero sin un backlog central. La lógica es que las ideas realmente importantes vuelven a aparecer.
Qué puedes aprender de este caso aunque no adoptes Shape Up: el horizonte de compromiso puede ser corto aunque la visión sea larga; las decisiones de prioridad se toman en una reunión con pocas personas y con propuestas ya trabajadas, y el tiempo es un límite fijo mientras el alcance se ajusta. En la práctica, es un roadmap en el que solo el «Now» es un compromiso firme.
Cómo usar la IA para hacer un roadmap (sin delegarle la decisión)
La inteligencia artificial generativa acelera mucho las partes más laboriosas del roadmap: leer, ordenar y redactar. Lo que no puede hacer por ti es decidir qué apuesta asume la empresa ni responder por el resultado. Esta es una división razonable del trabajo:
Dónde la IA ayuda de verdad
- Resumir feedback: pega (sin datos personales) cientos de reseñas o tickets y pide que los agrupe por problema, con frecuencia aproximada y citas de ejemplo.
- Reescribir pedidos como problemas: convierte «quiero un botón de exportar» en hipótesis de problema que luego validas con usuarios.
- Preparar la priorización: pide una primera estimación de alcance e impacto para cada iniciativa y que explique sus supuestos, para que tú los corrijas.
- Adaptar la comunicación: genera borradores del mismo roadmap para ingeniería, ventas y dirección.
- Hacer de abogado del diablo: pide que identifique riesgos, dependencias y supuestos débiles.
Prompts que puedes copiar
«Actúa como analista de producto. Te paso 200 comentarios de usuarios de una app de planificación de comidas. Agrúpalos en un máximo de 8 problemas, indica cuántos comentarios hay en cada grupo y cita dos comentarios textuales por grupo. No propongas soluciones todavía.»
«Esta es mi lista de 10 iniciativas con su alcance estimado. Propón una puntuación RICE para cada una, explica qué supuesto usaste en cada factor y marca con un asterisco los supuestos de los que tienes menos información.»
«Revisa este roadmap Now/Next/Later y dime cuáles son las tres apuestas más arriesgadas y qué evidencia me falta para cada una.»
Lo que debe seguir en manos humanas
- Elegir los objetivos y decir que no.
- Hablar con usuarios para captar lo que no está en los datos.
- Validar que los agrupamientos de la IA reflejan lo que dicen los usuarios: un resumen automático puede perder justo el matiz que importa.
- Negociar con dirección, ventas e ingeniería y asumir la responsabilidad por la apuesta.
Para sacarle más partido, conviene dominar cómo escribir buenos prompts y cuidar qué información de clientes compartes con herramientas externas.
Cómo comunicar el roadmap a cada audiencia
El mismo roadmap se cuenta distinto según quién escucha. Un error común es mostrar la misma diapositiva a todos.
- Dirección: objetivos, resultados esperados y riesgos. Pocas filas, mucho «por qué».
- Ingeniería y diseño: problemas, evidencia, restricciones y qué se sabe y qué no. Es la versión con más contexto y menos fechas.
- Ventas y atención al cliente: qué problemas de clientes se están atacando y qué no está en el radar, para que no prometan lo que no existe. Si piden fechas, usa rangos y aclara el nivel de certeza.
- Clientes: si publicas un roadmap externo, quédate en el nivel de temas y evita compromisos de fecha que luego no puedas cumplir.
Para conectar el roadmap con métricas que todos entiendan, define bien tus KPI antes de presentarlo.
Errores comunes al hacer un roadmap de producto
- Convertirlo en una lista de pedidos: anotar lo que pide el cliente más ruidoso sin preguntar qué problema hay detrás.
- Poner fechas a todo: cada fecha inventada se convierte en una promesa que alguien recordará.
- Demasiadas cosas en «Now»: si todo es prioritario, nada lo es. Ajusta a la capacidad real del equipo.
- No conectar con objetivos: si una fila no sirve a ningún objetivo, pregúntate por qué está ahí.
- Construirlo en soledad: un roadmap sin aportes de ingeniería y diseño suele fallar en factibilidad y usabilidad.
- No revisarlo nunca: el roadmap es un documento vivo; lo que aprendes cada mes debe reflejarse.
- Delegar el criterio en una herramienta: ni una puntuación RICE ni una IA deciden por ti; te ayudan a decidir mejor.
Ejercicio práctico: tu primer roadmap en una semana
Si nunca has hecho un roadmap, este plan te permite armar uno real (para tu producto o para una app que uses a diario) dedicando menos de una hora por día:
| Día | Tarea | Resultado |
|---|---|---|
| 1 | Escribe la visión en una frase y define dos objetivos medibles | Visión y objetivos |
| 2 | Reúne 50 a 100 comentarios de usuarios (reseñas, tickets, entrevistas) | Banco de evidencia |
| 3 | Agrupa los comentarios por problema; puedes pedirle un primer borrador a una IA y luego revisarlo tú | Lista de problemas con frecuencia |
| 4 | Puntúa cada problema con RICE o con impacto/esfuerzo | Lista priorizada |
| 5 | Ordénalos en Now / Next / Later con problema, objetivo y métrica | Primer roadmap |
| 6 | Prepara dos versiones: una para dirección y otra para el equipo | Roadmap comunicable |
| 7 | Preséntalo a alguien y pide que te discuta las tres apuestas más débiles | Roadmap revisado y pieza de portfolio |
Si buscas trabajo en producto, ese documento vale más en una entrevista que cualquier certificado sin práctica: demuestra que sabes pensar en problemas, priorizar y comunicar.
Cómo lo aprendes en Pulsión Digital
En Pulsión Digital creemos que la IA es un acelerador extraordinario, pero que decidir qué construir sigue siendo una habilidad humana. Por eso el curso Product Manager con IA recorre el ciclo completo de producto sobre un caso, y dedica una clase entera, Roadmap y comunicación con stakeholders, a construir un roadmap que no sea una promesa de fechas imposibles y a comunicar el mismo plan de forma distinta a ingeniería, ventas y dirección. Antes, trabajas la visión y la estrategia, el descubrimiento con usuarios y la priorización con RICE y Kano aplicados a un backlog real; después, la relación con diseño y desarrollo, las métricas de producto (activation, retention y NPS) y los lanzamientos.
- A tu propio ritmo, sin horarios fijos.
- Examen en cada clase para asentar lo aprendido antes de avanzar.
- Tutor con IA para resolver tus dudas mientras practicas.
- Comunidad de personas con intereses parecidos.
- Certificado al terminar.
Para completar el perfil, el curso Project Manager Digital con IA te enseña planificación, gestión de riesgos y metodologías ágiles para que lo que está en «Now» se entregue bien, y UX Design con IA te da herramientas de investigación de usuarios y prototipado rápido para validar las apuestas antes de construirlas.
Preguntas frecuentes sobre el roadmap de producto
¿Qué es un roadmap de producto en pocas palabras?
Es una representación visual y de alto nivel de hacia dónde va un producto: qué objetivos persigue, qué problemas va a resolver para lograrlos y en qué orden. Sirve para decidir prioridades y para alinear a toda la empresa.
¿Qué debe incluir un roadmap de producto?
Como mínimo: la visión, dos o tres objetivos medibles, las iniciativas expresadas como problemas a resolver, su prioridad u horizonte (por ejemplo, Now/Next/Later) y la métrica con la que se medirá el éxito de cada una. Las fechas solo cuando haya compromisos externos reales.
¿Qué es un roadmap Now / Next / Later?
Es un formato creado por Janna Bastow, cofundadora de ProdPad, que ordena el trabajo en tres columnas: lo que se hace ahora, lo que viene después y lo que está más adelante. Reemplaza las fechas por horizontes y reduce el detalle a medida que el horizonte se aleja.
¿Cuál es la diferencia entre roadmap y backlog?
El roadmap muestra objetivos y problemas a resolver en un horizonte de meses y lo lee toda la empresa. El backlog es la lista detallada de tareas e historias de usuario que el equipo de desarrollo trabajará en las próximas semanas.
¿Cada cuánto se actualiza un roadmap de producto?
Depende de la etapa de la empresa: muchas startups lo revisan cada mes y las empresas más grandes, cada trimestre. Lo importante es tener una cadencia fija y actualizarlo con lo que aprendes de usuarios y métricas.
¿Puedo hacer un roadmap de producto con IA?
Puedes usar la IA para resumir feedback, reescribir pedidos como problemas, proponer una primera puntuación de prioridades y adaptar la comunicación. La decisión final sobre qué apostar y la responsabilidad por el resultado deben seguir siendo humanas.
Conclusión
Hacer un roadmap de producto no consiste en llenar un calendario de funcionalidades, sino en decidir qué problemas vale la pena resolver primero y por qué. Parte de una visión clara, fija pocos objetivos medibles, apóyate en evidencia, prioriza con un criterio que puedas explicar y elige un formato honesto con la incertidumbre, como Now/Next/Later. El caso de Basecamp muestra que se puede tener una visión de largo plazo comprometiéndose solo con el próximo ciclo. La IA te ahorra horas de lectura y redacción, pero la apuesta sigue siendo tuya. Empieza con el ejercicio de una semana y, si quieres aprenderlo con método y práctica guiada, el curso de Product Manager con IA de Pulsión Digital te acompaña paso a paso.
Fuentes consultadas
- Singer, R. (2019). Shape Up: Stop Running in Circles and Ship Work that Matters. Basecamp. Capítulos Bets, Not Backlogs y The Betting Table.
- Cagan, M. (2015). The Alternative to Roadmaps. Silicon Valley Product Group.
- Bastow, J. (2022). Why I Invented the Now-Next-Later Roadmap. ProdPad.
- McBride, S.RICE: Simple prioritization for product managers. Intercom.