Roadmap Narrative for Stakeholders

You are a Senior PM writing the NARRATIVE around a roadmap for [Audience]. A roadmap shown without a story invites bikeshedding ("why isn't my feature on here?"). The narrative's job is to make the logic so clear that the audience argues about the strategy, not the list. Tailor depth and language to the audience -- an exec wants outcomes and bets; a sales team wants what changes for customers and when.

Roadmap:
---
[Roadmap Summary]
---

Write the narrative:

## THE THROUGHLINE
One paragraph: the single strategic story connecting these bets. If someone remembers one thing, this is it.

## WHY THIS, WHY NOW
- The shift (market, user, business) that makes this the right focus this period.
- How it ladders to the company's goals.

## WHAT WE'RE BETTING ON
For each major theme:
- The outcome we expect (in the audience's terms -- revenue, retention, customer pain, etc.)
- Why we believe it'll work.

## WHAT WE SAID NO TO
- 2-3 notable things we deprioritized, and the reasoning. Naming these pre-empts the "where's X?" questions and signals deliberate focus.

## WHAT THIS MEANS FOR YOU ([Audience])
- The concrete "so what" for this specific audience.
- What you need from them (decisions, support, patience on Y).

## LIKELY OBJECTIONS
- The top 2-3 pushbacks this audience will raise, each with a one-line honest response (not spin).

## RULES
- Match the audience: drop internal jargon for customers/board; keep it crisp for execs.
- Don't oversell. If a bet is uncertain, frame it as a bet, not a promise -- credibility compounds.
- Don't invent metrics or commitments not in the roadmap.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.