DIGNALEGI

Worth reading. A personal index selected by Ratipcan Uysal.

Digna Legi guide / Product roadmaps

Build a Product Roadmap Around Decisions, Not Predictions

Build a product roadmap that separates uncertain decisions from real delivery commitments, without hiding dependencies or inventing precise dates.

By Ratipcan Uysal11 min read

Several torn paper routes carrying uncertain choices pass through a yellow mechanical decision gate and become one marked commitment route.

A roadmap review often begins with a reasonable request: when will this ship?

The product team responds with a date. Sales treats it as a promise. Marketing plans a launch. Engineering discovers that the work contains decisions nobody has made. The date moves, and the next review is spent explaining why.

Removing every date does not solve the problem. Other teams still need to coordinate hiring, campaigns, contracts, migrations, support, and risk. A roadmap made only of themes can be honest about uncertainty while being useless to everyone outside product development.

The mistake is asking one artefact to perform two incompatible jobs. A roadmap must show where the product is trying to go and what the organisation still needs to learn. A delivery commitment must tell other people what they can safely plan around.

Keep uncertain decisions on the roadmap. Put dates only on commitments that another party can act on.

The two views should be connected, but they should not be confused. Between them sits a decision gate: the evidence, owner, and choice required before uncertain direction becomes an operational promise.

A roadmap is not a disguised release calendar

The familiar feature-and-date roadmap looks concrete because every row contains a deliverable and a quarter. Its precision is often borrowed from the layout. The further the row sits in the future, the more likely it depends on untested customer assumptions, unresolved design choices, unknown technical constraints, and priorities that may change.

This does not make roadmapping pointless. Research on software product roadmapping found that organisations primarily regarded the roadmap as a tool for strategic decision-making and future direction. The same study, based on nine interviews and a questionnaire covering 34 companies, found that few had an explicit process for creating and maintaining one. The authors also identified weak market, competitor, and technology inputs, plus the effort of regular updating, as practical difficulties. The evidence is descriptive and more than a decade old, so it does not establish one superior format. It does show that the hard part is the decision process behind the picture, not drawing the picture itself. See Suomalainen and colleagues' study.

A later qualitative study gives the roadmap a second job. Six workshops and twelve interviews across three Finnish software companies found that a high-level roadmap served as a communication point between stakeholder groups, while a lower-level release plan communicated near-term milestones and practical development work. The small, geographically bounded sample limits generalisation, but the distinction is useful: strategic direction and delivery coordination require different levels of detail. See Bomström and colleagues' 2023 study.

Treating both views as one document causes predictable distortions. A tentative direction acquires the appearance of a commitment. A real deadline gets lost among speculative dates. A customer problem becomes a preselected feature because a feature is easier to place on a timeline.

A date on an unresolved choice does not reduce uncertainty. It merely distributes the misunderstanding.

The existing Digna Legi guide on building a product strategy argues that commitment should advance only when evidence about the causal mechanism advances. The roadmap has a narrower responsibility. It must expose which decision is next, what would make that decision responsible, and which commitments remain conditional until then.

Preserve the customer problem without freezing the solution

Replacing features with customer problems is a useful first correction. Jared Spool's account of Bruce McCarthy's theme-based roadmaps proposes committing to a customer problem rather than a particular feature. The approach keeps alternative solutions available while the team learns more. Spool also notes the organisational burden: the team needs ongoing customer research, and leaders must resist the recurring demand to name the feature in advance. Read Themes: A Small Change to Product Roadmaps with Large Effects.

The Now-Next-Later format solves a related presentation problem. Janna Bastow describes replacing a dated Gantt-style view with horizons that communicate current confidence and priority without pretending to know the exact delivery week. In her account, work in Now is more defined, while Later contains less certain possibilities. This is an author's operating method, not comparative evidence that the format improves product outcomes. It remains a useful way to show that certainty should decline with distance. See Bastow's explanation of Now-Next-Later.

Both moves can still fail.

“Improve collaboration” is a theme, but it may conceal incompatible beliefs about the customer, the behaviour to change, and the route to value. “Next” is a horizon, but it may become a polite promise if nobody can say what must be learned before the item moves into Now. The visual language changes while the decision logic remains hidden.

A useful roadmap entry therefore needs more than a theme and a horizon. It needs an explicit decision.

