A public roadmap from your issue tracker, in three columns

A public roadmap is a list of what you intend to build, published where customers can see it. The word doing the work is intend: a roadmap is a set of promises about the future, and every item on it is one you will either keep or be seen not to keep. That is the reason to publish one, and it is also the reason most public roadmaps go stale within a quarter. The version that survives is small, derived from data you already maintain, and connected at the far end to the changelog, so that a promise becomes a fact without anyone re-entering it.

What is a public roadmap for?

A public roadmap tells a customer with a request that the request was heard, before it ships. It is the early half of closing the loop: “planned” answers the question “did anyone read this”, and “building” answers “is it actually happening”. Neither replaces the last step, telling the requester when it ships, but both reduce the number of people who ask in the meantime.

It also does one thing for the team: it forces a public commitment, which is the cheapest known cure for a backlog that quietly holds four hundred items nobody will build.

Three columns, in a fixed order, is enough. A fourth column (“considering”, “under review”, “backlog”) is where good intentions go to become a museum, and it is the one customers learn to ignore first.

Should you make your roadmap public?

Make it public if you can keep it small and honest; keep it private if the alternative is a long list of maybes. The cost of a public roadmap has nothing to do with publishing it: every item on it is now a question someone will ask about, in support, in sales calls and in renewal conversations. Ten items you will build are an asset. Sixty items you might build are sixty future conversations about why not.

Two honest reasons not to publish: your plans change faster than a quarter, or your competitors read your roadmap more carefully than your customers do. Both are real, and both are answered by publishing less rather than nothing: “building” only, with “planned” kept internal, still tells a requester their issue is moving.

How do you build a public roadmap from GitHub issues?

Put a label per column on the issues you already track, and render the labelled issues as the roadmap. Nothing is re-entered, the roadmap cannot drift from the work, and the same issue that started as a customer’s request moves through the columns without changing identity.

The mechanism, as we run it:

1. One label per column, with a fixed prefix: roadmap:planned, roadmap:building, roadmap:shipped. Labelling an issue in a connected repository drafts a roadmap item for that column; it appears publicly once a human approves the draft, the same review step the changelog entries go through. An issue with none of them is not on the roadmap, which is most issues, which is correct.
2. The columns are an ordered array, always in the same order. Planned, building, shipped. Not a map keyed by name, so a reader (or a widget) never has to guess the sequence.
3. When an issue carries two labels, the furthest-along wins. Someone will add roadmap:shipped before removing roadmap:planned; a state machine driven by “whichever webhook arrived last” would put the item in different columns depending on delivery order. Deciding from the label set alone makes the answer the same however events arrive.
4. Shipped is a label state like the others. The card moves when the issue gets roadmap:shipped, or is closed while carrying it. The card itself does not link to the changelog entry; the entry, drafted from the pull request that closed the issue, is where the details live.
5. Serve it as data. The roadmap is a JSON document with those three columns, published beside the changelog feed with the same cache headers, so a docs site, a widget or a status page can render it without a second integration. The feed documentation has the exact shape.

A label is a small thing to ask of a maintainer, and it is the whole integration. No board to keep in sync, no separate tool to log into, and the request the customer filed is the item on the roadmap; when it ships, it is the same item.

What should a public roadmap not contain?

It should not contain dates, estimates, or anything you would be embarrassed to be asked about in nine months. Dates are the classic mistake: a quarter on a roadmap becomes a commitment in a sales deck becomes a ticket titled “you said Q3”. Columns say enough. “Building” already means “soon enough that someone is on it”.

It also should not contain the internal backlog. A roadmap with three hundred items is a search problem, not a promise, and the customer who finds their request in position 212 has learned something you did not mean to tell them.

How does the roadmap connect to the changelog?

The roadmap and the changelog describe the same issues from two sides, one for the future and one for the past. Nobody moves a card on a separate board. A maintainer changes the label on the issue they were already working in, the entry is drafted from the pull request, and when a human approves that entry a requester whose widget feedback became that issue is told on it. Moving the card to shipped is still its own step, the roadmap:shipped label, so make it part of the same review; approving the entry does not do it for you.

This is the same loop the feedback-loop article describes from the changelog side; the roadmap is what the customer sees in the middle of it. The changelog tools roundup covers which products offer a roadmap view and which treat it as a separate board, which is the difference that decides whether it stays accurate.

What does a good public roadmap look like?

It looks short, and every item says plainly what the customer will be able to do. The test is whether someone outside the team can read an item and know whether it solves their problem, without needing the issue behind it. That is deliberate here: a roadmap item publishes only the title and description written for it, never the source issue, its number or its repository, so an issue called “Fix auth bypass in /admin” cannot surface through the roadmap. A roadmap that is a list of bare feature names with nothing said about them is a brochure.

A worked example, as the JSON a widget would fetch:

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

Three items across three columns is a perfectly good public roadmap. It says what is coming, what is happening, and what happened, and every line of it is checkable. Five other layouts, from Now/Next/Later to outcome-based, are shown with sample items in product roadmap examples.

FAQ

How many items should a public roadmap have? As few as you can defend. Under ten across all columns is normal for a small product; more than thirty in “planned” is a backlog wearing a roadmap’s clothes.

Should a public roadmap have dates? No. Columns communicate sequence without creating a deadline. If a customer needs a date, that is a conversation, not a roadmap item.

Should customers vote on roadmap items? Votes measure who showed up, not what matters. A comment on the issue explaining the workaround they use today is worth more than fifty votes, and it costs the voter something, which is the point.

What happens to a roadmap item that is cancelled? Remove the label and say why on the issue. A public “we are not doing this” is part of the loop, and it is the message most teams never send.

The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.

Related on changeloop: Developer docs, Changelog tools compared