A product roadmap template is a fixed set of columns or fields you fill in rather than design from scratch. Below are four you can copy directly: a now/next/later board, a status-based list, a quarter-based calendar, and a minimal version for a single product. Which structure fits your product is a separate question, covered in public roadmap examples; this page is only the templates.
This page is one part of a larger guide. For the whole subject in one place, see public roadmaps.
What fields does a now/next/later roadmap need?
Three columns, each holding a short list of items. No dates, no percentages, just where each item currently sits.
NOW
-
-
NEXT
-
-
LATER
-
- - Now: what is actively being built, nothing else. If it isn't in progress, it doesn't belong here.
- Next: committed and scoped, not yet started. Keep this short; it is meant to turn over quickly.
- Later: real requests worth doing, with no slot yet. This is not a graveyard, just a holding area.
Who it suits: small teams shipping continuously, where the honest answer to "when" is "not yet decided". No column promises a date.
What fields does a status-based roadmap need?
Every item carries one status rather than sitting in a column. Mastodon's public roadmap runs a three-value version of this: released, next release, exploring. This version adds a declined status so people can see what was ruled out rather than just dropped.
Item:
Status: [under review / planned / in progress / shipped / declined]
Votes:
Notes: - Item: the request itself, named the way a customer would search for it, not the way engineering describes it internally.
- Status: the single most important field. Five values are enough; more than that and people stop reading them.
- Votes: optional, but useful as a secondary signal once you have more than a handful of items.
- Notes: a short line on what's blocking or driving the status, especially for anything marked declined.
Who it suits: teams that already run a feature request board, since a status-based roadmap can read as the next stage of that board rather than a separate document.
What fields does a quarter-based roadmap need, and why does it usually go wrong?
Work is sorted into calendar buckets rather than columns or statuses, the shape GitHub uses for its own public roadmap.
Q1
-
-
Q2
-
-
Q3
- to be scoped- Quarter labels: a date a reader will treat as a promise, however many caveats surround it.
- Items per quarter: keep this short. A quarter with eight items reads as padding, not planning.
- "To be scoped": an honest placeholder for a quarter you haven't planned yet, better than leaving it blank or guessing.
Why it usually goes wrong: software slips, and the moment one item moves from Q2 to Q3, every other item in that column loses credibility too, including the ones still on schedule. Quarter labels also get quoted inside sales conversations as commitments nobody in engineering actually made. This structure suits vendors selling into procurement cycles who are asked for it by name, most often for security or compliance work tied to a contract renewal. It is rarely worth it for a small team, because nobody is asking them for a quarter-shaped promise in the first place.
What does a minimal roadmap for a single product look like?
For a solo product or a small team, most of the fields above are overhead. This version fits on one page and takes minutes to update.
Building now:
-
Considering:
-
Won't do:
- - Building now: one to three items, no more. If everything is "now", nothing is.
- Considering: everything else that's been asked for and hasn't been ruled out.
- Won't do: short, and worth keeping. It stops the same request landing in your inbox every few months, and it shows you're actually reading what comes in.
Who it suits: a single product with one person or a small team deciding what's next, where a full status system or quarterly calendar would take longer to maintain than the roadmap itself is worth.
How do the four templates compare?
| Template | Fields | Best for |
|---|---|---|
| Now / Next / Later | Three columns, no dates | Small teams shipping continuously |
| Status-based | Item, status, votes, notes | Teams pairing a roadmap with a feature request board |
| Quarter-based | Calendar buckets, per-quarter items | Vendors selling into procurement cycles |
| Minimal | Building now, considering, won't do | A single product, one page |
One payment, no subscription, unlimited products.
Which one should you actually pick?
The templates above are interchangeable in structure but not in what they promise. Now/next/later and the minimal version promise the least and are the easiest to keep honest, since neither one attaches a date to anything. Status-based sits in the middle, useful mainly if you already have a feature request board feeding it, so an item can visibly travel from vote to shipped without anyone needing to ask what happened to it. Quarter-based promises the most and breaks the fastest once anything slips, so treat it as a last resort rather than a default, and reach for it only when a buyer is genuinely asking for a calendar rather than because it looks the most organised of the four.
Whichever template you start from, copy it as written first rather than adding fields before you've used it once. Extra columns and extra statuses are cheap to add and expensive to remove once customers have learned to read them a particular way; a roadmap that grows a "blocked" status or a fifth column six months in usually does it because a real gap showed up, not because the template was designed to have it from day one.
The full case for which structure fits which product, with worked examples of each one failing in practice, is in public roadmap examples. Start there once you've picked a template to fill in.
Frequently asked questions
Can I combine two of these templates?
Yes, and most working roadmaps do. 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.
Do I need a votes field on every template?
No. Votes are useful as a secondary signal once a list has enough items that ranking becomes hard, but they add nothing to a minimal roadmap with three items in "considering". Add the field when you need it, not before.
Should quarter labels ever be used by a small team?
Rarely. Quarter labels exist to answer a procurement question that small teams are not usually being asked. A now/next/later or status-based template gives the same honesty about priority without inviting a date-shaped promise the team cannot guarantee.
How many items should sit in each column or status?
Fewer than feels natural. A "Next" column with six items reads as a real plan; one with sixty reads as a list nobody has cleaned in a year, whichever template it's using. The same applies to "under review" in a status-based roadmap and to "considering" in the minimal version.
What's the difference between this page and the roadmap examples post?
This page is the templates: fields, structure, and who each one suits, ready to copy. The public roadmap examples post is the argument for which structure to actually pick, with worked examples of each one succeeding and failing in practice.