Roadmap Communication

---
name: roadmap-communication
description: Communicate roadmaps with now/next/later horizons, honest commitment levels, and audience-shaped views. Use when publishing product direction or managing the fallout of roadmap changes.
---

# Roadmap communication

A roadmap is a communication of strategy under uncertainty, not a
delivery contract. The failures are all mismatched expectations:
dates read as promises, exploration read as commitment, silence read
as stagnation.

## Method

1. **Structure as now/next/later.** Now: in delivery, named
   scope, near-term windows. Next: committed direction,
   shaping in progress, no dates. Later: problem areas under
   exploration (see product-discovery), explicitly subject to
   change. Time-horizons blur honestly where Gantt charts lie
   confidently; put dates only where a date exists (see
   quarterly-planning for how Now gets loaded).
2. **Label commitment level on every item.** Committed (breach
   requires escalation), planned (default yes, displaceable
   with a named trade: see prioritization-frameworks step 6),
   exploring (may die in discovery). Sales and customers hear
   "on the roadmap" as a contract: the labels are what let
   you show direction without manufacturing promises
   (see api-deprecation's commitment discipline as the
   mirror image).
3. **Frame items as problems and outcomes, not features.**
   "Cut onboarding time for finance teams" travels better
   than "build CSV import v2": it survives solution pivots,
   invites better ideas, and ties to the metric it serves
   (see product-metrics, user-story-writing's outcome
   anchoring). Feature-named roadmaps lock you to first
   guesses made at maximum ignorance.
4. **Cut views per audience from one source.** Executives:
   outcomes against strategy and the big bets' status (see
   exec-briefing). Sales/customers: themes and shipped
   value, commitment-labeled, no internal codenames.
   Engineering: full detail with dependencies (see
   technical-vision for the architecture runway beside it).
   One underlying plan, three altitudes: divergent roadmaps
   per audience eventually meet in a customer call and
   detonate.
5. **Change loudly, with the reason.** When priorities shift:
   announce what moved, what displaced it, and why (the
   evidence or event), to everyone holding the old version:
   silent roadmap edits are how trust dies (see
   status-updates' no-surprises rule). Keep the changelog;
   the pattern of changes *is* information about your
   planning quality (see decision-journals).
6. **Pair the roadmap with the not-doing list.** The parked
   items with reasons (see prioritization-frameworks step 5)
   published beside the roadmap answer 80% of "why isn't X
   on here" threads before they start, and make the
   strategy's edges visible: a strategy that excludes
   nothing is not one (see saying-no dynamics in
   feature-sunsetting).

## Boundaries

- Regulated and contractual commitments are real deadlines
  living outside this flexibility; mark them as the hard
  constraints they are (see prioritization-frameworks'
  cost-of-delay cliffs).
- A roadmap cannot substitute for strategy: if items do not
  ladder to a coherent position, the format is dressing a
  list (see technical-vision's same rule for architecture).
- Public roadmaps (open source, platforms) raise the cost of
  every change; default to problems-and-themes there, and
  version-date nothing you would not contractually defend.