A public roadmap usually takes one of four shapes: a three-column now/next/later board, a status-based list running from under review to shipped, a quarter-based calendar, or a single list ranked by votes. Each suits a different kind of product, and each fails in its own specific way once real requests start landing on it.
None of these is a template you copy once and forget. A roadmap is a live document that has to survive contact with customers who read literally, competitors who read carefully, and a team whose priorities change every few months. The structure you pick decides which of those pressures breaks it first.
This page is one part of a larger guide. For the whole subject in one place, see public roadmaps.
What is a three-column now/next/later roadmap?
This is the simplest structure and the one most teams start with. Everything sits in one of three columns. Now holds what is actively being built. Next holds what is committed but not started yet. Later holds ideas that are real, requested, and worth doing, but have no slot.
A worked example, for a small note-taking tool: Now carries "Offline sync for mobile" and "Markdown export". Next carries "Shared folders" and "A public API". Later carries "Team billing" and "A browser extension", both requested regularly but not yet worth pulling forward.
Who it suits: small teams shipping continuously, where the honest answer to "when" is usually "not yet decided". The three columns never promise a date, and Later genuinely means "not yet", not a polite way of saying no.
How it fails: nothing forces an item to move. Next is meant to be short-lived, a holding area for things about to start, but with no mechanism pushing items along, it quietly becomes a second queue. A request can sit in Next for a year, still reading as imminent, while the team works on things that were never listed at all.
What is a status-based roadmap?
Instead of three columns, each item carries a status: under review, planned, in progress, shipped. Mastodon's public roadmap is a live example, running released, next release and exploring with no dates attached to any of them. Sometimes a fifth status, declined, sits off to the side so people can see what was considered and ruled out rather than just ignored.
A worked example: "Dark mode for the editor" is shipped. "Bulk tag editing" is in progress. "Custom keyboard shortcuts" is planned. "A native iOS app" is under review, with forty votes and a note that the team is scoping it. "A Windows Phone client" is declined.
Who it suits: teams that also run a feature request board and want the roadmap to read as the next stage of that board, so a submission can visibly travel from vote to shipped without anyone needing to ask what happened to it.
How it fails: "under review" becomes the place things go to avoid an awkward no. It costs nothing to leave an item there indefinitely, so teams do, and after enough months of that the status stops meaning anything. Customers learn to read "under review" as "unlikely", which is the opposite of what the status was for.
Why do quarter-based roadmaps usually go wrong?
This structure sorts work into calendar buckets: Q1, Q2, Q3, and so on. GitHub's own public roadmap works this way, adding every item to a project board column according to the quarter it is expected to ship in. It looks the most organised of the four, and it is the one enterprise buyers ask for by name, because they are used to planning their own renewals and budgets around a vendor's calendar.
A worked example: Q1 carries "SSO support" and "Audit log export". Q2 carries "Granular permissions" and "A usage dashboard". Q3 is left blank, described as "to be scoped".
Who it suits: vendors selling into procurement processes where a buyer genuinely needs to plan a purchase around a feature landing, most often security or compliance items tied to a contract renewal.
How it fails: a quarter label reads as a date to the person reading it, no matter how many caveats surround it. Software slips. The moment one Q2 item moves to Q3, every other item in that column looks broken too, even the ones on schedule, because the column itself has lost credibility. Sales teams then start quoting the roadmap inside live deals, and a rough internal plan becomes a commitment nobody in engineering actually made.
What is a voting-ordered roadmap list?
Here there are no columns or statuses at all, just a single list, sorted by the number of votes each item has received. The top of the list is whatever the loudest section of the audience wants most, updated automatically as votes come in.
A worked example: "Recurring tasks" sits at the top with 340 votes. "A dark theme" is second with 210. "An export to PDF" is eighth with 40, submitted eight months ago and unlikely to move given how the list is sorted.
Who it suits: early-stage products that genuinely do not know what to build next and want the loudest available signal, unfiltered by anyone's judgement about which request matters more.
How it fails: vote count rewards whichever group is most active online, not whichever request carries the most value. A cosmetic request with two hundred votes from free users can permanently outrank a request from three paying accounts worth real revenue between them, because the list has no way to weight a vote by who cast it.
How do the four compare?
| Structure | Who it suits | How it fails |
|---|---|---|
| Now / Next / Later | Small teams shipping continuously | Next fills up and never empties |
| Status-based | Teams pairing a roadmap with a feature request board | "Under review" becomes a polite no |
| Quarter-based | Vendors selling into procurement cycles | One slip breaks the credibility of the whole quarter |
| Voting-ordered | Early products with no clear priority yet | Loudest wins, not most valuable |
One payment, no subscription, unlimited products.
Can you combine structures?
Most working roadmaps are hybrids rather than a pure version of any one structure above. A common combination is status inside now/next/later: each column holds a handful of items, and each item also carries a status, so a card in Next can say "planned" or "in progress" without pretending to be scheduled to the week. Vote counts can sit quietly on each card as a signal for prioritisation without becoming the only sort order, which keeps the loudest requests visible without letting them run the whole list.
The one thing worth resisting, whichever structure you choose, is letting the column or list count grow without limit. A roadmap with six items in Next reads as a real plan. A roadmap with sixty reads as a list nobody has cleaned in a year, whichever of the four structures it happens to be using.
Before publishing any of this, it is worth deciding whether a public roadmap is the right call at all: see should your roadmap be public for the case on both sides.
Frequently asked questions
Which roadmap structure is easiest to maintain?
The three-column now/next/later structure, because it asks the least of the team running it. There is no calendar to keep accurate and no vote count to keep fair, just three honest buckets that get reshuffled as work actually starts and finishes. The tradeoff is that it says the least about when anything will land.
Should a roadmap show declined items?
It is worth considering. Showing what was ruled out, and briefly why, stops the same request being resubmitted every few months and shows the team is actually reading what comes in. The risk is that a declined list reads as a graveyard if it is not paired with items that are genuinely moving, so it works best alongside an active in-progress or shipped column.
Can a voting-ordered list be weighted rather than pure vote count?
Yes, and many status-based or now/next/later roadmaps effectively do this by using vote count as one input to prioritisation rather than the sort order itself. A pure top-to-bottom vote list is the simplest version and the one most exposed to being dominated by whichever group votes most, rather than whichever request matters most.
How often should a public roadmap be updated?
Often enough that nothing on it looks abandoned. An item that has sat in the same status for six months with no comment reads as dead whether or not it actually is. Moving items between statuses or columns as work genuinely progresses, and removing anything that is no longer planned, matters more than any particular schedule for reviewing the page.
Does a quarter-based roadmap ever work for a small team?
Rarely, and it is usually not necessary. Quarter labels exist to answer a procurement question that small teams are not usually being asked, so a now/next/later or status-based structure gives the same honesty about priority without inviting a date-shaped promise the team cannot actually guarantee.