Ask most product teams to show you their roadmap and they'll show you a Gantt chart. Ask them to show you their plan and they'll show you the same thing. The two words are used interchangeably in almost every product team I've worked with. They shouldn't be. The difference matters more than most people realise.
A roadmap is a communication tool. It communicates intent — what the team has decided to focus on, in what approximate order, and why. It is directional, not contractual. It is a view of the future based on current knowledge, and it should be expected to change as knowledge changes.
A plan is an execution tool. It communicates commitments — who is doing what, by when, and what done looks like. It is specific, not approximate. It is the thing that makes a roadmap actionable, and it should be expected to be followed unless something forces a change.
Having a roadmap without a plan is having intent without execution. Having a plan without a roadmap is having execution without direction. Most teams have the roadmap. Far fewer have the plan.
Why confusing them causes chaos
The most common dysfunction I see in product teams comes from treating a roadmap as a commitment. The leadership team sees "Q2: payment system rebuild" on the roadmap and treats it as a delivery date. The engineering team treats it as a directional signal that might shift. Neither party has been explicit about what they're treating it as — so when Q2 arrives and the payment system rebuild is still in progress, there's a breakdown.
The fix isn't to make the roadmap more accurate. The fix is to also have a plan. The plan would have identified, in Q1, exactly what was required to deliver the payment system rebuild in Q2: which engineers, which external dependencies, which design work. If those inputs didn't exist or shifted, the plan would have surfaced the problem weeks earlier — not when the deadline was missed.
The roadmap is the promise. The plan is how you keep it.
What a roadmap should contain
A roadmap should contain three things: what you're working towards, why those things and not others, and how confident you are. Confidence decreases the further out you go — and good roadmaps show that explicitly. "Q1: highly confident. Q2: medium confidence. H2: directional." This is honest about the nature of planning, and it stops stakeholders treating a six-month-out item as a guarantee.
A roadmap should not contain specific dates, specific engineers, specific resource allocations, or detailed task breakdowns. Those belong in the plan.
What a plan should contain
A plan should contain named owners for every piece of work. Not teams — people. Not "engineering" — the specific engineer. It should contain a specific done condition: not "build the payment system" but "payment system processing transactions in production, load tested to 10,000 concurrent users, PCI compliance sign-off obtained." It should contain dependencies — other pieces of work that must be complete before this one can start. And it should contain the earliest signal that the plan is off track, so the team knows when to escalate before the deadline, not when the deadline has passed.
The conversation that creates alignment
The single most useful alignment conversation a product leadership team can have is the translation session — the meeting where the roadmap items get converted into plans. Not "what are we building in Q1" — that's the roadmap conversation. "Who specifically is building the checkout flow improvement, what does done look like, what has to be true by week four for us to be on track, and what are the two most likely failure modes" — that's the planning conversation.
Most teams never have the second conversation. They update the roadmap and call it planning. Then they wonder why, when the roadmap says the thing should be done, the thing isn't done.
The roadmap is not the plan. The plan is the plan. You need both.
