What a roadmap is (and isn't)

A product roadmap is a strategic communication tool. It shows how the product will move towards its vision: which customer problems and business goals the team will tackle, roughly in what order, and why. It answers three questions for everyone around the product: where are we going, why, and what comes first.

Notice what's missing: exact dates, task owners, story points. Those live elsewhere.

A roadmap has many readers, and each takes something different from it. Engineering sees why the work matters. Sales and marketing see what to prepare for. The CEO and the board see how money turns into results. Customers see that their problems have been heard.

A good roadmap shows a direction, not a contract. It says “this is where we're heading and why”, and it's honest that the route will change as the team learns.

The reason is simple: the further ahead you look, the less you know. A roadmap serves many readers for months, so a dated promise for every item is mostly guesswork, and it breaks the first time the team learns something new.

Compare two pages for the same team. The first lists outcomes in a broad order: what's now, what's next, what's later, with a note that Next and Later will change and the date of the last review. The second lists features with exact days next to them.

The first survives surprises. If research in March shows that reminders don't stop cancellations, the team swaps the solution and the page still tells the truth. The second breaks: every slipped day is a broken promise to someone who planned around it.

Timing doesn't disappear from a direction-style roadmap: readers still see what comes first and roughly when. What disappears is the false precision that turns a plan into a debt the team owes.

A roadmap isn't the only planning document, and it shouldn't try to do the others' jobs. What ships when, who does which task, which story comes next: all of that lives one level down. Each document answers its own question:

• Product roadmap: where are we going, why, and what comes first? Direction and reasons.
• Release plan: which solutions ship in which release, with scope, dates and capacity. It answers “how and when” for work the roadmap has already justified with “what and why”.
• Product backlog: the ordered list of stories and bugs the team picks up in the next sprints.
• Project plan, often drawn as a Gantt chart: who does which task and what depends on what.

All four are useful, and they feed each other: the roadmap sets the direction, the release plan turns chosen solutions into dates, the backlog breaks them into work, and the project plan coordinates people. Trouble starts when one pretends to be another. A Gantt chart of 40 features sent to the board is a project plan dressed as a roadmap: lots of dates, no reasons.

Before you answer a request, separate what someone asks for from why they ask. The literal request is often one person's guess at a solution; the reason behind it is the need you actually have to serve. Deliver only the literal request and you can do exactly what was asked while the need stays unmet.

At CatChow, the CEO, Ian, asks for next year's roadmap by Friday: each of the 40 requests in the team's spreadsheet with a month next to it, “so sales and marketing can plan around it”. The request is dates. The reason is in the second half of his message: the board, sales and marketing need to plan.

Planning needs a clear direction and an order of priorities. It doesn't need 40 guesses dressed up as commitments, which by May would mean slipped features, a couple of useless ones and a customer quoting a March date to sales. Give Ian direction and order, and keep firm dates for the work the team can actually vouch for.

Dating every row of a roadmap has a hidden cost: to put a date on every row, someone has to estimate every row, long before anyone knows what the solution will be. At CatChow, the tech lead, Lucy, hears the roadmap will have a date for each of 40 features and asks whether she needs estimates for all of them by Friday. Her team barely understands half.

A request like “bulk ordering for clinics” could mean a shared spreadsheet or a whole ordering system; the estimate depends entirely on which one the team ends up building. Numbers produced this way are guesses dressed up as a plan, and they hide the uncertainty instead of showing it.

An honest roadmap doesn't need a year of estimates up front. It names the problems and their order. Engineering estimates a solution once the team understands the problem and has chosen how to solve it, which usually happens close to the work itself.

A roadmap turns into a promise the moment people read its dates as commitments. Then dates leak into contracts, and every slip costs a customer's trust. At CatChow it starts with one chat message: Brandon, the key account manager, told PurrPoint, a chain of 14 vet clinics, that bulk ordering will be ready in April, and asks to put it on the roadmap for April.

The loud symptoms are easy to spot:

• roadmap features and dates appear in customer contracts;
• sales closes deals on features that don't exist yet.

The quiet ones are easier to miss:

• the team ships everything on time, yet retention and revenue don't move;
• features pass acceptance but don't solve the problem;
• people ask “why is this on the roadmap?” and only hear when it's due.

A year of up-front estimates, the hidden cost of a dated feature list, belongs to the same family. Healthy signs look the opposite: every item links to a business objective, and the page says plainly that plans will change as the team learns.

When someone asks for a specific solution with a date on the roadmap, ask why before you add the date. The request hides a problem, and the problem is what the team can commit to.

Brandon's April promise to PurrPoint shows the three bad options. Saying yes puts a date on the roadmap that the team has never checked, for a solution nobody has examined. A flat no leaves Brandon looking bad in front of a client about to sign for 14 clinics. Quietly parking it under “Later” while Brandon says it's on the roadmap is just a vaguer promise.

“Bulk ordering” is Brandon's guess at a solution. Behind it is a problem: maybe clinic admins spend hours ordering by phone, maybe orders get mixed up, maybe prescription diets run out. Each problem has a different best solution, and some are far cheaper than a full ordering system.

Once the problem is clear, CatChow can commit to solving that and date only the part the team is confident about. The next lesson turns this “why?” into a method.

Three quick checks tell you whether a roadmap is doing its job.

• Trace check: point at any row and ask which goal or customer problem it serves. If nobody can answer, the row doesn't belong there.
• Change check: imagine the team learns something in March that reshuffles the plan. Can you update the page without breaking a promise to anyone? If not, it's written as a contract.
• Reader check: the tech lead, a salesperson, the CEO and a customer each open it. Does each find their answer (why, what comes first, what to prepare for) without booking a meeting with you?

Each failure points to its own fix: an orphan row needs a reason or should leave; a page that can't change needs looser dates and a note about change; a page nobody understands needs plainer words.

How it fits together: a roadmap that passes all three shows direction, reasons and order instead of dated promises, so it serves the need behind requests like Ian's and Brandon's and survives what the team learns. Next, Outcomes over outputs shows what each row should say.