Un roadmap público de producto es un artefacto engañosamente simple. Visto desde fuera parece un kanban con tres columnas: qué está planeado, qué se está construyendo, qué se shippeó. Visto desde dentro es una pieza de estrategia de comunicación que decide qué clientes se sienten informados, qué competidores se sienten amenazados y qué ingenieros se sienten comprometidos con una fecha que no eligieron. Bien hecho, un roadmap público es la superficie de marketing de mayor palanca que tiene un equipo de producto. Mal hecho se convierte en una serie de promesas rotas que todo el mundo aprende a ignorar.

ProductPlan, en su guía completa sobre roadmaps de producto, lista cinco propósitos que un roadmap debería cumplir: describir la visión y estrategia, guiar la ejecución, alinear stakeholders internos, facilitar discusiones de planning y comunicar con partes externas. Un roadmap público cumple principalmente el último, pero hereda restricciones de los cinco. Esta guía se enfoca en la superficie pública: qué mostrar, qué ocultar y cómo mantener vivo el artefacto.

Público vs interno: dos documentos distintos

El roadmap interno y el roadmap público no son el mismo artefacto con permisos distintos. Son documentos distintos que comparten una fuente de verdad subyacente. La versión interna tiene fechas, owners, dependencias, impacto en ingresos, asignaciones de headcount e items que mencionan a clientes por nombre. La versión pública muestra temas, marcos temporales vagos ("este trimestre", "más adelante") e items expresados como beneficios para el usuario, no como tareas de ingeniería.

Si publicas la versión interna tal cual, pasarás el siguiente mes explicando por qué una fecha se corrió, por qué la feature de un cliente saltó la cola y por qué al equipo se le permite siquiera estimar. Si publicas una versión demasiado vaga ("estamos trabajando en mejoras"), los usuarios no se molestarán en mirar. La granularidad correcta está en el medio: específica como para que un lector decida si se queda esperándola, vaga como para que nadie la confunda con un contrato.

Tres columnas que funcionan para casi cualquier equipo

El default de Roaderly es Proposed, In Progress y Shipped. Los nombres de los stages importan menos que lo que comunican:

  • Proposed le dice al lector que el equipo lo está considerando. Sin compromiso, sin fecha. El voting y la discusión están abiertos.
  • In Progress le dice al lector que el equipo ya empezó el trabajo. Aún sin fecha, pero con suficiente confianza para invertir en research, diseño o código.
  • Shipped cierra el loop. El post enlaza a release notes, anuncio en el blog o cualquier artefacto que permita usar la cosa.

Algunos equipos agregan una cuarta columna (Under Consideration, Researching, Beta). Está bien, pero cada columna extra hace al roadmap más difícil de escanear. Si no estás seguro de que una columna se gana su espacio, no la sumes.

Qué poner en un roadmap público (y qué no)

Si un competidor viendo el roadmap cambiara su comportamiento mañana, el item es demasiado específico.

Cosas que pertenecen al roadmap público:

  • Features que tus usuarios llevan pidiendo, en su lenguaje.
  • Mejoras a capacidades existentes que resuelven pain points conocidos.
  • Temas en los que quieres que los usuarios sepan que estás invirtiendo, aunque la forma exacta esté indecisa.

Cosas que deben quedarse fuera:

  • Items atados a ciclos de deal específicos o cuentas nombradas.
  • Items que dependen de rewrites de infraestructura donde el resultado visible para el usuario es incierto.
  • Items que existen sólo para igualar a un competidor y no tienen demanda orgánica en tus propios boards.
  • Cualquier cosa con fecha cerrada cuando el equipo aún no ha sostenido esa fecha.

Atar el roadmap al feedback

Un roadmap que no se conecta al feedback entrante se siente como una nota de prensa. Un roadmap que vive en la misma herramienta que el board de feedback es un sistema. Cada item en Proposed debería enlazar a los requests o votos originales que justifican su existencia. Cada item en Shipped debería notificar a los usuarios que votaron. El punto no es darle veto a los usuarios, sino hacer legible la conexión entre input y output.

Esta es también la jugada de SEO más subestimada del marketing de producto. Una página de roadmap público con URLs estables por item, indexada por buscadores, posiciona para queries long-tail tipo "¿soporta <producto> <feature>?" durante años. Los usuarios que buscan si tienes algo aterrizan muchas veces en un post Proposed o In Progress antes de llegar a tu homepage.

Cada cuánto actualizar

Dos cadencias mantienen útil a un roadmap público. Semanal: al menos un movimiento (Proposed a In Progress, o In Progress a Shipped). El movimiento es la señal. Si nada se mueve en tres semanas, los lectores asumen que el roadmap es decorativo. Trimestral: una auditoría. Archiva items en Proposed que el equipo no va a construir realmente. Reordena en base a lo que cambió en los últimos 90 días. Escribe una nota corta (un párrafo) arriba del roadmap explicando el tema del próximo trimestre.

Para qué NO sirve un roadmap público

Un roadmap público no es una herramienta de project management. No es donde los ingenieros trackean sus tareas, donde sales trackea features atadas al pipeline o donde customer success trackea escalations individuales. Tratar de hacer que el roadmap público sirva a esas audiencias es cómo termina siendo demasiado detallado para los usuarios y demasiado sanitizado para el equipo. Mantén esos flujos en las herramientas diseñadas para eso (Jira, Linear, tu CRM). El roadmap público existe para hacer exactamente un trabajo: decirle a los usuarios qué viene, en un lenguaje sobre el que pueden actuar.

Lanza un roadmap público en Roaderly con stages, voting y un board de feedback que lo alimenta, todo en un solo lugar.