Product roadmaps that don’t become broken promises

A roadmap is supposed to show where a product is heading. Too often it becomes a list of features with dates that sales has already promised to customers, built on estimates made before anyone understood the problem. When the dates slip, trust goes with them.

This guide explains why feature-and-date roadmaps break, and how two alternatives, the now-next-later roadmap and the outcome roadmap, keep direction clear without making promises you cannot keep. It ends with how to handle the situations where a firm date really is needed.

What a roadmap is for

Atlassian describes a product roadmap as a shared source of truth that outlines the vision, direction, priorities and progress of a product over time. It adds that showing why is just as important as showing what.

That second point is where most roadmaps fail. A row that says “Bulk export, Q3” tells the reader nothing about the problem, so nobody can judge whether a different solution would do. It also turns a guess into a commitment.

Why timeline roadmaps break

Marty Cagan of Silicon Valley Product Group sets out the problem in The Alternative to Roadmaps. Typical roadmaps tell the team what to build, often without stating the problem each item is meant to solve. He observes that very often the initial approach does not work out, and argues that shipping a feature is not enough: it must actually work, as measured by its results.

Janna Bastow, co-founder of ProdPad, makes a similar case in her account of the now-next-later roadmap. Timeline roadmaps insist on deadlines, which pushes teams towards output instead of discovery. They go out of date quickly, and missed dates hurt morale and can create a culture of blame.

There is a simpler problem too. Estimates for work six months away are guesses. Putting them on a slide with a date makes them look like facts.

The now-next-later roadmap

Bastow says she and a colleague sketched the first version in 2012, under the labels Current, Near Term and Future, and a customer later suggested the names that stuck. The format has three columns:

• Now: what the team is working on. Clearly defined and broken into small pieces.
• Next: what comes once the current work is done. Less detailed, and may change depending on what the team learns now.
• Later: bigger, vaguer problems worth keeping in view but not yet committed to.

Detail decreases from left to right, which matches how certainty works in real life. Items move left as they get closer and better understood. Nothing has a date unless it truly needs one.

Bastow’s guidance is to fill the columns with problems or initiatives tied to objectives, not with feature names. She puts the relationship neatly: “The roadmap shows the plan. The OKRs carry the commitment.”

Outcome roadmaps

An outcome roadmap goes one step further. Each item is stated as the result the team wants, not the thing it will build. Cagan’s version gives each product team a set of prioritised business objectives, which he prefers to manage as OKRs, and lets the team decide how to meet them. His example is an objective to cut customer onboarding from 30 days to under three hours. The team might meet it with a new feature, a process change or something nobody has thought of yet.

In practice many teams combine the two formats: now-next-later columns, with each card written as an outcome and a measure.

A worked example

An example (illustration only). A UK firm sells scheduling software to home-care agencies. Its old roadmap listed “Mobile app v2 (March)”, “Rota templates (May)” and “Payroll export (July)”. The rewritten version looks like this:

Sales can now tell a prospect, truthfully, that rota building is the team’s next focus, without promising a feature by a date. If discovery shows that copying last week’s rota solves most of the problem, the team can ship that in a fortnight instead of building a template system nobody asked for.

When a date really matters

Some commitments need dates: a contract with a major customer, a regulatory deadline, a trade show. Cagan reserves what he calls high-integrity commitments for the situations where a team really must commit to a date or a deliverable. A sensible rule is to make one only after enough discovery to understand the solution and its cost. Until then, give a range or a decision date (“we will confirm by 15 March”) rather than a delivery date.

Keep the number of dated commitments small and label them clearly on the roadmap, so everyone knows which items are promises and which are intentions.

Common mistakes

• Renaming columns but keeping features. A now-next-later board full of feature names is a timeline roadmap with the dates hidden.
• One roadmap for every audience. Atlassian notes that engineers, executives, sales and customers need different levels of detail. Keep one source and adjust the view.
• Letting it go stale. Atlassian says a roadmap is counter-productive if it is not up to date, and suggests weekly or fortnightly updates.
• Overloading Now. If Now has more items than the team can work on, it is not now.
• Dates from sales, not from the team. Any date shared outside should come from the people doing the work.

When this approach fits

Now-next-later and outcome roadmaps suit product teams with some freedom to choose solutions and a leadership team willing to judge them on results. They are harder to adopt in agency or contract work where the customer has bought a defined scope, or in organisations where budgets are set by project. In those settings, try adding a problem statement and a success measure to each item on the existing roadmap. It is a smaller change, and it starts the same conversation.