A product roadmap example is only useful once it's filled in. An empty grid tells you nothing about how a real one is supposed to read, so this page skips the grid and writes five, each for a different kind of company, each with its own table and its own way of failing.
The five aren't interchangeable. A roadmap that works for a small team shipping weekly would embarrass a company presenting to an investor, and a roadmap built for an investor would tell a customer nothing they could use. Match the shape to the reader first; everything else is detail.
These are product management roadmap examples, not public ones
Every table below is a product management roadmap example: something a team plans against, not something posted for the world to read. The fifth one is the exception, built for the public page a customer opens, and it's marked as such.
The distinction matters because the two documents answer different questions. One tells a team what order to build in. The other tells a stranger whether the thing they want is coming. Confusing the two produces a page that satisfies nobody.
A SaaS product roadmap example
Picture a company of about ten people, shipping something small most weeks. Quarters mean little to them, because half of what they build wasn't planned three months ago.
| Column | Item | Why | Asked by |
|---|---|---|---|
| Now | Move billing history off the dashboard onto its own page | The dashboard takes four seconds to load once an account has a year of invoices | a batch of long time accounts |
| Now | Let a teammate be removed without deleting their comments | Losing history when someone leaves the company is the top support complaint this month | support inbox, repeatedly |
| Next | Two factor login | A handful of accounts manage money through the product and won't renew without it | three enterprise trials |
| Next | Export the audit log as a file | Compliance teams want to keep a copy outside the product | one prospective customer |
| Later | A calendar view of scheduled changes | Nice to have, nobody has said they need it | a stray suggestion, unweighted |
This shape gets one thing right: it never claims a date it can't keep. Now and Next describe order, not a month, so nothing on the page becomes a broken promise when a small team's plan changes on a Tuesday.
What sinks it is a Later column nobody prunes. Leave the calendar item sitting there for two quarters and the whole column starts to read as a place ideas go to be forgotten rather than a place they wait their turn.
A product roadmap for an app
A product roadmap for an app carries a complication the SaaS table above never has to think about: a release cycle the team doesn't fully control, and two platforms that rarely ship the same thing on the same day.
| Item | Why | iOS | Android |
|---|---|---|---|
| Offline mode for the main list | Half of the support tickets about crashes trace back to a dropped connection, not a bug | submitted for review | shipped |
| Widget for the home screen | Requested in nearly every review that mentions "checking constantly" | in development | in development |
| Dark theme | Cosmetic, low cost, keeps the app looking maintained | shipped | submitted for review |
| Sign in with a work email domain | One large customer's IT department requires it before wider rollout | not started | not started |
The column that saves this table is the split between platforms. Offline mode is live for one group of users and waiting on a reviewer for the other, and saying so plainly stops a reasonable customer from assuming the whole team is stalling.
What would sink it is writing a single status column and picking whichever platform looks better that week. The first customer who owns the other phone and can't find the feature will notice, and they'll be right to distrust the rest of the page.
A sprint roadmap example
A sprint roadmap is the one shaped by a cadence rather than by a theme, and it is the version most engineering teams already keep without calling it a roadmap.
| Item | Why | Sprint | Carried over |
|---|---|---|---|
| Bulk edit on the request list | Every board over two hundred cards asks for it within a month | 14 | no |
| Export the voter list as a file | Blocks two customers from reporting to their own management | 14 | yes, once |
| Second sort order on the public page | Cheap, and it is the first thing people look for after votes | 15 | no |
| Replace the session store | Nothing visible changes, and everything after it is slower until it is done | 15 | yes, twice |
The column that earns its place here is the last one. A carried over count is the only part of a sprint roadmap that tells you something you did not already know, because an item that has moved three times is not an item that is nearly done. It is an item nobody has been able to start, and the honest response is to take it off the board rather than to move it again.
What sinks this shape is showing it to a customer. Sprint numbers are an internal cadence and they mean nothing to somebody waiting, who will read sprint 15 as a date and be wrong. If the same work needs a public face, it belongs in the now, next and later shape instead.
An architecture roadmap example
An architecture roadmap example doesn't list features at all. It lists the systems underneath the product, and the reason behind each line is a cost or a risk the team is carrying, not a request that arrived from a customer.
| Migration | Reason | Depends on | Risk if left alone |
|---|---|---|---|
| Move session storage off the shared cache | The cache is nearing its memory ceiling under current traffic | nothing | a full outage during a traffic spike |
| Split the reporting queries onto a read replica | Slow reports are locking rows that regular usage needs | the cache move, so the two workloads aren't fighting over the same box | the app becoming unusable for everyone during month end reporting |
| Retire the old webhook delivery service | It has no owner left on the team and no tests | the replica split, to free up the engineering time | a silent failure nobody notices until a customer complains |
| Rotate the database encryption key | The current key predates the team's security policy | nothing, can run anytime | a policy violation, not an outage |
What this table gets right is real dependency instead of the borrowed kind. The webhook retirement waits on the replica split because of who's available to do the work, not because a manager ranked it lower.
What would sink it is presenting this exact table to a customer. Nobody outside engineering asked for a read replica, and dressing a cost avoidance exercise up as a feature list is the fastest way to make a technical roadmap sound like an excuse.
A product roadmap for investors
A product roadmap for investors is reporting on a different unit entirely. The row isn't a feature, it's a theme, and the interesting column isn't what the theme builds but what it unlocks for the business.
| Theme | What it unlocks | Roughly when |
|---|---|---|
| Self serve onboarding | A customer can start paying without a sales call, which changes who can reach this product at all | this half |
| Usage based billing | Lets the smallest and largest accounts pay proportionally instead of on one flat tier | next half |
| A partner integration layer | Opens a channel where other companies bring customers in, instead of the team finding every one itself | later this year |
| Data residency options | Removes the one blocker that's kept a specific regulated industry from buying | under evaluation |
What makes this table work for its reader is that every row answers the question an investor is actually asking, which is whether the coming year adds up to a larger business, not whether a particular button ships in March.
What would sink it is including the maintenance work and the bug list, because an investor has no way to weigh a security patch against a new market, and adding it just proves the deck wasn't edited for the room it's shown in.
A roadmap customers see on a public page
The fifth table is the one exception on this page: it's not read by the team, it's read by a customer deciding whether to keep waiting. Grouping it by quarter would tell that customer almost nothing, so it's grouped by the problem it solves instead.
| Problem | What's coming | Status |
|---|---|---|
| It's slow to bring an existing list of ideas into the board | A one step import from a spreadsheet | in progress |
| It's hard to tell who else wants the same thing | Merging duplicate requests so votes stack instead of splitting | planned |
| Notifications arrive for things nobody cares about | Letting each person choose which boards notify them | planned |
| Nothing on the board says why a request was turned down | A visible reason next to anything declined | shipped |
Grouping by problem instead of by quarter is what makes this readable to someone who has never used the product before. A quarter means nothing to a first time visitor; a problem they recognise means everything.
What would sink it is grouping by problem while quietly leaving out the requests that got a flat no. A customer who can't find their own request anywhere on the page learns that the page hides bad news, and stops trusting the good news too.
Application, digital and strategic roadmap examples aren't the features underneath
Application roadmap examples list the products a company runs side by side, not the screens inside any one of them; a company with three internal tools might roadmap which one gets rebuilt this year and which gets frozen.
Digital roadmap examples usually belong to a company whose product isn't software at all, covering the paper process, the phone line or the manual spreadsheet it's replacing with something a customer can use themselves.
Strategic roadmap examples sit a level above both, grouping a year of work under outcomes such as entering a new market or cutting the cost of serving an existing one, with the individual products as line items rather than the subject.
What format fits a product roadmap example, and does it work in Excel?
The right product roadmap format depends on which of the five above you're building, not on personal taste. A team shipping continuously wants the Now, Next, Later shape from the first table. A team reporting up wants the theme shape from the investor table. Mixing the two into one page produces the kind of roadmap nobody can read twice.
Every table on this page is plain rows and columns, so a product roadmap example in Excel is really just the same table pasted into a sheet, with status, votes or effort as extra columns you sort by. Nothing here needs a formula to be useful; the formulas only start to matter once the sheet is doing the counting for you.
If you'd rather start from a file than from this page, the editable versions live here: a spreadsheet with the columns already labelled, a slide deck for the investor and theme shapes, and a one page PDF showing a finished example of both.
What every example above has in common, once it's real
Strip away the illustration and each of the five tables would carry three more things in a working version, none of which made it onto the page above on purpose.
A date the whole thing was last true. Every table here is a snapshot, and a snapshot with no date on it is indistinguishable from one nobody has touched in a year.
A count next to each row, of how many people actually asked, not a guess dressed up as a number. Without it, the order down the page is somebody's opinion, and there's no way for a reader to check it.
A list of what's declined, with the reason written next to each line rather than left blank. A team that can say what it turned down, and why, is showing a plan. A team that only ever says yes is showing a wish list with better formatting.
None of the five examples above needed real numbers to make its point, so none of them carry any; a working version would. What separates a real roadmap from a list that only looks like one goes through that test in full.
14 days, a card at signup, then $9 or $39 a month.