The roadmap review is on Thursday. On Wednesday, Marcus realizes he's presenting the same deck to three very different rooms: the Sales team at 10 AM, the Engineering leads at 2 PM, and the executive team at 4 PM.
He built one deck. It's organized chronologically — Q1 through Q4 — with the features grouped by theme, each with a one-sentence description and a status indicator. It's accurate. It's complete. It's exactly nobody's ideal roadmap format.
Sales will want to know which features help them close deals this quarter. They'll get lost in the Q4 column and won't know what to do with the engineering dependency lines.
Engineering will want to know about technical sequencing, dependencies, and capacity allocation. They'll be frustrated by the absence of complexity information and confused by the sales-narrative feature names that don't match the systems they're building.
The executive team will want to understand the strategic rationale and outcome impact. They'll disengage quickly from a feature list with no strategic framing and no metrics.
Same roadmap. Three audiences. Three different failures — unless Marcus builds three different presentations from the same underlying source of truth.
This is the multi-audience roadmap problem, and it afflicts nearly every PM who presents to cross-functional stakeholders. The solution isn't building three separate roadmaps — it's building one underlying roadmap with three intentional presentation lenses.
The Three Audience Lenses
Each audience has a fundamentally different relationship to the roadmap. Understanding that relationship determines how to format, frame, and sequence information for maximum relevance and minimum confusion.
Lens 1: The Sales and CS Audience — "What Can I Promise?"
Sales and Customer Success professionals interact with the roadmap as a promise management tool. Their primary questions:
- Which features are committed for Q1 vs. Q2? (Commit vs. planning distinction)
- Which features directly address the top customer objections and churn reasons?
- Can I tell a prospect "this is coming in March" — or is it more uncertain than that?
- Are there things moving vs. the last roadmap I used in a customer conversation?
What they don't need: Technical implementation details, dependency chains, or the nuanced priority rationale that involves trade-offs between engineering investments.
What damages their meeting experience: Timeline uncertainty presented without a clear communication strategy ("We're planning this for Q2 but it depends on..."). They'll take the uncertainty home and communicate it to customers in an unhelpful way.
The Sales/CS roadmap format:
Q1 Commits (ship date: high confidence)
Feature Customer problem solved Deal impact Bulk export Enterprise customers can't do batch operations Handles most common enterprise trial objection SSO support Required for security-conscious enterprise Unlocks 6 pipeline deals currently blocked on security review Q2 Plans (ship date: medium confidence) [Same structure, explicit note: "These dates are directional — not for use in customer commitments without checking with Product first"]
Later this year (directional) [Feature names only, no dates — these should not be promised to customers]
Changes from last version: [Explicit section showing what moved and why — so Sales can update their customer conversations]
The "changes from last version" section is the most underappreciated element. Every time Sales uses the roadmap in a customer conversation, they're making implicit promises. The PM who flags changes explicitly gives Sales the information they need to manage those promises. The PM who updates the roadmap without a changes section forces Sales to discover the changes mid-customer-conversation — an experience that damages both the customer relationship and the PM-Sales relationship.
Lens 2: The Engineering Audience — "How Are We Building This?"
Engineering leads interact with the roadmap as a planning and capacity tool. Their primary questions:
- What are the dependencies between features? (Can't build B without A being solid)
- What's the sequencing rationale — why this order?
- What's the complexity and risk distribution across the quarter?
- Where are the architectural decisions that need to be made before sprint planning?
What they don't need: Sales narrative, customer-impact framing, or timeline uncertainty managed for external communication.
What damages their meeting experience: Feature names that don't match engineering systems, omission of dependencies, and vague complexity indicators that leave them guessing what they're agreeing to.
The Engineering roadmap format:
Sprint 14–16 (Q1)
Feature System components impacted Complexity Dependencies Decision required Bulk export Export service, job queue, data pipeline High (new queue architecture) Requires job queue refactor to land first Architecture decision: queue vs. batch processing — need decision this week SSO support Auth service, user management Medium None — standalone None Sprint 17–20 (Q2, planning horizon) [Same format, with explicit note: "These are planning-horizon items. Not committed. Capacity will be confirmed after Q1 retrospective."]
Architecture items (cross-sprint) [Separate section for the cross-cutting technical decisions that affect multiple roadmap items]
The key differentiator from the Sales view: explicit complexity, explicit dependencies, and the "decision required" column. Engineers need to know where they'll be blocked by open decisions — and those blocks need to be surfaced before sprint planning, not discovered mid-sprint.
Lens 3: The Executive Audience — "Why Does This Matter?"
Executives interact with the roadmap as a strategy validation tool. Their primary questions:
- Does this roadmap advance the strategic priorities we've set?
- What outcomes will this roadmap produce, and by when?
- What are the key bets we're making, and what's the risk/reward?
- What are we choosing not to do — and why?
What they don't need: Feature-level detail, dependency chains, or the complete Q3-Q4 feature list.
What damages their meeting experience: A feature list without strategic framing. Executives who see a list of features will ask "so what" until someone connects them to outcomes. Make that connection explicit before they're forced to ask.
The Executive roadmap format:
Strategic theme 1: Enterprise Readiness Goal: Enable the three enterprise deals currently in pipeline (estimated $880K ARR) Key bets: SSO support, audit logging, data residency Expected outcome: Unblock 6 security-blocked deals by end of Q1; enable enterprise tier launch in Q2 Risk: SSO timeline has infrastructure dependency — 30% probability of Q2 slip
Strategic theme 2: Workflow Automation Goal: Improve product stickiness in power-user segment (current NPS: 34; target: 45) Key bets: Bulk operations, conditional logic, API webhooks Expected outcome: Power-user weekly active hours +25% by Q3; reduce churn in $10K+ ARR accounts Risk: Conditional logic complexity higher than estimated — may need to scope Phase 1
Explicitly not doing this quarter:
- [Item 1 + one-line reason]
- [Item 2 + one-line reason]
The "explicitly not doing" section is the one most executives wish existed in every roadmap presentation. The absence of a feature from the roadmap is always a prioritization decision — but without explicitly naming it, executives are left wondering whether it was considered. The explicit not-doing section demonstrates strategic discipline: you're not just building whatever was requested, you're making choices.
The Single Source of Truth
The three presentation lenses work because they're all generated from the same underlying roadmap — not three separate roadmaps that drift apart. The underlying truth has all the information:
Feature: SSO Support
Strategic theme: Enterprise Readiness
Customer problem: Required for security-conscious enterprise accounts
Deal impact: Unblocks 6 pipeline deals blocked on security review
Engineering system: Auth service, user management
Complexity: Medium
Dependencies: None
Status: Committed Q1
Commit confidence: High
Promises made to customers: None formally committed
Architecture decisions required: None
Each presentation lens is a filtered, formatted view of this underlying record. When the timeline changes, the underlying record changes once — and all three views update.
The tooling for this can be as simple as a well-structured Notion database or Airtable base with filtered views. It doesn't require specialized roadmap software (though products like Productboard, Craft.io, or Linear help). The discipline is maintaining the underlying record with enough structure to generate all three filtered views.
The Presentation Sequence That Works for Each Audience
Beyond format, the order of information within each presentation matters:
For Sales: Lead with what changed since last version. Their first concern is always whether any customer conversations they've already had need to be corrected. Resolve this immediately, then walk through the commits.
For Engineering: Lead with the architectural decisions that need to be made now. Their attention is highest early in the meeting, and the decisions that block sprint planning are more urgent than any feature-level detail.
For Executives: Lead with the strategic context and outcomes, not the features. The features should be named last, as evidence of the strategy — not as the organizing principle. "We're making these three features our Q1 enterprise bet because..." not "Here are our Q1 features."
The Prodinja Angle
Maintaining a single roadmap source of truth that generates accurate audience-specific views is exactly the kind of systematic discipline that gets deprioritized under sprint pressure. Prodinja's Roadmap Intelligence module helps structure the underlying roadmap record with the audience-specific fields that make multi-lens presentation possible — and flags when the different views are drifting from each other, which is a signal that the underlying source has become inconsistent.
See also the broader stakeholder communication framework.
Key Takeaways
- Three audiences, three lenses: Sales/CS sees commit confidence, customer impact, and changes from last version. Engineering sees complexity, dependencies, and open decisions. Executives see strategic themes, outcomes, and explicit not-doing choices.
- One source of truth, three filtered views. Maintaining separate roadmaps for each audience is unsustainable and creates dangerous inconsistencies when things change.
- The "changes from last version" section is the most underappreciated roadmap element for Sales audiences — it lets them update customer conversations before discovering changes mid-call.
- The "explicitly not doing" section is the one executives most wish existed. The absence of a feature from the roadmap is a prioritization decision — name it explicitly to demonstrate strategic discipline.
- Presentation sequence matters as much as format: Lead Sales with changes, Engineering with open decisions, and Executives with outcomes — in that order.