Roadmap de producto: cómo priorizar el desarrollo
Un roadmap no es una lista de features con fechas. Es una herramienta estratégica que articula qué outcomes perseguís, en qué orden y con qué nivel de certeza.
Qué es un roadmap de producto
Un roadmap de producto es la representación visual de la estrategia de producto en el tiempo: qué vas a construir, en qué secuencia y por qué cada decisión importa más que las alternativas que descartaste. Marty Cagan, en Empowered (cap. 8), lo define como "un instrumento de alineación, no un contrato de entrega". El roadmap no promete fechas — articula dirección.
La distinción es crítica. Un roadmap tratado como contrato produce equipos que entregan features a tiempo pero sin impacto — porque el compromiso es con la lista, no con el resultado. Un roadmap tratado como instrumento estratégico produce equipos que entregan outcomes medibles aunque las features específicas cambien en el camino. La propuesta de valor debería ser el filtro que gobierna qué entra al roadmap: si una feature no fortalece la propuesta, no importa cuántos clientes la piden.
Dan Olsen, en The Lean Product Playbook (cap. 11), conecta el roadmap con la pirámide de product-market fit: cada item del roadmap debería atacar una capa específica de la pirámide — mejorar la comprensión del cliente, fortalecer la propuesta, expandir features o pulir la experiencia. Un roadmap sin conexión con el PMF es una lista de deseos disfrazada de estrategia.
02Now / Next / Later: el modelo de horizontes
El modelo Now/Next/Later reemplaza al Gantt chart como formato de roadmap en equipos de producto modernos. La razón es epistemológica: cuanto más lejos mirás, menos sabés. Un Gantt de 12 meses con features específicas y fechas fijas es una ficción — el mercado cambia, los datos te sorprenden, las prioridades se reconfiguran. El modelo de horizontes refleja la realidad de lo que sabés con certeza y lo que es todavía hipótesis.
Lo que estamos construyendo ahora. Features definidas, equipo asignado, sprint en curso. Alta certeza de qué y cómo.
Ejemplo: "Mejorar onboarding — reducir tiempo de activación de 3 días a 1 día."
Certeza: alta (90%+)Lo que viene después. Outcome definido, solución en exploración. Sabemos qué problema atacar pero no exactamente cómo.
Ejemplo: "Reducir churn de mes 3 — hipótesis: alertas predictivas + intervención proactiva."
Certeza: media (50-70%)Lo que exploramos para el futuro. Dirección estratégica, oportunidades identificadas. Todo es hipótesis.
Ejemplo: "Expandir a segmento enterprise — requiere investigación de mercado y rediseño de pricing."
Certeza: baja (<30%)Janna Bastow, cofundadora de ProdPad, popularizó este modelo argumentando que reduce dos problemas simultáneamente: la ansiedad del equipo (saber qué viene) y la rigidez del plan (poder cambiar cuando los datos lo exigen). La priorización opera dentro de cada horizonte: en Now priorizás entre features; en Next priorizás entre outcomes; en Later priorizás entre direcciones estratégicas.
03Priorización: RICE y el arte de decir que no
El roadmap más valioso es el que dice qué NO construir. Cada feature que entra al backlog compite con todas las demás por el recurso más escaso: tiempo de ingeniería. Sean McBride formalizó el framework RICE (Reach × Impact × Confidence / Effort) como método de scoring para priorizar con criterio en lugar de intuición o política interna.
Reach: ¿a cuántos usuarios impacta? Una feature para el 80% de los usuarios pesa más que una para el 5%. Los datos de analítica te dicen el reach real — no el imaginado.
Impact: ¿cuánto mueve la North Star Metric? Una feature que reduce el churn un 10% tiene más impacto que una que agrega un filtro cosmético al dashboard.
Confidence: ¿cuánta evidencia tenés de que va a funcionar? Una feature validada con un prototipo y 20 usuarios tiene más confianza que una que salió de un brainstorm sin datos. La experimentación previa al roadmap aumenta la confianza y reduce el riesgo de invertir en la dirección equivocada.
Effort: ¿cuánto cuesta construirla? En semanas de ingeniería, no en complejidad percibida. Una feature de alto impacto y bajo esfuerzo es "quick win"; una de bajo impacto y alto esfuerzo es "time sink". Las quick wins generan momentum y credibilidad del equipo de producto ante el resto de la organización.
Trabajé con un equipo de producto que tenía un roadmap de 47 features para los próximos 12 meses. Le pregunté: "¿cuáles son las 3 que más impactan la métrica que importa?" No pudieron responder. Cuando priorizamos con scoring de impacto × confianza × esfuerzo, 8 de las 47 concentraban el 80% del impacto potencial. Las otras 39 eran pedidos de clientes individuales disfrazados de features estratégicas.
Lisandro IserteRoadmap de features vs. roadmap de outcomes
Cagan hace la distinción más importante del producto moderno en Empowered (cap. 6): los equipos de features reciben una lista de qué construir; los equipos de outcomes reciben un resultado a lograr y descubren cómo lograrlo. El roadmap refleja esta diferencia.
Un roadmap de features dice "Q2: lanzar dashboard de analytics, Q3: agregar integración con Slack, Q4: rediseñar pricing page". Es predecible, fácil de comunicar y completamente rígido. El problema: si el dashboard de analytics no mueve la métrica que importa, igual se construyó porque estaba en el plan. El equipo cumplió el roadmap pero no generó impacto.
Un roadmap de outcomes dice "Q2: reducir tiempo de activación de 3 días a 1 día, Q3: aumentar retención de mes 2 un 15%, Q4: expandir revenue por usuario un 20%". Cada outcome tiene hipótesis de solución que el equipo explora con research y testing antes de construir. La feature que se construye es la que la evidencia validó — no la que alguien puso en un deck 6 meses antes.
La conexión con la estrategia de marca es directa: los outcomes del roadmap deberían reforzar el posicionamiento. Si tu marca se posiciona en "simplicidad" y el roadmap está lleno de features que agregan complejidad, hay una desconexión que la gobernanza de consistencia debería detectar. Sharp, en How Brands Grow, argumenta que la disponibilidad mental se construye con consistencia — y el roadmap es donde la coherencia entre promesa y producto se decide. La definición de territorio funciona como filtro: las features que caen fuera del territorio debilitan la posición.
05Errores frecuentes
El roadmap gobernado por el cliente más ruidoso
"El cliente X amenazó con irse si no agregamos esta feature." Y el equipo la construye. El problema: el cliente X es uno de cientos y su pedido no representa un job compartido. Cada feature construida para un cliente individual es deuda de producto que el resto de los usuarios paga con complejidad. La segmentación por ICP filtra: si el pedido viene de tu segmento core y refleja un job compartido, entra. Si viene de un outlier, se registra pero no se prioriza.
Priorizar por esfuerzo en lugar de por impacto
"Hagamos las fáciles primero." El roadmap se llena de quick wins que no mueven la aguja mientras las iniciativas de alto impacto (que requieren más esfuerzo) se postergan indefinidamente. La retención no mejora con 15 features cosméticas — mejora con 1-2 cambios estructurales que resuelven los dolores reales.
Roadmap sin métricas de éxito
Se construye la feature, se lanza, se pasa a la siguiente. Nadie mide si la anterior funcionó. Sin métricas de éxito definidas antes de construir, no hay forma de saber si el roadmap está generando valor o acumulando código. El tracking del impacto de cada feature debería ser parte del proceso de cierre — no un afterthought.
No comunicar el roadmap a marketing
El equipo de producto construye features que el equipo de marketing desconoce hasta el día del lanzamiento. El go-to-market necesita semanas de preparación — contenido, messaging, landing pages. Un roadmap compartido entre producto y marketing es la base de un lanzamiento que no improvisa.
Cómo diagnosticar un roadmap que no funciona
Si lanzás features pero las métricas no se mueven: el roadmap tiene un problema de impacto. Revisá si los items están conectados con outcomes medibles o si son features sueltas sin hipótesis de valor. La iteración post-lanzamiento importa tanto como el lanzamiento: una feature que se lanza y no se mide ni se mejora es una inversión a medias.
Si el equipo está siempre apurado pero el producto no avanza: el roadmap tiene un problema de priorización. Probablemente hay demasiados items en Now sin filtro de impacto. Aplicá RICE y recortá: las 3 iniciativas con mayor score reciben recursos; las demás esperan. La capacidad de diagnóstico cualitativo del equipo debería incluir una revisión trimestral de "qué construimos, qué impacto tuvo y qué aprendimos".
Si el roadmap cambia cada semana: no tenés roadmap — tenés un backlog reactivo. La causa suele ser que la dirección no tiene claridad sobre la North Star Metric. Sin NSM, todo parece igualmente urgente. Con NSM, solo lo que la mueve es verdaderamente prioritario — y el resto puede esperar. Los unit economics funcionan como filtro adicional: cada item del roadmap debería justificarse en términos de impacto sobre LTV, CAC o margen.
Preguntas frecuentes sobre roadmap de producto
¿Un roadmap es una lista de features con fechas?
No. El roadmap estratégico articula outcomes: qué resultados querés lograr, en qué orden, con qué certeza. Las features son hipótesis sobre cómo lograr esos outcomes. Los mejores equipos se comprometen al resultado, no a la feature específica.
¿Cómo equilibrar pedidos de clientes con visión de producto?
No se equilibran — se filtran. Cada pedido pasa tres preguntas: ¿resuelve un job compartido? ¿Se alinea con el posicionamiento? ¿Impacta la métrica que importa? Si no pasa las tres, se registra como feedback pero no como compromiso.
¿Cada cuánto se revisa el roadmap?
Now cada sprint. Next mensualmente. Later trimestralmente. La dirección estratégica no debería cambiar entre revisiones. Lo que cambia son las hipótesis de solución y prioridades dentro de cada horizonte.