Roadmapping

A roadmap on one screen — finished

Most people who look up roadmapping want to see a roadmap that survives a meeting with stakeholders. Here is one: the customer team’s roadmap for the online shop used across the Decomposition, Release Process and Product Discovery pages, as reviewed on Monday 19 October 2026. This is the team’s own version; the section on readers shows what the other two get. Later sections cite the lines by number.

1. 1.What it serves

   1. 1.1Buying again feels effortless: week-2 return visits from 18% to 25% — key result 1.1 on the OKROKRObjectives and Key Results — a goal with measured resultsA goal-setting method that pairs one qualitative objective with two to five measurable key results proving it was reached, set and reviewed every quarter. It stops working when the key results become a task list or the scores feed into pay.Full article →All terms page, aspirational
   2. 1.2Paying never lets a customer down: payment success at or above 97.5% in every week — committed key result 2.1 on the OKR page
   3. 1.3Under the company’s strategy for the year: grow revenue from returning customers rather than buy new ones

2. 2.Now — being built or released; the solution is known

   1. 2.1Reorder from order history — feature 1 of the reorder epicepica large backlog itemA large piece of work that is split into features or stories before anyone builds it, best written as a bet with a hypothesis and a condition that closes it. Its size depends on whose vocabulary is in use — anything above a story in Jira, a portfolio investment with a business case in SAFe — so check before comparing two epics.Full article →All terms; customers see it in stages from 26 October to 16 November, by the release plan
   2. 2.2Automatic retry and refund when the payment provider times out — serves 1.2; built behind a flag, released after the freeze in 5.1

3. 3.Next — the problem and the outcome are chosen; the solution is still being tested

   1. 3.1Saved baskets — feature 2 of the epic, from January; discovery left it as the runner-up for “finding each one again takes ages”
   2. 3.2“I only remember to order when something has run out” — reminders, feature 3, built only if the leading indicators of 2.1 move
   3. 3.3“The payment failed and I don’t know whether I was charged” — what a customer sees after a timeout, once 2.2 has stopped the double charges; serves 1.2

4. 4.Later — a direction; no solution and no date

   1. 4.1Customers who buy the same basket every few weeks never have to start an order — subscriptions, parked by discovery as solution D
   2. 4.2Returning customers get help choosing, not only repeating — named on the epic as a bet of its own

5. 5.Dates the team defends — few, and each made after discovery

   1. 5.1Peak-season change freeze, 19 November to 1 December — the company’s date, not the team’s; nothing new reaches customers inside it
   2. 5.2Gift cards for a partner’s campaign, live on 1 March 2027 — asked for on 21 September, committed on 9 October after a two-week spike, written into the partner contract
   3. 5.3The zip field leaves the order library no earlier than 15 March 2027 — a floor owed to four other teams, not a promise to remove it then

6. 6.Asked for, and not on it — each refused against an outcome

   1. 6.1One-tap buy — dropped in discovery, because the law on order buttons rules it out
   2. 6.2Loyalty points, asked for by sales — no opportunity above it in the tree, and it would move spend per order, not 1.1
   3. 6.3A list of features with dates for the board pack — replaced by 7.2

7. 7.Who sees which version, and how it changes

   1. 7.1The team: this version, every Monday, with the tests running under each Next item
   2. 7.2StakeholdersStakeholderanyone the outcome affectsAnyone whose work or results are affected by what is being built, whether or not they can decide anything about it. The distinction that matters in practice is between those who are consulted and those who can say no.All terms: every group, with Next as problems only, in a fifteen-minute review on the first Thursday of each month
   3. 7.3Customers: three themes on the help centre — no dates, nothing from Next
   4. 7.4Reviewed every quarter against the OKRs; the next review is on Tuesday 12 January 2027
   5. 7.5An item moves from Next to Now only when its outcome has a number and its solution has survived a test

What a roadmap is — and the two ways a dated one goes wrong

Bruce McCarthy and his co-authors define a roadmap in “Product Roadmaps Relaunched” (2017) as a statement of intent and direction. Their primary components map straight onto the hook. The product vision and the business objectives are group 1. The timeframes are the three broad horizons rather than months. The themes are the problems in groups 3 and 4. And the disclaimer is line 7.4: the document says out loud that it will change.