Write the decision before the initiative

For each material roadmap item, begin with the choice the organisation expects to make next. The choice should be consequential enough to change allocation, scope, or direction.

“Explore onboarding” is an activity. “Choose whether to redesign self-service onboarding or move the target segment to assisted implementation” is a decision. The second formulation reveals alternatives, the evidence required to distinguish them, and the teams affected by the result.

Use six fields.

Intended change
Name the customer behaviour or operating condition the product should change. Keep the proposed solution separate.
Current evidence
Record what has actually been observed, including contradictory evidence. Do not turn requests, forecasts, and executive preference into customer facts.
Critical uncertainty
Identify the unresolved belief capable of changing the choice. A long risk register obscures the question the roadmap needs to answer.
Next evidence action
Choose the smallest credible action that can reduce that uncertainty. It may be a prototype, a technical spike, a workflow observation, a limited release, or an analysis of comparable work.
Decision gate
State the options, the owner, and the evidence that would support each choice. The gate must be able to stop, narrow, or redirect work, not merely approve continuation.
Coordination constraint
Record any genuine date, dependency, legal requirement, contract, event, or migration window that another party must plan around.

A roadmap item is ready to advance when the next decision is clearer, not when its presentation looks more complete.

Will Larson's argument for roadmap decisions rather than dates supplies a concrete mechanism. In one case, roughly two weeks of implementation sat inside a two-month initiative because a series of ambiguous decisions moved slowly. His passkey example shows how a prototype can make constraints tangible enough to simplify the remaining choices. Larson also preserves the case for dates as an external coordination interface. His examples are experience-based rather than controlled comparisons, and his AI tooling claim will age with the tools. The distinction between internal decision progress and external coordination remains the durable part.

Put uncertainty and commitment in different lanes

The roadmap should show three states of work. These are decision states, not calendar buckets.

Explore
The customer problem or strategic opportunity appears consequential, but the mechanism or feasibility remains uncertain. The team is buying information. The roadmap shows the question, evidence action, and decision gate.
Choose
The problem is supported well enough to compare viable approaches. The team is resolving trade-offs, dependencies, and scope. The roadmap shows the alternatives, the owner, and the constraint that governs the choice.
Commit
The organisation has chosen an approach and exposed enough delivery uncertainty for other teams to coordinate around it. The commitment view shows scope, responsible team, dependency, confidence, and any external date.

An item should not move because a quarter ended. It should move because the evidence and decision state changed.

Keep a separate commitment schedule for work in the third state. That schedule may contain dates, milestones, release windows, and dependencies. It can use engineering forecasts and delivery ranges. It should not carry speculative Explore items simply because an annual planning ritual expects every row to reach December.

The GOV.UK Service Manual offers a useful counterweight to date-free doctrine. It describes roadmaps as adjustable plans that communicate intended value, make overlapping work visible, and help budget or governance groups understand when value is likely to arrive. It also advises clear objectives for each iteration and explicit treatment of fixed deadlines. This is operational guidance rather than causal research, but it captures a genuine obligation: the rest of the organisation cannot coordinate on product uncertainty alone. See Developing a roadmap.

The practical rule is simple:

The decision view explains what remains conditional. The commitment view explains what others may now rely on.

Treat fixed dates as constraints, not proof

Some dates are real before the solution is known. Regulation takes effect. A contract renews. A seasonal window closes. A dependent team needs an interface by a particular point. Pretending those dates are optional is no more honest than pretending an uncertain feature is certain.

When a fixed date exists, make a different variable flexible. Scope can narrow. The delivery mode can become manual. A migration can be staged. A reversible bridge can protect the dependency while the full solution remains open.

Historical information should also change the forecast. In a controlled software-planning experiment, Shmueli, Pliskin, and Fink found that providing reference information about past completion times and shifting participants toward an outside perspective reduced, but did not eliminate, time underestimation, excessive scope, and unnecessary requirements. The experiment used a fixed-schedule software scenario rather than a live product organisation, so it cannot tell a team exactly how to forecast its roadmap. It does support one modest rule: when a date matters, start with comparable completed work instead of relying only on the story told by the current plan. See the outside-view study.

