Roadmap vs project plan: what the person asking actually wants
A roadmap states intent and sequence and is expected to change. A project plan states committed work with dependencies and dates and changes through a process. The unit differs too, since roadmap items are problems and plan items are tasks. Giving someone a roadmap when they wanted a plan reads as vagueness, and the reverse reads as overcommitment.
| Decision | When | Why |
|---|---|---|
Give a roadmap | The question is what we are doing and in what order | Sequence and intent are what a prioritisation conversation needs, and dates would only anchor it |
Give a project plan | The work is committed, dated and has dependencies someone must manage | A launch with a fixed date needs the critical path visible, and a roadmap deliberately hides it |
Give both, separately | One roadmap item has grown into a dated delivery | Merging them produces a roadmap nobody trusts and a plan nobody reads, because the two are revised at different rates |
Change the roadmap in the review | Whenever priorities shift | Open revision is the roadmap’s function; a roadmap that needs approval to change has quietly become a plan |
Change the plan through a written change | Any date or scope move on committed work | The people holding you to a dated commitment need to see the change, not discover it |
Someone in another function asks for the roadmap. What they open it expecting is a list of dated deliverables with dependencies, because that’s what the plan means everywhere outside product. What they get is three columns of problem statements. The gap reads as evasion, and the next request goes to someone more senior than you.
Two documents, two rules
A roadmap states intent and sequence. It’s expected to change, and changing it in a review is the document working rather than failing. Its items are problems: things that will be true for a customer once the work is done.
A project plan states committed work. It carries dependencies, owners and dates, and it changes through a process where the change is visible to everyone holding the commitment. Its items are tasks.
The distinction that matters isn’t the visual. It’s the revision rule. A document you can move in a meeting is a roadmap. A document that needs a written change and a distribution list is a plan. If your roadmap requires approval to change, it stopped being a roadmap some time ago and nobody mentioned it. Teams keeping both in one general-purpose workspace tend to meet this the hard way, and roadmap tool alternatives is specific about which kinds of tool can hold two revision rules at once.
What is each one bad at?
A roadmap is bad at coordination. It deliberately doesn’t show the critical path, so a launch with four dependent teams and a dated external announcement can’t be run from it. Trying produces the familiar situation where everyone agrees on the quarter and nobody agrees on who is blocked on whom.
A plan is bad at prioritisation. Every item on a Gantt chart is already committed, so the document has no way of expressing that something might not happen, or that it depends on what you learn in March. Put one in front of a strategy review and the discussion becomes the dates, because the dates are the only thing on the page that can be argued about.
This is also why the fields differ. Dependencies, effort and percentage complete belong on a plan and cost you on a roadmap, and the reasoning for each of them is in what to include in a product roadmap.
When a roadmap item becomes a plan
It happens to two or three items a year. Something moves into the current bucket, acquires a fixed date, picks up three teams and an external announcement, and now needs managing at a precision the roadmap can’t carry.
Spawn a plan for that item and leave the roadmap alone. The roadmap keeps one bar; the plan holds the detail underneath it and is owned by whoever runs delivery. Merging them, so that the roadmap carries the detail for one item and not the others, is how a roadmap turns into a tracker export over about two quarters. Where exactly that boundary sits is the engineering team’s version of this argument, worked through field by field in roadmap for engineering team.
Answer the question, not the request
When someone asks for the roadmap, ask what they’re deciding. Hiring, budget, sequencing and whether to say yes to a particular customer are roadmap questions. Launch coordination, dependency management and anything with a date written into a contract are plan questions.
Often what they want is a roadmap and a date, which is a reasonable thing to want. Giving it without turning the document into a plan is covered in roadmap without dates: sequence, horizon and confidence, with exact dates kept for the handful of items that genuinely have them.
Ask the question early enough and most of these requests resolve in a sentence. Nobody wants the artefact. They want to know whether to hire, whether to promise, or whether their own work is about to be blocked.
Common mistakes
Putting dependencies on the roadmap. It becomes a plan that leadership then holds you to at plan precision.
Handing a Gantt chart to a strategy review. Every date on it’s read as a promise, and the discussion becomes the dates.
Running one artefact for both. It gets revised at the plan’s pace and read at the roadmap’s, or the other way round, and both audiences lose.
Assuming the person asking knows which one they want. Ask what decision they’re making before choosing the format.
Questions
Can one document be both?
Not for long. The two are revised at different rates and by different rules, so a merged artefact is either a roadmap that needs change control or a plan that moves without notice. Both are worse than either document alone.
What about a roadmap with a Gantt view on it?
That’s a plan with roadmap styling. The moment dependencies and bars with exact ends are on the page, readers apply plan precision to it, and they’re right to.
Who owns which?
The product manager owns the roadmap. A delivery lead, programme manager or engineering manager owns the plan. When one person owns both, the plan usually eats the roadmap, because the plan has a deadline attached to it.
How do I tell which one is being requested?
Ask what decision they’re about to make. Hiring, budget and sequencing questions want a roadmap. Launch coordination, dependency management and anything with a fixed external date wants a plan.
Related
- Roadmap for executivesFour fields to show, two to hide, and why each call goes the way it does.
- Roadmap tool alternativesWhat the category does better, what a local file does better, and how to tell which you need.
- What to include in a product roadmapOne test for every item, plus the three things that belong on no roadmap outside the squad.
Last updated