Amey-Thakur 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
- 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).
- 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).
- 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.
- 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.
- 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).
- 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.