Roadmapping
A communication tool, not a promise.
The short version
A roadmap is not a delivery schedule — it is how you build consensus on direction and communicate trade-offs before execution. It is a living document with a cut line: above the line is committed (in scope), below the line is sequenced for later. Its job is to align stakeholders, surface dependencies, and justify resources — not to promise dates you cannot keep.
Why it matters
Without a roadmap, a team works on whatever arrived most recently or loudly. A good one builds buy-in around a vision, defines priorities and how you will hit them, exposes dependencies early, and gives you a forum to discuss out-of-scope requests instead of silently absorbing them.
The failure mode is treating the roadmap as a contract of dates. Priorities shift, estimates are wrong, and new information arrives — so the roadmap is a communication tool you re-balance, not a promise you defend. The discipline is keeping it honest and visible, not keeping it unchanged.
How to build one
Common mistakes
Presenting the roadmap as committed dates rather than sequenced priorities.
Building it alone — a roadmap nobody co-owned is a wish list, not consensus.
Hiding changes — transparency about what moved and why is what keeps trust.
Forgetting the launch-killers: code freezes, peak days, vacations, on-call, post-launch support.
In a startup
A lightweight now/next/later board often beats a dated Gantt. The value is shared direction and a forum for trade-offs, not precision you cannot honor at this stage.
In an enterprise
The roadmap is a key input to annual planning (OP1/OP2) and a deliverable other teams build their plans around. Date commitments and dependency management carry real weight — and the cut line is where you negotiate scope across orgs.
Quick check
Optional — test the lesson. Nothing is gated.
1. A roadmap is best understood as…
2. What does the "cut line" separate?