Roadmap pública desde tu issue tracker, tres columnas

Una roadmap pública es una lista de lo que pretendes construir, publicada donde los clientes la puedan ver. La palabra que hace el trabajo es pretendes: una roadmap es un conjunto de promesas sobre el futuro, y cada elemento en ella es uno que vas a cumplir o se verá que no cumples. Esa es la razón para publicar una, y también es la razón por la que la mayoría de las roadmaps públicas se vuelven obsoletas en un trimestre. La versión que sobrevive es pequeña, se deriva de datos que ya mantienes, y está conectada en el otro extremo al changelog, para que una promesa se convierta en un hecho sin que nadie la vuelva a introducir.

¿Para qué sirve una roadmap pública?

Una roadmap pública le dice a una clienta con una petición que la petición fue escuchada, antes de que se lance. Es la mitad temprana de cerrar el ciclo: “planeado” responde la pregunta “¿alguien leyó esto?”, y “en construcción” responde “¿realmente está pasando?”. Ninguna de las dos sustituye el último paso, avisarle a quien preguntó cuando se lanza, pero ambas reducen la cantidad de gente que pregunta mientras tanto.

También hace algo por el equipo: fuerza un compromiso público, que es la cura más barata conocida para un backlog que guarda en silencio cuatrocientos elementos que nadie va a construir.

Tres columnas, en orden fijo, son suficientes. Una cuarta columna (“en consideración”, “bajo revisión”, “backlog”) es donde las buenas intenciones se convierten en un museo, y es la primera que los clientes aprenden a ignorar.

¿Debería tu roadmap ser pública?

Hazla pública si puedes mantenerla pequeña y honesta; mantenla privada si la alternativa es una larga lista de tal vez. El costo de una roadmap pública no tiene nada que ver con publicarla: cada elemento en ella es ahora una pregunta que alguien va a hacer, en soporte, en llamadas de ventas y en conversaciones de renovación. Diez elementos que vas a construir son un activo. Sesenta elementos que quizás construyas son sesenta conversaciones futuras sobre por qué no.

Dos razones honestas para no publicar: tus planes cambian más rápido que un trimestre, o tu competencia lee tu roadmap con más atención que tus clientes. Ambas son reales, y ambas se responden publicando menos en vez de nada: solo “en construcción”, con “planeado” mantenido interno, igual le dice a quien preguntó que su issue se está moviendo.

¿Cómo se construye una roadmap pública a partir de issues de GitHub?

Pon una etiqueta por columna en los issues que ya rastreas, y renderiza los issues etiquetados como la roadmap. Nada se vuelve a introducir, la roadmap no puede desviarse del trabajo, y el mismo issue que empezó como petición de un cliente se mueve por las columnas sin cambiar de identidad.

El mecanismo, tal como lo ejecutamos:

1. Una etiqueta por columna, con prefijo fijo: roadmap:planned, roadmap:building, roadmap:shipped. Cualquier issue en un repositorio conectado que lleve una aparece en esa columna. Un issue sin ninguna de ellas no está en la roadmap, que es la mayoría de los issues, lo cual es correcto.
2. Las columnas son un arreglo ordenado, siempre en el mismo orden. Planeado, en construcción, lanzado. No un mapa indexado por nombre, para que una lectora (o un widget) nunca tenga que adivinar la secuencia.
3. Si un issue lleva dos etiquetas, gana la más avanzada. Alguien va a añadir roadmap:shipped antes de quitar roadmap:planned; una máquina de estados guiada por “qué webhook llegó último” pondría el elemento en columnas distintas según el orden de entrega. Decidir solo a partir del conjunto de etiquetas hace que la respuesta sea la misma sin importar cómo lleguen los eventos.
4. Lanzado es un estado de etiqueta como los demás. La tarjeta se mueve cuando el issue recibe roadmap:shipped, o se cierra mientras la lleva. La tarjeta en sí no enlaza a la entrada de changelog; la entrada, redactada a partir del pull request que cerró el issue, es donde viven los detalles.
5. Sírvela como datos. La roadmap es un documento JSON con esas tres columnas, publicado junto al feed de changelog con los mismos headers de caché, para que un sitio de docs, un widget o una página de estado la puedan renderizar sin una segunda integración. La documentación del feed tiene la forma exacta.

Una etiqueta es poco pedirle a una mantenedora, y es toda la integración. Ningún tablero que mantener sincronizado, ninguna herramienta separada en la que iniciar sesión, y la petición que archivó la clienta es el elemento en la roadmap; cuando se lanza, es el mismo elemento.