A roadmap is easiest to understand by what it is not. Each neighbouring document answers a different question, on a different horizon, and most roadmap arguments are one of them being asked to do another’s job.

Two independent ways a dated feature roadmap is wrong

The familiar roadmap is a grid: features down the side, months across the top, coloured bars in between. Everyone can read it, which is why it survives. It is also wrong in two ways at once. The first is the obvious one. The dates are estimates made before the work is understood, so they slip, and slipping dates erode trust faster than having no dates at all.

The second matters more. Marty Cagan put it bluntly in 2013: “at least half of our ideas are just not going to work”, and “even with the ideas that do prove to be valuable, usable and feasible, it typically takes several iterations” before they deliver the expected business value. The experiment figures on the Product Discovery page are harsher still. So even if every date held, a dated feature roadmap would be a promise to deliver a particular set of guesses, on time.

That is why the argument between product and stakeholders so often goes in circles. Both sides are right: the stakeholder genuinely needs to plan around something, and the team genuinely cannot promise features it has not tested. Cagan’s alternative, set out in September 2015, changes what is promised. Each team gets a product vision and business objectives — in practice its OKRs — and is judged on whether the numbers move. The few things that really need a date get what he calls a high-integrity commitment, and group 5 is the shop’s list of them.

Now, Next, Later — horizons of confidence instead of dates

Janna Bastow and Simon Cast created the Now-Next-Later roadmap in 2012, while building ProdPad, after years of watching timeline roadmaps create expectations nobody met. The three columns replace months with confidence. ProdPad’s own definitions are worth keeping exact. Now holds “validated Initiatives the team is actively working on, where the problem is well understood and the focus has shifted to the solution”. In Next, “discovery narrows the options, and solution exploration begins”. Later holds “strategic problem areas the team cares about but has not yet shaped into something workable”.

The narrowing is the whole idea. Line 2.1 is committed and specific because the work is understood and the release plan exists. Line 3.2 names a problem in the customer’s words and an outcome, but not a solution, because reminders are still a bet on the leading indicators. Line 4.1 is a direction, with no date and no promise, revisited every quarter as evidence arrives.

One rule keeps the format honest under pressure, and it is line 7.5: an item moves from Next to Now only when its outcome has a number and its solution has survived a test. Saved baskets, line 3.1, will cross in January because discovery tested it and the epic numbers its outcome. Without that gate, Now fills with what was urgent rather than what was ready, and the three columns become a queue with nicer headings.

Three readers, three versions

One file cannot serve everyone who asks for a roadmap, and the attempt is why so many are at once too vague to plan with and too specific to be true. The three readers want different things and tolerate different amounts of uncertainty. Group 7 gives each its own version, cut from the same source, so the versions can never disagree with each other.

The stakeholder version is the one most teams get wrong, and usually by leaving group 6 out. A head of sales who asked for loyalty points and finds them absent without explanation assumes the request was lost and asks again, louder. Seeing it listed with its reason — no opportunity above it, and it moves the wrong number — ends the conversation or moves it to the right level, which is the strategy line in 1.3.

The public version

The customer-facing version is where discipline pays most. Anything published outside will be read as a commitment, whatever the disclaimer next to it says, and a sales team will quote it. GitHub publishes its roadmap as a public repository, arranged by quarter and by release phase, and its README is explicit that the roadmap “does not represent a commitment, guarantee, obligation or promise to deliver any product or feature, or to deliver any product and feature by any particular date”. A company with GitHub’s lawyers still needs that sentence, which says everything about how a public roadmap is read.

Hence line 7.3: three themes, no dates, nothing from Next. Publish fewer items than you are working on, never publish a date you have not decided to defend, and expect to be asked about the item you removed. Both public promises later on this page cost far more to withdraw than they would have cost never to make.

Ordering — four models, four opinions about “first”

The format does not answer the question everyone actually argues about: which of these goes first. Four models cover almost every such conversation. Each is a different opinion about what “first” means — most value per unit of effort, most money lost by waiting, what customers will not forgive, or what the project dies without.

