Product Roadmap
The product roadmap is a strategic document showing how a product is likely to grow. It carries themes, each grouping high-level requirements or features, placed on a coarse timescale: either quarters or three columns named now, next and later. It is used to align stakeholders on a direction, to open the discussion on priorities and to secure the delivery budget. The Agile Extension to the BABOK Guide places it at the Strategy horizon. Its reference form comes from Lombardo, McCarthy, Ryan and Connors, who build it on the product's desired outcomes and on bars of varying width.
Goal
The product roadmap is the document where an organisation reads on one page what it wants its product to become, in which order and with what certainty. Each row is a theme, a set of features or requirements serving one desired outcome; each column is a period of time. The Agile Extension gives it the purpose of communicating the direction taken towards the vision for the solution and of measuring progress against that vision through the achievement of the stakeholders' desired outcomes.
Each team keeps its own backlog, management keeps its annual objectives, the sales department promises features in client meetings. Nothing brings these three lists together. The question that comes back in every meeting, "when will we have this feature?", then gets a date invented by whoever answers. The roadmap replaces that date with a position on an axis and a degree of certainty that falls off with distance.
It serves a second decision, one the guide states: securing the delivery budget. A committee that funds a product across several financial years arbitrates on desired outcomes and on their order, material that a list of tickets does not give it. The roadmap is what that arbitration rests on, then the reference against which it is revised; the business case then examines each theme on its own.
The deliverable is the roadmap, kept up to date, together with the register of desired outcomes and their measures. The guide places the technique at the Strategy horizon, the widest of the Agile Extension's three horizons.
Usage
When to use it
- Several teams on one product: a single direction replaces as many plans as there are teams.
- A multi-year budget request: the committee arbitrates on desired outcomes and on their order.
- Vision settled, path still open: the order of the themes is fixed without freezing the solutions.
- Stakeholders who ask for dates: the periods give an answer that holds and can be discussed.
- A product sold to external customers: a public view announces the direction without committing to a release.
- Competing requests from several departments: themes make them comparable on the outcome they aim at.
When not to use it
- A vision reopened at every committee meeting: the document goes stale before it is read; the work to be done bears first on the vision itself.
- A contractual commitment on dates and scope: a schedule and a binding estimate answer the request.
- One team, one product, a three-month horizon: backlog management is enough to hold the order.
Description
Two formats for the same content
A roadmap takes two forms and the Agile Extension uses both without distinguishing them. Its text describes features expressed as "now, next, later"; its figure 7.10.1 sets out a grid of four quarters where each capability occupies one cell, one of them split into three segments spread over the first, the second and the fourth. The choice between these two formats fixes what the reader will be entitled to ask for.
The calendar format divides the axis into quarters or half-years. A committee used to financial years reads it without explanation and it lines up with the funding cycle. The bar of varying width, straddling two columns of the scale, comes from Lombardo, McCarthy, Ryan and Connors, whose Product Roadmaps Relaunched sets the reference form.
The now, next, later format divides the axis into three columns of decreasing certainty. The first is committed and funded, the second is framed without being scheduled, the third is an intention that the next measurement can overturn. No column carries a date and the committee loses its budgetary bearings.
Both formats carry the same content. Going from quarters to the three columns loses nothing; the reverse forces dates to be set. The calendar format is the only one the guide illustrates.
Product roadmap
The same content, in three columns
Now
· committed and funded
Open an account without visiting a branch
- e-ID identification
- Qualified electronic signature
- Carry-over of the existing customer's data
Next
· framed, not scheduled
Pay without leaving the application
(QR-bills and eBill)
Advise online under FinSA
(online risk profile)
Later
· intention
Save without thinking about it
Instant payment between customers
The elements
The vision and the strategy open the document. The vision says what the solution covers and the outcome it aims at; it is the vision the guide charges with clarifying what falls inside the scope. The strategy says by which path the organisation intends to get there. A list of the requests turned down, kept beside the document, names what the organisation is giving up. A partner or a customer looks for that second list as much as for the first.
The desired outcomes are stated for the organisation and for the stakeholders. Lombardo and his co-authors make the measured outcome the backbone of the document: an outcome is written with its measure, its starting point and its target, "share of account openings completed without a branch visit, from 12% to 45%". The measure makes it possible to establish afterwards whether the theme delivered produced what was expected of it. Without it, a theme stays an intention and its progress gets reported as a percentage of code written.
The product management team holds the document. The guide describes it as small, led by the product owner or by a representative of the customers. It gives that team three obligations: reflect current priorities, stay accessible to those who need the document, adapt the view to the audience. This team is the named owner; without that name, revision stops at the second quarter.
The themes are the rows. A theme groups requirements, features or user stories that serve one outcome. Lombardo and his co-authors have it named after that outcome: "open an account without visiting a branch" fits on one line and speaks to a committee.
The high-level requirements fill the themes. Each groups requirements or stories from which the delivery team will draw its backlog. Their granularity falls off with distance: a theme in the committed column is described in three or four named items, a distant theme fits in one sentence.
The SAFe framework distinguishes the program increment roadmap, the product or solution roadmap and the portfolio roadmap, each held by a different body and covering a different span. The product roadmap corresponds to the product or solution level; the portfolio view belongs to Portfolio Kanban, which shows what stage each committed initiative has reached.
How to build one
The order matters: each step takes the output of the previous one as its input. The vision is written first, in one sentence that an outsider can contest. The desired outcomes are then stated, three to six of them, each with its measure, its starting point measured and its target.
The existing requests are then grouped, backlog, support tickets, sales commitments and regulatory obligations, each of them attached to an outcome. A request that attaches to no outcome poses an alternative: either the outcome is missing from the list, or the request falls outside the product. The themes obtained are ordered, by prioritisation or by a weighted vote of the committee, and placed on the chosen axis.
What remains is to fix the revision cadence and the name of the person who holds the document. One revision per quarter, ahead of the budget round, is enough for most products. The roadmap carries its revision date in plain sight, which keeps a copy nine months old from circulating as though it still held.
One roadmap, several views
The guide counts the view by audience among the strengths of the technique: management, the delivery team and external customers read the same document at three levels of detail. The three views are derived from a single source. Maintained in parallel, they diverge within a quarter and the organisation ends up with three directions.
| Audience | Question the view answers | Content | Circulation |
|---|---|---|---|
| Management | What are we committing next year's budget to? | The themes, their desired outcome with its measure, the budget per theme, the quarterly columns. | One dated slide, at each quarterly revision. |
| Delivery team | What are we preparing after the work already committed? | The same themes, broken out into high-level requirements, with the dependencies between teams and the known technical constraints. | The working document, kept up to date continuously. |
| Customers and partners | Is the product going in the direction I need? | The themes and their order, without budget, without internal dependencies and without any deadline beyond the committed column. | A published page, reviewed before each release. |
What makes the technique fail
The quarter read as a date
Committing to distant dates is the first failure mode Lombardo and his co-authors document, and the guide states the same limitation: the technique gets turned into a milestone calendar. A theme placed on the third quarter becomes "delivered in September" in the minutes, then a commitment in a letter to a customer. Two additions to the document limit the drift: a statement of the degree of certainty per column and the date of the last revision. The third corrective is a practice: the first revision that moves a theme from one quarter to another, made in front of the same committee, teaches the reader what a placement is worth.
The vision that changes every month
The guide calls the technique ineffective wherever the vision and the desired outcomes are reopened at every committee meeting. The roadmap is redone there more often than it is read, because the cause sits upstream of the document and no format corrects it.
The detail that makes upkeep impossible
The guide points to the maintenance cost of a roadmap that is too detailed or broken into too many views. A theme fits on one line and reads from three metres away. As soon as a row carries a list of tickets, the content belongs to the backlog and the roadmap has begun to duplicate it. Beyond three views, a product management team of two or three people can no longer keep up.
The theme named after the component
"Migration to the new payment gateway" names an internal piece of work. The committee cannot arbitrate on it, having no outcome to compare it against, and it accepts or refuses it on the reputation of whoever presents it. The same work, named "pay without leaving the application" and given a measure, enters the comparison with the other themes.
AI considerations
A language model serves this technique at volume. On an export of the backlog and of support tickets, it proposes groupings by intent and brings out the candidate themes, work a team otherwise runs in workshops over several half-days; the proposal has to be read back, but it starts from material nobody would have read in full. It spots the themes with no measure, the measures whose starting point is not filled in and the requests attached to no outcome. It compares two successive versions of the roadmap and lists what has moved, which prepares the agenda of the revision. It derives a customer view from a management view out of the same source, removing what must not go out, subject to review.
The order of the themes is not something to ask a model for. It depends on commitments already made, on the balance of power between departments, on a regulatory deadline and on the capacity of the teams, none of which is written in the document submitted. Placing a theme on a column runs into the same limit: a model told to date a theme produces a plausible quarter with no capacity behind it. The targets of the desired outcomes are negotiated with those who will have to meet them. A roadmap carries unannounced market entries, supplier names and budget figures: these are removed before anything goes to a public model.
Examples
The product management team of a cantonal bank holds the roadmap for its mobile banking application, reviewed each quarter by the retail banking division. The format is the calendar format over four quarters.
Product roadmap
Cantonal bank, mobile banking app
Four themes carry four outcomes and the bars do not line up. Account opening advances in two steps over the first two quarters; online advice under FinSA, the Financial Services Act, sits on the second; payment occupies a bar straddling the second and the third, then resumes in the fourth; saving appears only in the fourth, as a pilot. This irregularity is what a roadmap shows: themes come in different sizes and certainty falls off towards the right.
The outcome register is kept beside the roadmap. It is the register the committee reads back at each revision, theme by theme.
| Theme | Desired outcome and measure | Start | Target | Budget |
|---|---|---|---|---|
| Open an account without visiting a branch | Share of account openings carried through online | 12% | 45% | CHF 1'850'000 |
| Pay without leaving the application | Share of QR-bills and eBills paid from the application | 31% | 70% | CHF 940'000 |
| Advise online under FinSA | Risk profiles kept up to date among customers holding a securities account | 54% | 95% | CHF 620'000 |
| Save without thinking about it | Customers with a savings goal funded automatically | 0 | 8'000 | CHF 210'000 |
The starting-point column is the one most often missing. A starting point that has been measured turns the next revision into a verifiable finding.
Visualisations
A roadmap is drawn in rows and columns: one row per theme, headed by its outcome and its measure, one column per quarter. Each bar covers the quarters its theme occupies, one of them able to spill from one quarter into the next. A gradient or a lighter outline on the right-hand columns makes the decreasing certainty visible. The date of the last revision and the name of the team that holds the document appear on the figure itself, since that is what circulates.
The three-column format is drawn as three columns of cards, with no timescale, only the left-hand column carrying detail. The outcome register reads as a table, one row per theme.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | High | Agreement on the vision and on the desired outcomes takes management and the business departments through several sessions. Grouping the existing requests into themes means reading back the backlog and the commitments already made. |
| Execution | Low | A quarterly revision of one to two hours, with participants the budget round brings together in any case. |
| Documentation | Medium | The document is short. The spending goes on reading the measures at each revision and on deriving the views by audience. |
Tooling
The wall remains the tool of the build session: columns marked out in tape, one card per theme, a move possible during the discussion. It assumes a team gathered in one place and produces nothing that circulates.
The collaborative whiteboards (Miro, Mural and their equivalents) fill the same role for a team spread across several sites. They suit circulation poorly, because the occasional reader will not open a boundless board to look for one row.
The spreadsheet and the presentation carry most of the roadmaps in service. They produce a management view readable on one slide, at no cost. Their weakness is the copy: a slide leaves by email, loses its revision date and then circulates on its own account. Locking the revision date into the footer limits the damage.
The product management tools (ProductPlan, Aha!, Roadmunk, Jira Product Discovery and their equivalents) attach the themes to the backlog items and produce several views from a single source, which answers the upkeep limitation. They are paid for per user and ask that the backlog already be clean.
That leaves the tool the measure depends on: the system that produces the indicators, product usage measures or a decision-support dashboard. A desired outcome that nobody knows how to measure each quarter leaves the roadmap with no way of establishing its own effect.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.10 Product Roadmap: the purpose of the technique, the five elements, among them the product management team and the themes, the strengths stated, among them the views by audience, the three limitations and the placement at the Strategy horizon. Figure 7.10.1 gives the calendar format, a grid of four quarters where each capability occupies one cell.
- C. Todd Lombardo, Bruce McCarthy, Evan Ryan, Michael Connors, Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty, O'Reilly Media, 2017: the roadmap as a statement of direction, the format built on desired outcomes and on a timescale, the bar of varying width straddling several columns, the theme named after its outcome, along with the documented failure modes, first among them the commitment to distant dates and features.
- Scaled Agile Framework, Roadmap: the technique declined at several levels, that of the program increment, that of the product or solution and that of the portfolio.