The short version
- Seven roadmap shapes, and what each one commits you to.
- A roadmap shows three things at once, and they're separable.
- The dated timeline is the one nobody should publish, and this says why.
- Pick the shape you would still be willing to publish after a bad quarter.
A roadmap's shape is a promise. Choose the shape and you've chosen what you'll be held to, which is why the interesting question about any example isn't whether it looks good but what it commits you to when the quarter goes badly.
Six shapes below, each with a worked example written for this post, each followed by the promise it makes and the way it fails. The sixth is the one nobody should publish.
What is a software roadmap example actually showing you?
Three things at once, and they're separable. What's coming, in what order, and by when. Every shape below picks a different subset of those and is honest or dishonest according to whether it claims the ones it can't keep.
There's a working roadmap to look at, not a picture of one, and the demo is open without an account.
Picking the tool this lives in? Eight roadmap tools, sorted by who is allowed to look. On one of them every viewer needs a paid seat.
The six shapes
| Shape | What it shows | What it promises | How it fails |
|---|---|---|---|
| Now, next, later | Order only | That the order is real | Later becomes a graveyard nobody revisits |
| By status column | Where each item has got to | That items move | Items sit in one column for months and the page looks alive when it is not |
| Themed | What kinds of problem are being worked on | That a theme is being pursued | A theme is broad enough that nothing in particular has to ship |
| Outcome based | What will be different afterwards | That you are measuring the outcome | Nobody measures it, and the roadmap becomes aspiration |
| Release train | What is in each named release | That releases happen on a cadence | One slipped release breaks every promise after it |
| Dated timeline | What ships on what date | Dates | Always |
Now, next, later
Now · Bulk CSV import · Webhook events on status change Next · Single sign on · API rate limit controls Later · Native mobile app · Audit log export
The shape with the best ratio of usefulness to risk. It answers the only question most readers actually have, which is whether their thing is close.
Its failure is Later. Left alone, Later accumulates everything you didn't want to say no to, and within a year it's a list nobody believes. The fix is to treat Later as a queue with a length limit, not a bucket, and to move things off it in both directions.
By status column
Suggested 24 · In Review 12 · Planned 8 · In Progress 4 · Shipped 31
A board, not a document, and the shape most public roadmaps actually use.
Its promise is movement, which is also its exposure. A reader who visits twice can tell whether anything changed. That's uncomfortable and it's exactly what makes it credible. A status board that's kept current is worth more than any prettier artefact, because the reader can verify it themselves.
Its failure is a column that never empties. If In Progress holds the same four items for a quarter, the board is telling the truth and that truth is unflattering, which is the moment most teams quietly stop updating it.
Themed
This quarter we are working on imports and migration. Bringing a board over from another tool, in one step, without losing votes or dates.
Useful for saying what you're not doing. A theme lets you decline six requests with one sentence, and that's a real thing a roadmap should do.
Its failure is that a theme is satisfied by almost anything. At the end of the quarter you've worked on imports, which was the promise, and nobody can say whether the thing they wanted arrived.
Outcome based
The outcome. A new team can import an existing board and have it live in under ten minutes. Today. About forty minutes, most of it typing in votes by hand.
The best shape when it's honest, because it states the current number. An outcome roadmap with no current number is a wish list with a different font.
Its failure is that outcomes are slower than features, so the page barely changes for months and readers stop checking it. It works best as a layer above one of the other shapes rather than as the whole thing.
Release train
2.4, dark mode and API pagination 2.5, single sign on and an audit log 2.6, a mobile app
Good when you genuinely ship on a cadence and read as competence when you do.
Its failure is cascading. One slipped release moves everything after it, and because the reader saw a numbered sequence they experience it as three broken promises, not one.
The dated timeline, and why nobody should publish it
March · Bulk import April · Single sign on May · Mobile app
This is the shape that gets asked for and it's the one to refuse.
A date on a public roadmap is a commitment made before the work is understood, by somebody who won't be doing it, to an audience that will remember. Software estimates are wrong in one direction, and a public date converts each ordinary slip into a visible failure.
The honest substitute for a date is order plus a state. Now, next, later says what a date says that's actually true, which is roughly where you're in the queue, and it says nothing that's not.
If a date is genuinely required, it belongs in a contract with one customer, not on a page the internet can read.
Where do architecture and application roadmaps fit?
No, and the difference is the reader, not the drawing.
An architecture roadmap plans the systems underneath a product. Which services get split, which database moves, which dependency is retired and in what order.
An application roadmap is the same kind of document one level up, covering the applications a company runs, not the features inside one of them. Both are read by engineers and both are full of names no customer has heard of.
A digital roadmap is further out again. It's a company's plan for the systems and processes it means to move, replace or connect over the next few years, and the products inside it are line items, not the subject.
Somebody searching for a digital roadmap example wants a transformation plan, not a feature list.
The six shapes above are for a document somebody outside your company opens. That's why none of them carries a dependency, an owner or a system name.
You can draw an architecture plan in the now, next and later shape and it will work, and what you can't do is publish it and expect a customer to get anything from it.
How do you pick a shape?
Ask what you'll do when the quarter goes badly, then pick the shape you would still be willing to publish.
| If you | Use |
|---|---|
| Ship continuously and want to show it | By status column |
| Want to decline requests with one sentence | Themed |
| Have a real cadence | Release train |
| Want the least exposure with the most usefulness | Now, next, later |
| Are being pushed for dates | Order plus a state, and say why |
How do you do this without a tool?
A page with three headings called Now, Next and Later, edited when something moves. That's a real roadmap and it's better than most.
What it can't do is let readers tell you that the order is wrong. A published roadmap is one way traffic, so the ordering stays your guess about what people want.
How does this product do it?
The board is the status column shape by default, with five columns, being Suggested, Denied, In Review, In Progress and Completed. Each card carries a vote count, an effort estimate and a percentage of progress, and cards can be tied to a named release.
The part a document can't do is the other direction. Readers vote on what's in Suggested, so the order in the columns is informed by the people waiting, not only by the people building. The public roadmap page covers the board itself, and what a software roadmap is covers what belongs on one.
What a roadmap should include covers the items themselves rather than the shape.
14 days, a card at signup, then $9 or $39 a month.