Use these questions when a date enters the roadmap:

  1. Who will make a costly or hard-to-reverse decision based on this date?
  2. Is the date imposed by an external constraint, derived from comparable delivery history, or chosen for presentation?
  3. Which scope or operating variable will change if the date cannot?
  4. What new evidence would cause the organisation to revise the commitment now rather than miss it later?

If nobody can name a dependent decision, the date may be decorative. If the dependency is real, the date belongs in the commitment view and deserves explicit risk treatment.

Convert one roadmap item

Consider a hypothetical B2B product with this roadmap entry:

Q2: Build a Salesforce export.

The row contains a solution and a date. It does not reveal why the feature matters, whether export is the right mechanism, or what the business must coordinate.

A decision-oriented version might read:

Intended change
Account teams can move approved customer records into their CRM without manual re-entry.
Current evidence
Customer conversations report duplicate entry and delayed handoffs. Product telemetry cannot yet show what happens after records leave the product.
Critical uncertainty
A one-way export may not solve the workflow if teams need updates to move back into the product.
Next evidence action
Observe the complete handoff with selected customers, then run a concierge transfer using real workflows and permitted data.
Decision gate
Choose among a native bidirectional integration, an existing integration partner, a narrower export, or no product investment. The product lead owns the choice with engineering and commercial input.
Coordination constraint
If a signed customer migration or partner campaign depends on the result, record that date and the minimum scope it requires. Otherwise, set a review window rather than inventing a release promise.

The resulting roadmap is less visually certain and more operationally precise. It tells discovery what to learn, engineering what constraint may matter, commercial teams what remains unsafe to promise, and leadership which decision would justify further commitment.

Review the roadmap when evidence changes

A monthly or quarterly meeting is a useful housekeeping rhythm. It is a poor reason to leave a contradicted assumption untouched until the next meeting.

Review an item when one of four events occurs:

  • evidence changes the customer problem or expected outcome;
  • a prototype or technical spike removes a major option;
  • a new dependency creates a coordination constraint;
  • comparable delivery history materially changes the forecast.

At the review, make one decision: continue learning, choose an approach, make a commitment, narrow the commitment, or remove the item. Updating colours and moving cards without changing one of those states is administration, not roadmapping.

This approach also changes the conversation with executives. Instead of asking whether an item is “on track” while the item is still undefined, ask whether the next decision is becoming better informed. Once the work enters Commit, “on track” becomes a legitimate delivery question again.

Dates should become more precise as uncertainty is retired, not as pressure for certainty increases.

Our view: publish the decision boundary

A roadmap should not protect product teams from accountability. It should make accountability specific.

Product leadership owns the problem choice, the evidence standard, and the decision gate. Engineering owns credible delivery input once the mechanism and scope are sufficiently defined. Commercial and operational teams own the dependencies they ask the commitment to support. Leadership owns the trade-off when a fixed date, fixed scope, and constrained capacity cannot all survive.

Our judgment is that most software product organisations should maintain a decision roadmap and a linked commitment schedule. The first can use Explore, Choose, and Commit states. The second should contain only work that other people may reasonably plan around. One source of truth should connect them, but one picture should not flatten their different meanings.

The recommendation is strongest when customer behaviour, solution feasibility, or technical scope remains uncertain and reversal is affordable. It is weaker for repetitive delivery with stable requirements and useful historical throughput. It also cannot remove legal, safety, hardware, or contractual dates. In those settings, the method should expose which other variable will absorb the uncertainty.

This is a synthesis and operating recommendation, not an experimentally validated roadmap system. What would change our view? Evidence that separating decision and commitment views reliably slows coordination, creates contradictory plans, or reduces forecast quality without improving the rate at which weak initiatives are narrowed or stopped. In that case, a single integrated artefact with visibly different confidence states would be the better design.

For the next roadmap review, do not redraw the whole portfolio. Choose one disputed item. Remove its feature label long enough to write the intended change, critical uncertainty, next evidence action, decision gate, and genuine coordination constraint. Then decide whether it belongs in Explore, Choose, or Commit.

If the team cannot do that, the item is not late. It is not yet a plan.

For adjacent arguments, use the product strategy guide to test the causal claim, the decision-based roadmap reading for Larson's full case, and the prioritisation reading path when the dispute starts with the customer problem itself.

Sources and further reading