Roadmap Planning & Communication
The CEO, Sarah Chen, sends a message three days before the quarterly business review: "I need the Q3 roadmap. Three things: what engineering is building and when, what I can tell the board, and something I can send to enterprise customers who keep asking what's coming. Can you send me three versions?"
Three audiences. Three purposes. One roadmap — expressed three different ways.
This is the real PM skill in roadmap work: not building the roadmap, but translating it. The engineering team needs sprint-level commitments. The CEO needs commercial outcomes tied to strategy. Enterprise customers need benefit language that helps them plan, not dates that become expectations.
You will use /roadmap-update from the official product-management plugin to build InsightFlow's Q3 roadmap from the L08 story backlog, and then generate the three versions Sarah needs — each calibrated for its audience.
The Four Roadmap Frameworks
Different audiences and planning contexts require different formats. Choosing the wrong one creates the wrong expectations:
| Framework | Format | Best For | Avoid When |
|---|---|---|---|
| Now / Next / Later | Three time buckets with no specific dates | External comms, executive summaries, team alignment | When engineering needs sprint-level scheduling |
| Quarterly Themes | 2-3 strategic themes per quarter, with initiatives underneath | Planning meetings, strategy communication | When the audience needs to see individual features |
| OKR-Aligned | Roadmap items mapped to Objectives and Key Results | OKR organisations, executive accountability | When OKRs are not mature or team does not use them |
| Timeline / Gantt | Calendar view with start/end dates, parallelism visible | Engineering execution planning, resource conflict identification | External communication (creates false precision and date expectations) |
For most communication situations, Now / Next / Later is the right default. It communicates direction without false precision. "Q3" on a customer roadmap is read as a contract; "Next" is read as a direction.
A roadmap that shows exact delivery dates for software features trains stakeholders to treat it as a contract. When a dependency slips — and it will — the PM is now renegotiating a contract rather than updating a plan. Now/Next/Later avoids this by communicating timeframe buckets, not calendar commitments. Use Timeline/Gantt internally for engineering planning; use Now/Next/Later for everything else.
The Now / Next / Later Structure
Each bucket has a specific meaning and level of commitment:
| Bucket | Timeframe | Commitment Level | What It Contains |
|---|---|---|---|
| Now | Current sprint or quarter | High — these are commitments | Work actively in progress or starting this sprint. Specs complete, teams assigned. |
| Next | Following quarter | Medium — intentions, not commitments | Work planned and roughly scoped. Problem statements ready. Not yet fully specified. |
| Later | 3-6+ months | Low — signals, not promises | Strategic themes and opportunities. User problems, not solutions. No dates. |
The critical distinction: Now items have specs. Next items have problem statements. Later items have themes. This structure prevents the backlog-dump roadmap where everything is presented as equally real.
Dependency Mapping
Every roadmap needs an explicit dependency map. Unacknowledged dependencies are the primary cause of roadmap slippage:
| Dependency Type | Description | Example in Workflow Builder |
|---|---|---|
| Technical | Feature B requires infrastructure from Feature A | Trigger Configuration depends on Automation Engine from Platform team |
| Team | Feature requires work from another team | Threshold trigger depends on Data team's evaluation service |
| External | Waiting on vendor, partner, or third-party | Email delivery via SendGrid API availability |
| Knowledge | Need research results before starting | Data team feasibility confirmation on real-time threshold polling |
| Sequential | Must ship Feature A before Feature B can start | Automation Builder UI must ship before users can configure triggers |
For each dependency: name it, assign an owner, and set a "need by" date. Unowned dependencies do not get resolved.
Capacity Planning with the 70/20/10 Rule
Before populating the roadmap, apply the capacity rule:
InsightFlow context: 12 engineers, 2-week sprints, velocity ~40 story points per sprint.
| Allocation | Percentage | Story Points per Sprint | Purpose |
|---|---|---|---|
| Planned features | 70% | ~28 points | Roadmap items that advance strategic goals |
| Technical health | 20% | ~8 points | Tech debt, reliability, performance, DX |
| Unplanned | 10% | ~4 points | Urgent issues, quick wins, other-team requests |
If the Workflow Builder backlog from L08 requires more than 28 story points per sprint averaged across 8 sprints, the roadmap is over-committed. Something must come off, or the capacity allocation changes — but never by pretending engineers can simply do more.
Worked Example: InsightFlow Q3 Roadmap
Run /roadmap-update with the L08 story backlog as input:
/roadmap-update
Create InsightFlow's Q3 roadmap from the Workflow Builder story backlog.
Context:
- InsightFlow: B2B SaaS analytics platform (Series B, 50 employees, 200 customers)
- Engineering team: 12 engineers + 3 designers, 2-week sprints, velocity ~40 pts
- Q3 strategic bet: Workflow Builder — automation layer that lets analysts
automate repetitive data workflows
Story backlog (from L08):
- Story 1: Create a new workflow [S, Sprint 1]
- Story 2: Add and arrange workflow steps [M, Sprint 1-2]
- Story 3: Browse and select an action [S, Sprint 2]
- Story 4: Configure "Send Report" action [S, Sprint 2]
- Story 5: Configure schedule trigger [S, Sprint 2-3]
- Story 6: Configure data threshold trigger [M, Sprint 3]
- Plus: Workflow status view, error state handling (Sprint 4-5)
Dependencies:
- Platform team: Automation engine API (need by Sprint 1 Week 2)
- Data team: Threshold trigger evaluation service (need by Sprint 3)
- Email service: SendGrid integration (need by Sprint 2)
Format: Now/Next/Later
Additional context: Also building SOC 2 compliance work and self-serve
onboarding improvements in Q3 alongside Workflow Builder.
After generating the Now/Next/Later roadmap, produce three versions:
1. Engineering planning view (sprint-level detail)
2. Executive summary (commercial outcomes, aligned to Q3 strategy)
3. Customer-facing update (benefit language, no dates)
Sample roadmap output:
INSIGHTFLOW Q3 ROADMAP
════════════════════════════════════════════════════════════
Format: Now / Next / Later
Updated: 2026-03-18
STRATEGIC BET: "Build InsightFlow's automation layer — from analytics
platform to always-on data intelligence"
── NOW (Q3 Sprints 1-5) ────────────────────────────────────
Theme 1: Workflow Builder — Core Automation (PRIORITY 1)
Automation Builder UI [On Track] Sprint 1-2
Action Library (3 actions) [On Track] Sprint 2
Schedule Trigger Configuration [On Track] Sprint 2-3
Data Threshold Trigger [At Risk] Sprint 3
⚠ Dependency: Data team evaluation service — need by Sprint 3 start
Theme 2: Enterprise Security — SOC 2 Prep (PRIORITY 2)
SOC 2 evidence collection [On Track] Sprint 1-3
Audit log implementation [Not Started] Sprint 4-5
Dependency: Engineering lead security review — need by Sprint 4
Theme 3: Self-Serve Onboarding (PRIORITY 3)
Onboarding flow redesign [In Progress] Sprint 1-4
Note: Stretch goal — cut if Workflow Builder runs over
── NEXT (Q4 Intentions) ────────────────────────────────────
Workflow Builder extensions:
- Workflow sharing (team access)
- Advanced trigger conditions (multi-condition AND/OR)
- Trigger history and audit log
Enterprise features:
- SSO (SAML 2.0 + OIDC)
- Admin provisioning console
── LATER (2027 Signals) ────────────────────────────────────
Platform bets:
- AI-powered workflow recommendations
- External workflow integrations (Salesforce, HubSpot triggers)
- Mobile app (field team use cases)
RISKS AND DEPENDENCIES:
1. Data team threshold trigger service [HIGH RISK]
Owner: Maria Santos (CTO) | Need by: Sprint 3 start
Mitigation: If not ready by Sprint 3 start, defer threshold
trigger to Q4 and ship schedule trigger only in Q3
2. Platform team automation engine [MEDIUM RISK]
Owner: Engineering lead | Need by: Sprint 1 Week 2
Current status: In progress — on track
CAPACITY CHECK (70/20/10):
Feature work: 28pts × 8 sprints = 224 pts planned
Workflow Builder: ~160 pts | SOC 2 prep: ~32 pts | Onboarding: ~32 pts
Tech health budget: 8pts × 8 sprints = 64 pts reserved
Unplanned buffer: 4pts × 8 sprints = 32 pts reserved
Total capacity: 320 pts | Total committed: 224 pts ✓
════════════════════════════════════════════════════════════
The Three Audience Versions
After generating the roadmap, run /roadmap-update again with the audience instruction:
Version 1: Engineering Planning
/roadmap-update
Generate the engineering planning view from the Q3 roadmap.
Include: sprint assignments, dependency owners and need-by dates,
at-risk items with mitigation plans, capacity allocation.
Audience: Engineering team — sprint planning meeting.
The engineering view includes sprint numbers, dependency names, and explicit at-risk flags. Engineers need to know who owns what and when.
Version 2: Executive Summary (QBR)
/roadmap-update
Generate the executive summary from the Q3 roadmap.
Translate technical items into commercial outcomes.
Include: Q3 strategic bet, expected business outcomes,
what is NOT being built and why.
Audience: CEO Sarah Chen and CPO David Park — quarterly business review.
Max length: one page.
The executive view drops sprint numbers and dependency details. It leads with the strategic bet, explains the commercial case, and tells Sarah what she can say to the board: not "we are building trigger configuration" but "Analyst Alex's Monday morning report will run automatically without her logging in."
Version 3: Customer-Facing Update
/roadmap-update
Generate a customer-facing product update from the Q3 roadmap.
Use benefit language — what customers will be able to do, not what
we are building. Avoid dates and sprint references. Use 'coming soon'
and 'planned' language, not 'committed' or 'Q3'.
Audience: Enterprise customers and prospects.
The customer version uses benefit language, avoids dates, and framing around what customers will be able to do rather than what the team is building. "Workflow automation" becomes "your Monday morning report, running automatically."
Communicating Roadmap Changes
When the roadmap changes — and it will — the communication matters as much as the update. Use the five-step framework:
- Acknowledge the change — Be direct. "We are changing the Q3 roadmap."
- Explain the reason — What new information drove this? "The data team confirmed that the threshold trigger service cannot be ready until Q4."
- Show the tradeoff — What moves to make room? "Threshold triggers move to Q4 Next. Schedule triggers ship as planned."
- Show the new plan — Updated roadmap with changes reflected.
- Acknowledge impact — Who expected the deprioritised item? "Enterprise customers who asked about data threshold alerts will need a direct conversation from Aisha (Head of Sales)."
Lessons 3-14 build one continuous product management cycle for InsightFlow. Keep your Cowork session and working folder between lessons. The Q3 roadmap you build in this exercise is the roadmap whose items L10 will prioritise — the prioritisation order you produce in L10 will determine what enters the first sprint.
Try With AI
Use these prompts in Cowork or your preferred AI assistant.
Prompt 1 — Reproduce (apply what you just learned):
Build a Now/Next/Later roadmap for InsightFlow's Q3 with this context:
NOW:
- Workflow Builder core (automation builder + 3 actions + schedule trigger)
- SOC 2 evidence collection
NEXT:
- Workflow Builder extensions (threshold trigger, workflow sharing)
- SSO (SAML 2.0)
LATER:
- AI-powered workflow recommendations
- Mobile app
Format as a Now/Next/Later table with a brief status for each item.
Include a dependencies section — the platform team automation engine
must deliver by Sprint 1 Week 2 (owner: engineering lead).
What you're learning: Building a roadmap from a story list — the translation from backlog to roadmap structure. Notice how the roadmap collapses individual stories into initiative-level items. The customer does not need to know about "Story 1: Create a new workflow" — they need to know about "Workflow automation arrives in Q3."
Prompt 2 — Adapt (change the context):
A PM at a legal tech SaaS needs to communicate a roadmap change to
three audiences:
The change: The AI Contract Summary feature (highest-priority Q3 item)
is delayed by 6 weeks because the legal review team needed to build
a validation layer before the AI model can be production-ready.
Original delivery: End of Q3
New delivery: Start of Q4
Apply the five-step change communication framework:
1. Acknowledge the change
2. Explain the reason (what new information drove this)
3. Show the tradeoff (what changes in the plan)
4. Show the new plan (updated timeline)
5. Acknowledge impact (who was expecting this — and who needs a
direct conversation)
Write version for: (a) engineering team, (b) CEO, (c) enterprise
prospects who were told AI Contract Summary was "coming Q3"
What you're learning: The change communication framework in a regulated industry. Legal tech changes are often driven by compliance validation rather than technical slippage — the communication needs to be precise about why the delay happened and what changed in the thinking.
Prompt 3 — Apply (connect to your domain):
Take your current product roadmap (or the roadmap you wish you had)
and audit it:
1. What format is it in? (Now/Next/Later, Quarterly, Timeline?)
2. Which audience is the current format optimised for?
3. What would the other two audience versions look like?
4. Are all dependencies named with owners and need-by dates?
5. Apply the 70/20/10 capacity rule: what percentage of your
team's capacity is currently committed to planned features?
Report what you find. If you discover the roadmap is over-committed
(more than 70% to features), what would come off?
What you're learning: The roadmap audit — applying the frameworks from this lesson to your own situation. Most PMs discover that their roadmap is either in a format that doesn't match their current communication need, or that dependencies are implicit rather than named.
Exercise: Build InsightFlow's Q3 Roadmap
Plugin: Official product-management
Command: /roadmap-update
Time: 30 minutes
Step 1 — Load the L08 story backlog
Gather the stories from your L08 exercise. Group them by the Workflow Builder feature they belong to (Builder UI, Action Library, Trigger Configuration, Status View).
Step 2 — Run /roadmap-update for the base roadmap
/roadmap-update
Create InsightFlow's Q3 roadmap in Now/Next/Later format.
[Use the context from the worked example above, including the
full story backlog, dependencies, and capacity numbers.]
Step 3 — Generate the three audience versions
Run /roadmap-update three more times, once for each audience, using the audience prompts from the worked example. Evaluate each version:
- Engineering version: Does it show sprint assignments and dependency need-by dates? If the threshold trigger dependency is absent, add it.
- Executive version: Does it translate "threshold trigger" into a commercial outcome? If it still says "data threshold trigger configuration," prompt: "Translate technical items into business outcomes for the CEO audience."
- Customer version: Does it avoid dates and feature-implementation language? If it says "Q3" anywhere, prompt: "Replace specific time references with 'coming soon' or 'planned for later this year.'"
Step 4 — Evaluate audience calibration
For each version, check one thing: "Would someone who does not know how software is built be confused by anything in this version?" If yes for the engineering version, it is too simplified. If yes for the customer version, it is too technical.
Step 5 — Simulate a dependency slip
Run this prompt to test the change communication framework:
The data team confirms the threshold trigger evaluation service
will not be ready until Q4. Schedule triggers will ship on time.
Update the Q3 roadmap to reflect this change. Then apply the
five-step change communication framework to produce a stakeholder
communication that:
1. Names the change directly
2. Explains the reason (data team feasibility confirmation)
3. Shows the tradeoff (threshold trigger moves to Q4)
4. Shows the updated Q3 roadmap
5. Identifies who needs a direct conversation (enterprise customers
who asked about data-driven automation in L05 competitive brief)
What You Built
You built InsightFlow's Q3 roadmap from the L08 story backlog in Now/Next/Later format, with dependencies mapped and capacity validated against the 70/20/10 rule. You generated three audience-calibrated versions — engineering, executive, and customer — and applied the five-step change communication framework to a dependency slip scenario.
This roadmap feeds directly into Lesson 10, where you will use /prioritise from the custom product-strategy plugin to RICE-score the Workflow Builder story backlog and produce the quarterly priority decision — determining which stories enter Sprint 1 and which move to Next.
Flashcards Study Aid
Continue to Lesson 10: Backlog Prioritization Frameworks →