A roadmap is not a plan. It's a conversation, a shared view that a group uses to make decisions together. Done well it shifts how stakeholders see your role. Done badly it becomes a Gantt chart everyone lies about.
You'll be able to:
- Tell which of three artefacts a stakeholder is actually asking for
- Lay out a Now / Next / Later that's honest about certainty
- Produce four audience cuts from a single source of truth
~15 min read · 30 min exercise at the end
The principle Before you produce anything, ask "what decision are you trying to make?" The answer tells you which artefact you actually need. People asking for dates want a delivery plan. People asking about priorities want a product roadmap. People asking about direction want strategy.
1 · Three things called "roadmap"
A senior leader asks you on Monday for "the roadmap." You send a Gantt with sprints, story points, and dates. She glances at it and her shoulders drop. A week later she asks again. You realise she never wanted a plan, she wanted to know where you were heading. Same word, different artefact, missed conversation. Multiply that by every stakeholder you have.
Stakeholders use the same word for three different things. When someone asks you for "the roadmap," your first job is figuring out which one they actually want.
| Delivery plan | Product roadmap | Strategy | |
|---|---|---|---|
| Audience | Delivery team, vendor | PM + stakeholders | Leadership |
| Shape | Gantt, tasks, dates | Themes over time | Narrative + priorities |
| Horizon | Days / weeks · committed | Quarters · directional | Multi-year |
| Answers | "When will X be done?" | "What are we investing in, and why?" | "Why this, not that?" |
| Certainty | High you're on the hook | Medium shaping in progress | Low intent, not plan |
| Update cadence | Weekly | Monthly / quarterly | Annually · major shifts |
The table tells you the differences. The decision tree tells you what to do with them, listen for what the stakeholder is actually asking, then reach for the right artefact.
From stakeholder ask to roadmap artefact One central question, what are they really asking, branches into three answers: dates need a delivery plan, priorities need a product roadmap, direction needs strategy. What are they really asking? "When will X ship?" Delivery plan Weekly · committed "What's coming up?" Product roadmap Monthly · shaping "Why this direction?" Strategy Quarterly · intent
The three-horizon view
Gantt · tasks · dates · acceptance gates. Where SOW commitments live. High certainty, short horizon, real dates.
Themes · Now / Next / Later · outcomes. Where PM thinking lives. Scope adjustable, dates directional.
Narrative · bets · priorities · direction. No dates. Themes and bets. The "why we do anything at all."
Pause and think Picture the last roadmap conversation you sat in. Strip away how it was framed and ask yourself: which of the three artefacts was the stakeholder actually after? Did they get it, or did they get the artefact you were most comfortable producing?
- Producing a delivery plan and calling it strategy. Leadership wanted direction; you handed them dates. They walk out unconvinced you have a vision.
- Producing strategy and calling it a product roadmap. The team wanted to know what to work on this quarter. Themes don't pay the bills.
- Maintaining all three as separate artefacts. They drift, contradict each other, and the moment a stakeholder spots a mismatch your credibility takes a hit.
- Refusing to disambiguate. Producing whatever artefact you assume they want, instead of asking "what decision are you trying to make?" first.
2 · Now / Next / Later: the working model
You've built a roadmap with quarters across the top. Q2, Q3, Q4, Q1. Each cell has a feature in it. Three months in, half the Q3 cells have moved to Q4 and the team is exhausted explaining why. Leadership thinks you're slipping. The roadmap looks like a graveyard of broken promises. The problem isn't the team. It's that the format pretended you knew Q4 with the same certainty you knew next sprint. You didn't. Nobody does.
Now / Next / Later is honest where dated quarters are dishonest. It carries different certainty in each column, and that asymmetry is the point.
This is the spine of a product roadmap. It's deliberately loose on dates because different horizons carry different certainty, and pretending otherwise damages your credibility.
The model at a glance
NOW
- What's in flight
- SOW commitments live here (they ARE fixed, don't pretend otherwise)
- Acceptance criteria are real, dates are real
NEXT
- Solution docs drafted
- Feasibility ballparked
- Scope broadly agreed with stakeholders
LATER
- "We intend to invest in X because Y"
- Specifics deliberately light
- No dates
Here's what the spine looks like populated. Three columns, three certainty levels, no false dates.
Now / Next / Later board, populated Three columns showing Now (committed), Next (shaping), and Later (directional) initiatives for an enterprise data and AI platform program. Q2 · COMMITTED Now SOW commitments in flight Reports migration Phase 1 · 12 reports live Data model v1 Core entities, glossary aligned Security & access Roles operational Q3 · SHAPING Next Solution docs in draft AI PoC Document triage · sol doc in draft Reports phase 2 Operational dashboards Self-service analytics First BU pilot Q4+ · DIRECTIONAL Later Themes and bets, no dates Expand AI-assisted triage If PoC succeeds Reports wave 2 Remaining legacy estate Advanced use cases Scenarios, trend analytics
Worked example. Enterprise Data & AI Platform
Illustrative. Placeholders for real dates and deliverables.
Q2 · committed · SOW in flight
NOW
Reports migration. Phase 1. Core risk reports on new platform. Acceptance: 12 reports live, analyst sign-off. Target: end of sprint 8.
Data model v1 build. Core entities modelled across [X] domains. Acceptance: peer review passed, glossary aligned.
Security & access layer. Roles/permissions operational. Acceptance: role matrix approved by compliance.
Q3 · shaping
NEXT
AI PoC, document triage. Status: solution doc in draft, data governance approval in progress. Blocker: network access provisioning from tech dept.
Reports migration, phase 2. Operational dashboards. Status: scope discussion with the operations team this month.
Analytics self-service, first business unit pilot. Status: pilot user list being agreed.
Q4+ · directional
LATER
- Expand AI-assisted triage based on PoC outcomes (if successful)
- Second wave of reports migration, remaining legacy estate
- Advanced use cases: scenario modelling, trend analytics
- Operational handover model. BAU ownership beyond project
Why this works in your context
- NOW is honest about SOW commitments. You don't pretend they're flexible. They're committed, dated, and acceptance-gated. Project-mode lives here legitimately.
- NEXT is where PM thinking shows up. Shaping, feasibility, stakeholder alignment. Dates are directional. Scope is still adjustable.
- LATER is where strategy connects. No dates. Themes and bets. This is where you keep the big moves visible without overcommitting.
- The boundaries are permeable. When a NEXT item gets fully shaped and committed, it moves to NOW. When a LATER theme matures into a concrete initiative, it appears in NEXT. The roadmap moves. That's the point.
Pause and think Look at your current Now / Next / Later, or the closest thing you have to one. How many items in NOW have been there for more than two months? How many items in LATER have a date attached? Each of those is a signal. Now is silting up, or Later is being pushed into a commitment it can't carry.
- Putting dates in LATER. The whole point of LATER is that you don't know the date yet. The moment you put one in, you've turned a bet into a commitment, and someone will hold you to it.
- Letting NOW silt up. Items added but never removed. If everything is committed, nothing is. The column has no signal left. Pull things out as they ship; don't be sentimental.
- Treating Now / Next / Later as Q1 / Q2 / Q3. They're not quarters. They're certainty bands. NEXT might be three weeks or six months depending on shaping progress.
- Showing the same view to every audience. Now / Next / Later is the spine. The leadership cut, the vendor cut, and the team cut all derive from it. We come back to that in section 3.
3 · Audience views, one initiative, four cuts
You bring the same roadmap deck to three meetings in a row. The steering committee glazes over because it's too detailed. The vendor pushes back because the dates aren't tight enough. The business stakeholders ask three times why their use case isn't on it, it is, but it's labelled in language they don't recognise. One artefact, three failed conversations. The instinct is to make a bigger deck. The fix is the opposite, fewer artefacts, each cut for the audience in the room.
Same underlying work. Four different framings. Each one shows what its audience needs to make a decision, and hides everything else.
One source, four filters
One source, four audience cuts A central master roadmap with arrows fanning out to four audience-specific views: leadership, vendor, tech department, and business stakeholders. Leadership view Outcomes & decisions Vendor view Deliverables & deps Tech department Dependencies they own Business stakeholders What changes for them Master roadmap Single source of truth
The master is one place, usually a Confluence page. Each audience view is derived from it, not maintained separately. When the master changes, every view becomes stale until you regenerate it. That discipline is the whole game. The diagram below shows what each cut actually contains.
We'll use the AI PoC for document triage as the worked example for each view below.
View ALeadership
Framing: outcomes, strategic fit, decisions needed from them.
Why
Establish internal AI capability and governance model ahead of broader rollout. Operational value in reducing triage variance and time.
Expected outcome
- 200-document evaluation at >90% accuracy
- Analyst time savings validated
- Readiness decision for broader rollout
Status
Shaping, solution doc and data governance approvals in train. On track for Q3 start.
Top risks
- Data access timelines (external)
- Stakeholder perception of AI vs analysts (managed)
Decision needed from you
- Steering approval for PoC go-ahead
- Endorsement of data governance approach
No task-level detail. No tech. No Gantt. Outcomes, status, what you need from them.
View BVendor
Framing: deliverables, acceptance criteria, dependencies both ways.
Deliverables this phase
- Agent framework for classification and routing
- Audit log of agent decisions and rationale
- Analyst review UI (accept / override flow)
- Integration with [X] document store
Acceptance criteria
- >90% accuracy on 200-document evaluation set
- UI usability sign-off from 3 analysts
- Audit log captures full decision trail
Our dependencies on you
- Build team onboarded by [date]
- Weekly demo cadence from sprint 2
- Solution doc sign-off by [date]
Your dependencies on us
- Data governance approval for historical documents, target [date]
- Network / infrastructure access provisioning, target [date]
- Analyst availability for UI testing, 5 working days in sprint [N]
Risks, shared log
Problem + mitigation + owner + review date.
Deliverables, acceptance, dependencies. Commitments in both directions. No strategic framing, they don't need it.
View CTech department
Framing: what they need to do, when, and what happens if they don't.
Dependencies owned by you
- Infrastructure provisioning for PoC environment, by [date]
- Network access rules for vendor build team, by [date]
- Approval on data store integration pattern, by [date]
- SSO integration for analyst review UI, by [date]
Impact if slipped
- Infra: each week's delay moves PoC readout by [X]
- Network: blocks vendor's build phase entirely
- Integration pattern: blocks solution doc finalisation
Owners & cadence
[Their named lead] and [you]. Weekly sync on [day], 30 min. Shared tracker: [link].
No drama, no blame. Just visibility. Makes their accountability explicit without being confrontational.
View DBusiness stakeholders
Framing: what changes for them, what doesn't, what you need from them.
Today
Analysts classify and route every document manually. Quality depends on experience. Turnaround time is a frequent complaint.
What we're testing
An AI assistant that reads documents, proposes a classification and route, and shows why it chose that. An analyst always approves before anything happens.
What we need from you
- 3 volunteer analysts for review UI testing (late [month])
- 30 mins for a walkthrough ahead of that
- Honest feedback, especially on whether the AI's rationale is useful
What won't change
- No impact on live case handling during the PoC
- No change to your tools or process this quarter
- No AI decisions without your approval, ever
When
Testing phase in [quarter]. Readout and next-steps decision after.
Plain language. Reassurance front and centre. Small, clear ask. No technical detail because they don't need any.
Pause and think Pick one initiative you're working on. In your head, frame it four ways, for leadership, for the vendor, for the tech team you depend on, for the end users. Which framing did you find easiest? Which one came out thin? That thin framing is where you're least connected to that audience right now.
- Showing leadership the vendor view. Acceptance criteria and dependency dates make a steering committee feel like they're being managed, not informed. They want outcomes and decisions.
- Showing the team the leadership view. Outcome bullets don't tell engineers what to build on Monday. Each audience needs the artefact pitched at their decision horizon.
- Maintaining four separate roadmaps. They drift. Within a quarter, your leadership view and your vendor view will say slightly different things, and someone will notice.
- Forgetting the tech-department view. The view nobody asks for is usually the one that protects you most. If lateral teams own dependencies and you haven't given them a roadmap framed in their language, you're carrying their risk silently.
4 · Using these in practice
The artefacts are easy. The discipline of keeping one source of truth, regenerating views from it, and updating on the right cadence is what most teams quietly fail at. None of the failure modes below are dramatic, they're just slow erosion that hollows out the practice over a quarter or two.
One source of truth, multiple views. Maintain ONE underlying roadmap (Confluence is fine). The four views above are filters on that source, not separate documents. When the underlying roadmap changes, the views update from it, you don't edit four things.
Stakeholder asks "what's the roadmap?" First question: "what decision are you trying to make?" Their answer points you to the right view. This single habit will save you hours of rework.
Cadence at a glance
When a stakeholder pushes for dates in NEXT or LATER That's a signal the conversation is actually a delivery-plan conversation, or that they're anxious about something specific. Surface the anxiety, don't invent the date. "Something specific worrying you about the timing?" unlocks more than a fake date ever does.
- Updating views without updating the master. A change requested in a meeting goes into a slide deck and never makes it back to Confluence. Within a month the master is wrong and nobody knows.
- Treating the roadmap as a deliverable, not a living artefact. Big update before the steering meeting, neglected for the next ten weeks. The roadmap should change in small ways every week. That's the signal it's being used.
- Skipping the cadence when nothing has changed. The cadence is the trust signal. A weekly five-minute review where you confirm nothing has changed is more valuable than a bigger update done sporadically.
5 · Take-aways and homework
Five things to remember
- Three artefacts, one word. Delivery plan, product roadmap, strategy. Different audiences, different certainty, different cadence. Ask "what decision are you trying to make?" before producing anything.
- Now / Next / Later is honest where dated quarters are dishonest. Each column carries different certainty, and that asymmetry is the point.
- Move items between columns as reality changes. A roadmap that never moves has stopped being honest. NOW silting up and dates creeping into LATER are the two warning signs.
- One source, four cuts. Maintain one master. Generate audience views from it. Never edit four separate roadmaps in four separate tools.
- Cadence is the trust signal. Small weekly updates beat big quarterly reveals. The discipline of regular maintenance is what makes the practice durable.
Homework
Three exercises, building on each other. Don't do them all at once.
Today (15 min)
Pick one stakeholder you've recently been asked for "the roadmap" by. In one sentence, name which of the three artefacts they were actually asking for, and whether you produced the right one. If not, what did you produce instead, and why?
This week (30–45 min)
Draft a Now / Next / Later for one of your real initiatives. Use the populated example earlier in this page as a shape reference. Mark anything you're unsure about, those marks are the conversation you need to have with shaping next.
This month (90 min, split across two sittings)
Take that same initiative. Draft two of the four audience views, pick the two audiences you find hardest to communicate with right now. Show one to a peer (not the audience themselves) for feedback before you take it anywhere live. The peer review is the practice.
What to read next
If you haven't already, the Becoming a Product Manager Q&A is the foundation this toolkit sits on, agile hierarchy, role distinctions, the solution document, and the expectation-management playbook that a roadmap alone can't solve. The Stakeholder Management page gives you the human map that determines which audience views you'll need first.
That's the work.