What's in a Roadmap

The first time I sat in a room and watched a sales rep read a roadmap slide back to a customer as a list of guaranteed delivery dates, I understood why product managers get twitchy about who sees these things. The rep was not lying. He genuinely believed the dates on the slide were commitments, because nobody had ever explained to him what a roadmap is and what it is not.

So let me try to explain it, because I have spent a good chunk of my career translating roadmaps into messaging, and the gap between what a roadmap says and what people think it says is where a lot of trouble starts.

A roadmap is a statement of intent. It says here is where we think the product is going, here is roughly the order we plan to tackle things, and here is why. That is it. It is not a contract, it is not a delivery schedule, and it is definitely not a list of features you can bank on shipping by a specific quarter. Priorities shift, a big customer changes the calculus, a dependency slips, someone quits. The roadmap is the best current guess of a team that is trying to be honest about an uncertain future. Treating it as a promise is like treating the weather forecast as a legally binding document.

The other thing worth understanding is that there is almost never just one roadmap. There are at least two, and they serve different audiences.

The internal roadmap is the messy, honest one. It has dates, it has effort estimates, it has the features nobody wants to talk about publicly yet, and it has the stuff that might get cut. In most shops it does not live in a slide deck at all, it lives in Jira or GitLab, wired straight into the epics and issues the team is actually working, which is exactly why it changes so fast. Engineering, product, and sometimes marketing live in this version. It changes constantly. If you looked at the internal roadmap from three months ago and compared it to today, half of it would have moved. That is not dysfunction, that is a team responding to reality.

The external roadmap is the cleaned-up, careful version that goes in front of customers, analysts, and the public. It talks in themes and directions more than dates. Instead of “GPU driver automation shipping Q3,” it says “we are investing in making GPU workloads easier to deploy.” It communicates direction without making commitments the team cannot guarantee. The external roadmap exists to build confidence, not to set a deadline someone can hold you to.

Here is where I come in as a product marketer. My job sits right on the seam between those two versions. I take the internal roadmap, which I need to actually understand, and I figure out how to talk about it honestly to the outside world without either overpromising or being so vague that it means nothing. That is a real tension. If I am too specific, sales turns it into a promise and support pays for it later. If I am too vague, nobody believes the product is going anywhere.

The way I use a roadmap is as a source of narrative, not a source of dates. When I read the internal roadmap, I am looking for the story. What is the arc here? What problem are we chasing over the next year, and why does the order make sense? A good roadmap has a plot. The features are not a random pile of tickets, they add up to a direction. My job is to find that direction and make it legible to a customer who does not care about our sprint planning but does care about whether this product is going to keep being useful to them.

If you are new to working with roadmaps, the single most useful habit you can build is to stop reading them as calendars. Read them as intentions. Ask what the team is trying to accomplish and why they sequenced it the way they did. The dates will change. The intent, if the team is any good, tends to hold.