Kano’s categories are worth naming one by one, because each predicts a different mistake. A must-be feature earns no praise when it works and loses the customer when it does not — knowing whether you were charged after a failed payment is one. A one-dimensional feature pleases in proportion: the faster reordering is, the better. An attractive feature delights when present and is not missed when absent, which is why subscriptions can wait in Later. An indifferent one changes nothing either way, and a reverse one annoys some customers by existing. MoSCoW’s test for a Must is the bluntest of all: ask what happens if the requirement is not met, and only if the answer is “cancel the project” is it a Must.

Six candidates, scored two ways

Here are six items the shop’s team was asked to order in September, scored with both models. Reach is in returning customers a quarter, from about 15,000. The cost-of-delay parts are relative scores on SAFeSAFeScaled Agile Framework — a framework for running many agile teams as oneThe Scaled Agile Framework: roles, events and practices for coordinating dozens of agile teams, built around the Agile Release Train — five to twelve teams that plan together every eight to twelve weeks. It is the most prescriptive and the most widely adopted scaling framework, which is also why it can be installed without changing who makes the decisions.Full article →All terms’s scale. Every input is a guess the team argued about, and that argument is the useful output.

Read the disagreements, not the rankings. Gift cards fall from second to last when the model forgets time, because RICE has no column for a contract date — the time-criticality score of 20 is the whole reason they are in group 5. Reminders come second on RICE, and the epic still says not to build them until the leading indicators move: a score does not know about dependencies. Intercom’s own post says as much: “RICE scores shouldn’t be used as a hard and fast rule.” The one item both models agree on, the status after a failed payment, is also Kano’s must-be. When three opinions about “first” agree, you can stop arguing.

The other half of ordering is declining, and it has its own technique. A request refused on capacity — “we have no time” — invites the requester to find you more capacity, which they often can. A request refused against the outcome — “loyalty points would move spend per order, and the quarter is about return visits; if that is the wrong goal, that is the conversation to have” — moves the discussion to the level where it can actually be settled. Every line of group 6 is written that way.

Dates — few, made after discovery, and defended

Refusing all dates is its own failure. Some dates are real: a contract, a regulatory deadline, a launch event, a partner going live. Cagan’s answer, in his 2015 essay and his books after it, is the high-integrity commitment — made deliberately, for a small number of things, after enough discovery to know the shape of the work. In his words: “We do this for those situations where we need to actually commit to a date or a specific deliverable.”

The order of events matters as much as the count. Line 5.2 shows it. The partner asked for gift cards on 21 September. The honest answer that day was not a date but a date for the date: “you will have one by 9 October”. The team spent two weeks on a spike — the payment provider’s gift-card APIAPIApplication Programming Interface — contract between programsThe rules one program follows to call another: which requests it may send, in what shape, and what comes back. To the caller it is a contract — everything behind it stays a black box, which is exactly what lets the other side be rewritten without breaking you.Full article →All terms, the accounting treatment, the fraud rules — split the work into stories and forecast it from its own throughput. Only then did it commit, to 1 March, with a margin past the forecast’s 85th percentile.

Basecamp went further and turned the estimate around. In “Shape Up” (2019) Ryan Singer replaces the estimate with an appetite — “the amount of time we want to spend on a project, as opposed to an estimate” — and sums it up as “Estimates start with a design and end with a number. Appetites start with a number and end with a design.” Work is bet on in six-week cycles, and the circuit breaker keeps the date honest: “If they don’t finish, by default the project doesn’t get an extension.” Scope gives way; the date does not. That is what makes a fixed date compatible with not knowing the work in advance.

The practical rule follows. A team should hold very few such commitments at once, and treat each as a real promise rather than a line on a chart. The shop’s team has three, and one of them, 5.1, is not even its own. A roadmap where every item has a date has no high-integrity commitments at all — it has thirty low-integrity ones, and nobody can tell which of them the company will actually be judged on.

Two public promises, and two teams that changed the format

The first two cases are public dates made before the hardest part of the work was known. The other two are teams that changed what they publish and promise. Each is mapped to the line of the hook that answers it.

AirPower — a public year before the feasibility answer

On 12 September 2017 Apple’s press release for the iPhone X gave a “sneak peek of AirPower, an Apple-designed wireless charging accessory coming in 2018”, able to charge an iPhone, an Apple Watch and AirPods at once, anywhere on the mat. 2018 passed without it. On 29 March 2019 Dan Riccio, Apple’s head of hardware engineering, said: “After much effort, we’ve concluded AirPower will not achieve our high standards and we have cancelled the project.” Apple never said publicly what failed. That is the point: the year was published while the risk Product Discovery calls feasibility was still open, and Apple — not a company short of engineering — spent eighteen months of headlines learning it.

