Roadmap público a partir do seu issue tracker, três colunas

Um roadmap público é uma lista do que vocês pretendem construir, publicada onde clientes podem vê-la. A palavra que faz o trabalho é pretendem: um roadmap é um conjunto de promessas sobre o futuro, e cada item nele é um que vocês vão cumprir ou será visto que não cumpriram. Essa é a razão para publicar um, e é também a razão pela qual a maioria dos roadmaps públicos envelhece em um trimestre. A versão que sobrevive é pequena, derivada de dados que vocês já mantêm, e conectada na outra ponta ao changelog, para que uma promessa vire um fato sem que ninguém a reinsira.

Para que serve um roadmap público?

Um roadmap público diz a uma cliente com um pedido que o pedido foi ouvido, antes de ser lançado. É a metade inicial do fechamento do ciclo: “Planejado” responde a pergunta “alguém leu isso”, e “Em construção” responde “isso está realmente acontecendo”. Nenhum dos dois substitui o último passo, avisar quem pediu quando for lançado, mas ambos reduzem o número de pessoas que perguntam enquanto isso.

Também faz algo pela equipe: força um compromisso público, que é o remédio mais barato conhecido para um backlog que silenciosamente guarda quatrocentos itens que ninguém vai construir.

Três colunas, em ordem fixa, bastam. Uma quarta coluna (“em consideração”, “em revisão”, “backlog”) é onde boas intenções viram um museu, e é a primeira que clientes aprendem a ignorar.

Seu roadmap deveria ser público?

Torne-o público se vocês conseguem mantê-lo pequeno e honesto; mantenha-o privado se a alternativa é uma longa lista de talvez. O custo de um roadmap público não tem nada a ver com publicá-lo: todo item nele agora é uma pergunta que alguém vai fazer, no suporte, em ligações de vendas e em conversas de renovação. Dez itens que vocês vão construir são um ativo. Sessenta itens que vocês talvez construam são sessenta conversas futuras sobre por que não.

Duas razões honestas para não publicar: os planos de vocês mudam mais rápido que um trimestre, ou a concorrência de vocês lê o roadmap com mais cuidado que seus clientes. Ambas são reais, e ambas são respondidas publicando menos em vez de nada: só “em construção”, com “planejado” mantido interno, ainda diz a quem pediu que a issue dele está se movendo.

Como se constrói um roadmap público a partir de issues do GitHub?

Coloque uma etiqueta por coluna nas issues que vocês já acompanham, e renderize as issues etiquetadas como o roadmap. Nada é reinserido, o roadmap não consegue se desviar do trabalho, e a mesma issue que começou como um pedido de cliente se move pelas colunas sem mudar de identidade.

O mecanismo, do jeito que rodamos:

1. Uma etiqueta por coluna, com prefixo fixo: roadmap:planned, roadmap:building, roadmap:shipped. Qualquer issue em um repositório conectado que carregue uma aparece nessa coluna. Uma issue sem nenhuma delas não está no roadmap, o que é a maioria das issues, o que é correto.
2. As colunas são um array ordenado, sempre na mesma ordem. Planejado, em construção, lançado. Não um mapa indexado por nome, para que uma leitora (ou um widget) nunca tenha que adivinhar a sequência.
3. Se uma issue carrega duas etiquetas, a mais avançada vence. Alguém vai adicionar roadmap:shipped antes de remover roadmap:planned; uma máquina de estados guiada por “qual webhook chegou por último” colocaria o item em colunas diferentes dependendo da ordem de entrega. Decidir só a partir do conjunto de etiquetas faz a resposta ser a mesma independente de como os eventos chegam.
4. Lançado é um estado de etiqueta como os outros. O cartão se move quando a issue recebe roadmap:shipped, ou é fechada enquanto tem essa etiqueta. O cartão em si não linka para a entrada de changelog; a entrada, redigida a partir do pull request que fechou a issue, é onde ficam os detalhes.
5. Sirvam como dados. O roadmap é um documento JSON com essas três colunas, publicado ao lado do feed de changelog com os mesmos headers de cache, para que um site de docs, um widget ou uma página de status possam renderizá-lo sem uma segunda integração. A documentação do feed tem a forma exata.

Uma etiqueta é pouco a pedir de uma mantenedora, e é toda a integração. Nenhum quadro para manter sincronizado, nenhuma ferramenta separada para fazer login, e o pedido que a cliente registrou é o item no roadmap; quando é lançado, é o mesmo item.

O que um roadmap público não deveria conter?

Não deveria conter datas, estimativas, ou qualquer coisa que envergonharia vocês se perguntassem daqui a nove meses. Datas são o erro clássico: um trimestre em um roadmap vira um compromisso em um deck de vendas vira um ticket chamado “vocês disseram Q3”. Colunas dizem o suficiente. “Em construção” já significa “logo o bastante para que alguém esteja nisso”.

Também não deveria conter o backlog interno. Um roadmap com trezentos itens é um problema de busca, não uma promessa, e a cliente que encontra seu pedido na posição 212 aprendeu algo que vocês não queriam dizer a ela.

Como o roadmap se conecta ao changelog?

O roadmap e o changelog descrevem as mesmas issues de dois lados, um para o futuro e um para o passado. Ninguém move um cartão em um quadro separado. Uma mantenedora muda a etiqueta na issue em que já estava trabalhando, a entrada é redigida a partir do pull request, e quando uma pessoa aprova essa entrada, quem pediu e teve o feedback do widget transformado nessa issue é informado nela. Mover o cartão para lançado continua sendo um passo à parte, a etiqueta roadmap:shipped, então façam isso na mesma revisão; aprovar a entrada não faz isso por vocês.

Este é o mesmo ciclo que o artigo do ciclo de feedback descreve pelo lado do changelog; o roadmap é o que a cliente vê no meio disso. O resumo ferramentas de changelog cobre quais produtos oferecem uma visão de roadmap e quais o tratam como um quadro separado, o que é a diferença que decide se ele permanece preciso.

Como se parece um bom roadmap público?

Parece curto, e todo item nele é uma issue que qualquer um pode abrir. O teste é se uma cliente consegue ir de um item para a discussão por trás dele, e de um item lançado para a entrada que descreve o que realmente mudou. Um roadmap que é uma lista de nomes de recursos sem entrada é um folheto.

Um exemplo trabalhado, como o JSON que um widget buscaria:

{
  "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"
}

Três itens em três colunas são um roadmap público perfeitamente bom. Diz o que está por vir, o que está acontecendo, e o que aconteceu, e cada linha dele é verificável. Outros cinco layouts, de Now/Next/Later a roadmaps por resultados, aparecem com itens de exemplo em exemplos de roadmap de produto.

FAQ

Quantos itens um roadmap público deveria ter? O menos possível que vocês consigam defender. Menos de dez no total é normal para um produto pequeno; mais de trinta em “planejado” geralmente é um backlog disfarçado de roadmap.

Um roadmap público deveria ter datas? Não. Colunas comunicam sequência sem criar um prazo. Se uma cliente precisa de uma data, isso é uma conversa, não um item de roadmap.

Clientes deveriam votar em itens do roadmap? Votos medem quem apareceu, não o que importa. Um comentário na issue explicando a solução alternativa que usam hoje vale mais que cinquenta votos, e custa algo a quem vota, que é o ponto.

O que acontece com um item de roadmap cancelado? Remova a etiqueta e diga o porquê na issue. Um “não vamos fazer isso” público faz parte do ciclo, e é a mensagem que a maioria das equipes nunca envia.

As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.

Relacionado na changeloop: Documentação para desenvolvedores, Comparativo de ferramentas de changelog