Every customer engagement hits a point where someone asks for a roadmap. And the word gets used for a lot of different things. An exec sponsor hears “roadmap” and thinks about whether the money is paying off. A tech lead hears it and thinks about next quarter’s work. The engineer doing the delivery hears it and thinks about what’s on their plate next Monday. Same word, three different things, and all of them are fair.
What a roadmap actually is
A roadmap is an agreement between a vendor and a customer about what’s going to get done, in what order, by when, and how both sides will know it worked. That’s it. Everything else — the Gantt charts, the phase tables, the RAG dashboards — is just a way of showing that agreement to a specific audience.
Usually four audiences end up wanting to look at it:
- The customer’s exec sponsor, who wants to see outcomes and whether the money was worth it
- The customer’s tech lead, who wants to know what’s happening this quarter and who owns what
- The vendor’s CSM or PS lead, who wants to see risk and whether the account looks healthy
- The delivery engineer, who wants a checklist
Each one wants something slightly different from the same document, which is why “the roadmap” keeps getting asked for in new shapes. It’s not that anyone is being difficult — it’s that one document is doing four jobs.
A template you can use
I put together a fillable HTML template that has the structure I’ll describe below. Click any field to edit it, click the status pills to cycle through Complete / In progress / Not started, then print to PDF when you’re done. Your edits stay in the browser — nothing gets sent anywhere.
→ Open the fillable one-page roadmap template
Click any field to edit. Print to PDF when you’re done.
What a roadmap is actually good for
A few things, when it’s done right.
It gives you something to point at when renewal time comes around and someone asks what’s been delivered. If the value is written down in the customer’s own words, against things they agreed to at the start, that conversation is a lot shorter.
It covers you when a phase slips because the customer hasn’t given you the access you need, or hasn’t answered a question, or some other thing that isn’t on you. If those dependencies are named on the roadmap from day one, the slip is a dependency slip, not an engineer slip.
It forces a conversation about what’s not in scope. This one is underrated. If you don’t say out loud what you’re not doing, people assume you’re doing it, and the engagement ends with someone feeling shortchanged over something that was never on the table.
And it gives you one clean document to hand over when PS hands off to CSM. Better than a folder of meeting notes and half-filled spreadsheets.
A bad example
The most common trap is a “roadmap” that’s actually the delivery plan in disguise. Forty-plus rows across several tabs. Every row owned by the same vendor engineer. Business outcomes hidden in a “success criteria” column two scrolls to the right. No customer-side owners anywhere. No dependencies listed. Nothing about what’s out of scope.
Here’s the thing — that document isn’t wrong. It’s accurate, it’s thorough, and it’s genuinely useful to the person doing the work. The problem is calling it the roadmap and handing it to an exec sponsor. They’ll read two rows, realise it wasn’t written for them, and quietly start wondering if there’s a real roadmap at all.
It’s not the roadmap. It’s the delivery plan. Both are needed, but they’re not the same thing.
A good example
One page, six things on it, nothing else.
The business objective in one sentence, in the customer’s own words. Not product terminology. If you can’t write it as something the customer would actually say out loud, you’re not there yet.
Phases described as outcomes, not activities. What the customer can do at the end of each phase that they couldn’t do before. “Phase 2: run team can self-serve topology and path analysis for tier-1 incidents.” Not “Phase 2: complete discovery.”
One measurable success criterion per phase. Just one. If you can’t pick one, you haven’t figured out what success looks like yet.
Joint ownership. Every phase has a named owner on the vendor side and a named owner on the customer side. If every row belongs to the vendor, nobody on the customer side feels accountable, and adoption stalls.
Open dependencies and risks, written down on the same page as the plan. Access, data, availability, anything that could slip the plan. Surface it early so when it slips, the slip is predictable.
What’s not in scope. Two or three lines, plain language. Name the stuff people might assume is included so it doesn’t turn into a surprise later.
The detailed trackers — deployment checklist, training plan, value ledger — still exist. They live as backing documents you maintain alongside. The one-pager is the thing the sponsor actually reads.
Closing thought
Different audiences need different framings of the same work, and the framing that worked last quarter might not be the one that works this quarter. Figuring that out early saves you from re-doing the underlying work every time the framing shifts. Keep the structure stable, change the view.