Your roadmap is full. Your strategy may be empty.

The product roadmap contains a new dashboard, a customer portal, an AI assistant, integrations, onboarding improvements and a redesign. Each item has an enthusiastic sponsor. Each sponsor can explain why their request matters. The team can explain why it cannot finish all of them. The next planning meeting adds another column.

A roadmap can describe a sensible sequence of investments. It can also become a record of promises made in separate conversations. When too many priorities share the same people, the practical strategy is whatever survives the loudest interruption. The problem deserves a leadership discussion before it deserves another planning tool.

Ask what each item is supposed to change

Take a current roadmap item and complete this sentence: “For this customer or user, we expect this change to improve this situation, and we will look for this evidence.” If the sentence is hard to finish, investigate before treating the item as a settled commitment.

Some work maintains essential infrastructure, meets a contractual obligation or reduces a known risk. Say that clearly. It does not need to disguise itself as an exciting growth opportunity. Other work is a hypothesis about demand. State the uncertainty and what would make the investment worthwhile.

In a hypothetical business application, a reporting dashboard might help managers decide where to intervene. Alternatively, it might be requested because a competitor has one. These are different starting points. The team needs to know which problem deserves testing before it commits to building another collection of charts.

Choose the customer problem leadership can defend

Strategy should explain where the company will place its attention under real constraints. Describe the customer group, the problem, the commercial reason to address it and the capabilities you can bring. Include what you will defer. Those choices make the roadmap's sequence intelligible.

The Scrum Guide describes a Product Goal as a future state that guides planning, with an ordered Product Backlog emerging to support it. You do not need to adopt Scrum to use the underlying discipline: connect the work list to an explicit direction and order the work accordingly.

A company can have several teams and several important responsibilities. The point is not to pretend that everything reduces to one universal metric. The point is to prevent one team from carrying several incompatible first priorities without an agreed way to resolve them.

Separate committed delivery from exploration

A contractual delivery date, a plausible customer experiment and an idea someone mentioned after a conference do not carry the same certainty. Put them in different planning categories. Show what is committed, what is being investigated and what remains a possibility.

For exploration, name the next learning step. It could be a customer conversation, a prototype or a review of support cases. Include a budget or time boundary. A hypothesis does not earn unlimited effort simply by being placed on a slide labelled “innovation.”

For commitments, state the dependencies and the confidence behind the date. If the confidence changes, communicate the evidence early. Removing uncertainty from the presentation cannot remove it from the work. It merely gives the team a more dramatic meeting later.

Make the cost of adding work visible

Suppose, as an illustrative planning example, a team has capacity for about twelve person-weeks of planned work in the next period after allowing for its essential operating load. Three proposed initiatives require an estimated six person-weeks each. Eighteen exceeds twelve before considering interactions or estimation error.

The figures are assumptions, not a precise forecast. They still expose a choice. Leadership can reduce scope, change timing, secure appropriate extra capacity or defer an initiative. Calling all three “critical” does not supply the missing six person-weeks.

Include the opportunity cost in ordinary language: “Starting the integration now delays the onboarding experiment.” Ask which commercial consequence matters more and what evidence supports the answer. Avoid converting uncertain benefits into impressive financial totals simply to win the argument.

Use scores as prompts, not verdicts

Scoring methods can help compare opportunities when their assumptions are visible. Discuss reach, possible impact, confidence, effort and dependencies. A rough estimate should remain visibly rough. If uncertain inputs receive exact decimals, the spreadsheet can develop a confidence that none of its contributors actually possesses.

Keep a short explanation beside each score. What customer evidence supports the opportunity? What remains unknown? What would make it materially harder? An initiative with a lower score may still be necessary because of a commitment or risk outside the scoring model.

After the discussion, name the decision owner and record the reason. The value lies in making an informed choice that others can understand. Re-running a model until it ranks the executive's favourite first is a time-consuming way to avoid saying who decided.

Give sales and support a usable answer

Commercial colleagues need a way to respond to customer requests. If the roadmap is the only mechanism, every important customer may acquire a new feature promise. Create a request path that captures the problem, urgency, affected customers and commercial context before offering a commitment.

In a hypothetical case, a customer asks for an export format. Their real problem may be moving data into a reporting process. A small existing capability or a supported workaround might address the need sooner. It might also be insufficient. Investigate with the customer rather than assuming either answer.

Try: “We understand the problem and will assess it by this date. We have not committed to that implementation yet.” Give the commercial team a credible follow-up they can use. Leaving them with an unexplained “no” increases the chance of promises being made elsewhere.

Hold a review that can change a decision

At a roadmap review, ask what was learned, what changed commercially, what became more expensive and what no longer deserves investment. Review the intended outcomes alongside delivery progress. A completed feature can still need investigation if the expected use never appears.

• Can we explain the customer problem behind every active initiative?
• Which commitments have a genuine deadline or obligation?
• Which assumptions need testing before more work begins?
• What must move if a new request starts?
• Who owns the decision and who needs to hear it?
• What evidence will we revisit at the next review?

Protect enough stability for the team to finish useful work. Responding to evidence does not require changing direction after every anecdote. Agree which changes justify reopening a decision and which belong in the next review.

If your roadmap is already causing delivery congestion, read why busy teams stop finishing. If the missing piece is leadership ownership, read what to define before hiring a Head of Product. I help teams connect product strategy, customer evidence and practical delivery. My AI product leadership work includes choosing useful AI opportunities within that wider business context. Bring the roadmap and the disagreements behind it to a first conversation.

Questions people ask

How many priorities should be on a product roadmap?

There is no universal number. The roadmap should contain a manageable set of commitments that fits the team’s capacity and connects to an explicit product direction. Make the sequence clear and distinguish committed delivery from exploration. If every item is described as first priority, leadership needs to resolve the tradeoffs before the team can plan credibly.

How do I prioritise conflicting stakeholder requests?

Start with the customer problem, commercial context, obligations, expected benefit, uncertainty and effort behind each request. Make the consequences of choosing one visible, including what will move or stop. Use scoring to structure discussion rather than as an automatic verdict. Name a decision owner and communicate the reasoning to the people whose work or promises are affected.

What is the difference between product strategy and a roadmap?

Product strategy explains the customer problems and opportunities the business will pursue, why those choices matter and where it will place its limited attention. A roadmap describes how intended work is sequenced and communicated. A roadmap without that direction can become a list of requests. Revisit both as customer evidence, commitments and business constraints change.