Public Roadmap Examples: Four Patterns and When Each Works

A public roadmap answers one question your users keep asking: "are you working on the thing I need?" Firm dates invite deadline arguments, a board of statuses invites people to watch a card move, and a page of votes invites campaigning. Each shape sets a different expectation, so choose one on purpose.

Below are four common patterns, with examples from companies' own roadmap pages, then what to show, what to keep private and how often to update. Each example is described as its page stood in archived copies from June and early July 2026, and the links go to the live pages, which may have changed since.

The short version

• Now, next, later gives direction without dates. It suits small teams.
• A timeline by month or quarter helps customers who plan around you. Every date on it is a promise someone will remember.
• A kanban board by status shows progress rather than dates, and stays current if the statuses come from your own workflow.
• An idea board with votes is where requests start. It feeds a roadmap rather than replacing one.
• Whatever the shape, a roadmap that is updated when work changes beats a prettier one that goes stale.

Pattern 1: Now, next, later

Three groups and no dates: what you are building, what comes after, and what you are still thinking about. Distance on the page stands for confidence, not for a calendar.

Mastodon's roadmap is a clean version of it. Each item is a short card with a one-line explanation, labelled Released, Next release or Exploring. The next-release items name the version they are expected in, which gives a sense of timing without a date. Exploring items, such as moderation tools, read as problems under study, not promises.

When it fits: you ship in releases rather than to a calendar, your users want direction rather than dates, and your plans can change within a quarter. The weakness is the "later" group, which fills up and never empties. Prune it as firmly as you add to it.

Pattern 2: A timeline by month or quarter

Items sit under the period you expect to deliver them in. Business customers ask for this, because they plan budgets and migrations around it.

GitHub's public roadmap puts each item on a project board in the column for the quarter it is expected to ship in next, plus an Exploratory column for work with no timeframe yet. Each item is an issue labelled with its release phase, such as preview or general availability, and is closed with a link to the changelog post when it is delivered. A plain disclaimer says the roadmap is not a commitment to deliver anything by a particular date.

Atlassian's cloud roadmap tags each item as Released, Coming soon or Future, with a quarter such as Q3 2026, and offers a quarterly email of what has been released and which time frames have moved. The Microsoft 365 roadmap goes finer: each item has a status (In development, Rolling out or Launched) and an estimated rollout start date, and the page says that information is subject to change and that items are removed once they are generally available, cancelled or postponed.

When it fits: your customers schedule their own work around your releases, you can estimate a quarter ahead with reasonable confidence, and you are willing to say publicly when a date moves. GitHub and Microsoft both pair their dates with a statement that dates can change. A timeline without one reads as a contract.

Pattern 3: A kanban board by status

Columns are stages, cards move from left to right, and there are no dates. People see that something is moving without anyone promising when it lands.

The AWS containers roadmap is the textbook case. Its stages are Researching, We're working on it, Coming soon and Just shipped, and the README explains each one in a sentence. Its FAQ explains the missing dates: security and operational stability take priority over target dates. Community requests arrive as issues tagged Proposed.

Buffer's roadmap uses the same idea for a social media tool, with columns that run from Exploring through In Progress and Beta to Released.

When it fits: you want to show progress without committing to dates, your statuses already live in the tool where the work happens, and users mostly want to know whether something has started. Keep the column names plain. "In progress" needs no explanation. A column called "Cooking" does.

Pattern 4: An idea board with votes

An idea board is where requests come in. Users submit ideas, vote on other people's and comment. It is not a roadmap, because nothing on it is a decision yet, but it feeds one.

Buffer runs both side by side: suggestion boards where people submit ideas and upvote them, next to the roadmap that shows what was picked up. GitHub points roadmap questions and comments to its public feedback discussions rather than to the roadmap itself. The roadmap stays a statement from the team, and the conversation happens next door.

When it fits: you want demand data, you can answer what comes in, or at least move it to a status, and you treat votes as one input next to revenue and effort. The prioritisation frameworks overview covers how to combine them. The risk is a board full of ideas with no answers. A request with 200 votes and no reply for a year says more about you than any roadmap.

What to show and what to keep private

Show

• The problem, in the user's words. "Use maps without signal" is clearer than "Tile cache v2".
• A rough horizon. A month, a quarter or a group. Get more precise as the work gets closer.
• The status. Exploring, building, in beta, released.
• A line saying the roadmap can change. GitHub, AWS and Microsoft all carry one.

Keep private

• Exact dates far ahead. They will move, and people will screenshot them.
• Customer names and deal-driven items. "Built for one large customer" helps nobody else.
• Security work and anything a competitor could act on. AWS's FAQ says some launches come without notice. That is a fair line.
• Items you are not committed to. If you would not want to explain why it was dropped, keep it on the idea board.

How often to update

A fixed review. The Kotlin roadmap shows when it was last updated and when the next update is due, is revised roughly every six months, and lists what was completed, added and removed since the previous version. That suits big themes. For an app, a monthly review is a more natural rhythm.

Updates as a by-product. When the roadmap reads from the statuses you set during normal work, it is current whenever your backlog is. That is the version that survives a busy quarter.

Either way, tell the people who asked when something moves. A changed card helps those who check the page. An email reaches those who are waiting. Closing the loop with status emails covers that part.

A worked example: Trailmate

Trailmate, a fictional hiking app, has Offline maps (248 votes), Trail difficulty filter (131) and Elevation profile (87) at the top of its list. Hikers do not plan projects around it, so a month-by-month timeline promises more than they need. A board showing Offline maps In Progress and the filter Approved, beside an idea board where elevation profiles keep collecting votes, answers what they actually ask: has it started, and how do I push for mine?

How FeedbackKit fits in

FeedbackKit puts the idea board inside your app. Users submit requests, vote and comment through the SDK screens for Swift and SwiftUI, Kotlin, Flutter and React Native, or through your own screens built on the headless JavaScript SDK. A new request starts with its submitter's vote, voting stops at Completed or Rejected, and every request carries one of six statuses: Pending, Approved, In Progress, TestFlight, Completed and Rejected.

FeedbackKit can also show a project's roadmap and its board of requests on your own website through an iframe, and it has a feedback form page you can embed the same way. The roadmap lists the feature requests you mark for it, grouped by target month, with requests that have no date under "On Our Radar". The board shows open requests in status columns with their vote counts, and visitors can vote on it when you turn voting on. A visitor is counted by an anonymous ID kept in their browser, with no sign-in. The form takes a title, a category, a description and an optional name and email. You turn embedding on per project in the web dashboard, which gives you the iframe code and a direct link for each page. Embeds are on every plan, in light or dark. There is no changelog for your users, and no roadmap site hosted on your own domain.

In terms of the patterns above, the roadmap embed is a timeline by month and the board embed is a kanban by status, both built from the requests you already manage. There is no now, next, later view, though undated items under "On Our Radar" come close to a "later" group. Plans are on the pricing page.

Here is how voting looks in FeedbackKit, with sample data from a fictional hiking app:

Pick the roadmap shape your users can read at a glance, keep it honest about what can change, and let it update as part of your normal work. To collect the requests and votes that feed it inside your own app, start free.