Cyberpunk 2077 — a date defended by keeping the scope

On 9 June 2019 CD PROJEKT announced that Cyberpunk 2077 would release on 16 April 2020 for PC, PlayStation 4 and Xbox One. Its own regulatory filings record what followed: postponed to 17 September 2020 on 16 January, “to test, bugfix and polish the game”; to 19 November on 18 June, with the company stressing that this did “not affect the game’s finalized content”; and to 10 December on 27 October. By release, preorders were over 8 million. The game shipped on 10 December, and the version for the old consoles reached reviewers, in the company’s words, “just one day before the release”.

Four days after release the board said it plainly to investors: “After 3 delays, we as the Management Board were too focused on releasing the game. We underestimated the scale and complexity of the issues, we ignored the signals about the need for additional time to refine the game on the base last-gen consoles.” On 18 December Sony removed the game from PlayStation Store, after discussing full refunds with the company. Each delay moved the date and kept the scope: the same consoles and the finished content. The lever that line 5.2 names in advance — what is cut first if the forecast slips — was never pulled.

Basecamp and GitHub — changing what is promised

Basecamp’s answer, written up as “Shape Up” in 2019, removes the long list entirely. There are “no backlogs”: before each six-week cycle a betting table chooses among a few shaped pitches, and anything not chosen is simply not carried forward. The date is fixed by the cycle and the scope flexes to fit it, so the company never owes anyone a feature list. GitHub does the opposite in public — it publishes a roadmap by quarter and release phase — and protects itself with the disclaimer quoted in the readers section. Between them they mark the two honest options: promise nothing specific, or publish with every reader told it is not a promise.

Where it degrades — and what a roadmap cannot do

Changing the format alone does not work, and trying it is how most teams learn the second half of the lesson. Stakeholders who asked for features with dates and receive Now/Next/Later will read it as evasion unless something replaces the certainty they lost. What replaces it is rhythm — the monthly review in 7.2 where they see the numbers move. Predictable information beats a predicted date, but only if the information actually arrives.

• Now/Next/Later with a date quietly added to every item — the old roadmap in new columns.
• Later used as a graveyard for requests nobody wants to decline out loud.
• Next with no test running under it, so items wait there rather than get decided.
• One roadmap sent to customers, stakeholders and the team, so it fits none of them.
• A prioritisation score treated as a decision rather than as a prompt for the argument.
• A date given on the day it was asked for, before anyone looked at the work.
• Refusals made on capacity, so the same request comes back with more people attached.
• Never revisited, so the roadmap describes what was believed two quarters ago.
• Outcomes with no measurement behind them, which makes them features with better wording.

When to use it

Related pages

• ManagementProduct DiscoveryProduct discovery is the continuous work of deciding what is worth building, by testing ideas with real customers before engineering time is spent on them. It is not a phase before delivery and not requirements gathering: a team talks to customers every week and maps what it hears as opportunities, so solutions compete rather than arrive decided. The page opens with one finished quarter of discovery, then covers discovery beside delivery, the opportunity solution tree, interviews, the four risks and assumption mapping, tests from cheapest to dearest, five products and the test that would have been cheaper, and where the practice degrades.
• ManagementMetrics & KPIA metric is a number with a written definition that a team steers by, and a KPI is one of the few metrics a team or a company has agreed to be judged on. The craft is building a chain from something the team can move this week to something the business needs this year, keeping every number honest under pressure, and reading it without fooling yourself. The page opens with one team’s finished set of metrics, then covers the words and the chain, writing a definition, Goodhart’s law and guardrails, one number at the top and the tree beneath it, reading a number, four numbers that misled their owners, and where it degrades.
• ManagementRelease PlanningRelease planning is deciding what reaches users, when, and how you will know if it went wrong. Its most useful move is to stop treating deployment and release as one event: code reaches production switched off, and exposure becomes a separate, reversible decision taken in stages. The page opens with a finished plan for one release, then covers deploy versus release, a fixed date against a fixed scope, rollout strategies, the four kinds of feature flag, the way back, four releases that failed and the line each one lacked, and how to measure the process.