¿Qué no debería contener una roadmap pública?

No debería contener fechas, estimaciones, ni nada que te avergonzaría que te preguntaran en nueve meses. Las fechas son el error clásico: un trimestre en una roadmap se convierte en un compromiso en una presentación de ventas se convierte en un ticket llamado “dijeron Q3”. Las columnas dicen lo suficiente. “En construcción” ya significa “pronto, lo bastante como para que alguien esté en ello”.

Tampoco debería contener el backlog interno. Una roadmap con trescientos elementos es un problema de búsqueda, no una promesa, y la clienta que encuentra su petición en la posición 212 aprendió algo que no querías decirle.

¿Cómo se conecta la roadmap con el changelog?

La roadmap y el changelog describen los mismos issues desde dos lados, uno para el futuro y otro para el pasado. Nadie mueve una tarjeta en un tablero aparte. Una mantenedora cambia la etiqueta en el issue en el que ya estaba trabajando, la entrada se redacta a partir del pull request, y cuando una persona aprueba esa entrada, a quien preguntó y cuyo feedback del widget se convirtió en ese issue se le avisa en él. Mover la tarjeta a lanzado sigue siendo un paso propio, la etiqueta roadmap:shipped, así que hazlo parte de la misma revisión; aprobar la entrada no lo hace por ti.

Este es el mismo ciclo que describe el artículo del ciclo de feedback desde el lado del changelog; la roadmap es lo que la clienta ve en medio de él. La recopilación herramientas de changelog cubre qué productos ofrecen una vista de roadmap y cuáles la tratan como un tablero separado, que es la diferencia que decide si se mantiene precisa.

¿Cómo se ve una buena roadmap pública?

Se ve corta, y cada elemento en ella es un issue que alguien puede abrir. La prueba es si una clienta puede ir de un elemento a la discusión detrás de él, y de un elemento lanzado a la entrada que describe qué cambió realmente. Una roadmap que es una lista de nombres de función sin entrada es un folleto.

Un ejemplo trabajado, como el JSON que buscaría un widget:

{
  "columns": [
    { "column": "planned", "hasMore": false, "items": [
      { "id": "6b0c1f...", "column": "planned",
        "publicTitle": "Saved views on the inbox",
        "publicDescription": "Keep a filter you use often and come back to it.",
        "publishedAt": "2026-09-16T10:04:11.000Z" }
    ]},
    { "column": "building", "hasMore": false, "items": [
      { "id": "71a4e2...", "column": "building",
        "publicTitle": "Roadmap column in the widget",
        "publicDescription": "See what is coming without leaving the page.",
        "publishedAt": "2026-09-12T08:20:02.000Z" }
    ]},
    { "column": "shipped", "hasMore": false, "items": [
      { "id": "5c9d70...", "column": "shipped",
        "publicTitle": "Feedback filed as labelled issues",
        "publicDescription": "Widget submissions arrive as issues your triage already handles.",
        "publishedAt": "2026-09-02T15:41:37.000Z" }
    ]}
  ],
  "enabled": true,
  "language": "en"
}

Tres elementos en tres columnas son una roadmap pública perfectamente buena. Dice qué viene, qué está pasando, y qué pasó, y cada línea de ella es comprobable. Otros cinco formatos, de Now/Next/Later a por resultados, se muestran con elementos de ejemplo en ejemplos de roadmap de producto.

FAQ

¿Cuántos elementos debería tener una roadmap pública? Los menos que puedas defender. Menos de diez en total es normal para un producto pequeño; más de treinta en “planeado” es un backlog disfrazado de roadmap.

¿Debería una roadmap pública tener fechas? No. Las columnas comunican secuencia sin crear un plazo. Si una clienta necesita una fecha, eso es una conversación, no un elemento de roadmap.

¿Deberían votar los clientes sobre elementos de la roadmap? Los votos miden quién se presentó, no qué importa. Un comentario en el issue explicando la solución alternativa que usan hoy vale más que cincuenta votos, y le cuesta algo a quien vota, que es el punto.

¿Qué pasa con un elemento de roadmap que se cancela? Quita la etiqueta y di por qué en el issue. Un “no vamos a hacer esto” público es parte del ciclo, y es el mensaje que la mayoría de los equipos nunca envían.

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.

Relacionado en changeloop: Documentación para desarrolladores, Herramientas de changelog comparadas