# What a roadmap is (and isn't) > Why a feature list with dates fails as a roadmap, what a product roadmap is actually for, and how it differs from a release plan, a backlog and a Gantt chart. - Course: [Outcome-Based Product Roadmaps](https://productovi.com/courses/outcome-based-roadmaps.md) - Module: Why roadmaps need a rethink - Lesson 1/15, ~39 min - Source: https://productovi.com/courses/outcome-based-roadmaps/what-is-a-product-roadmap ## Where you work **Alex Tutor:** Welcome to the course. We're at **CatChow**, an online shop that delivers cat food to homes and supplies vet clinics. It has grown fast, and requests pour in from sales, support and the founders; nobody can say which matter most. You've joined its product team, alongside Sofia, the product manager. **Alex Tutor:** CEO Ian has asked for next year's roadmap, and over this course you'll build it with Sofia around results rather than a list of features with dates. Today we start with the basics: what a roadmap is, and what it isn't. It looks like his request has already landed. ## Ian wants dates **Sofia:** It has. He wants it by Friday. Here's his message: **Ian:** The board meets on the 14th. I need next year's roadmap by Friday: every feature with a month next to it, so sales and marketing can plan around it. **Sofia:** And I have this spreadsheet: 40 requests from sales, support and the founders. My plan is to sort them by who asked loudest, give each one a month and turn it all into a nice Gantt chart. **Dataset (CSV):** [CatChow's request spreadsheet](https://productovi.com/datasets/outcome-based-roadmaps/what-is-a-product-roadmap/catchow-requests.csv) The 40 feature requests from sales, support and the founders that the product team starts the course with, in the order they sit in the spreadsheet. Synthetic data made for this course. - `id`: Row ID - `request`: The request as written in the spreadsheet - `source`: Who asked: sales, support or the founders **Alex Tutor:** Let's fast-forward to May. Five of those features have slipped, two turned out to be useless, and a customer is waving your March date at the sales team. What has your roadmap become? ![A wall calendar covered in small cards pinned to squares; several have fallen and lie crumpled on the floor while a disappointed customer looks at an empty square.](https://productovi.com/courses/outcome-based-roadmaps/inline/what-is-a-product-roadmap-illustration-2.webp) *Forty dates in October become a list of broken promises by May.* **Sofia:** A list of broken promises. OK, but Ian asked for dates. What else can I give him? **Alex Tutor:** Hold that thought. To know what to give him, first see what a roadmap is for. We'll come back to his reason. ## What a roadmap is for **Sofia:** So what is a roadmap, if not a list of features with dates? **Alex Tutor:** 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. **Alex Tutor:** 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. **Sofia:** Who is it for, then? Ian or the team? **Alex Tutor:** Both, and more. Engineering sees why the work matters. Sales and marketing see what to prepare for. Ian and the board see how money turns into results. Customers see that their problems have been heard. **Alex Tutor:** That's why 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 we learn. ![A blue delivery van at the start of a dotted route on a map leading to a bright point on the horizon, a compass beside it; the route bends around obstacles.](https://productovi.com/courses/outcome-based-roadmaps/inline/what-is-a-product-roadmap-illustration-3.webp) *Where we're heading and why, while leaving room to change the route.* > **Exercise:** A product roadmap is a commitment to deliver every listed feature by the date next to it. **Alex Tutor:** Here are two pages for the same team. Which one would still be true in May? > **Exercise:** Two versions of CatChow's roadmap for next year. Which one shows a **direction** rather than a contract? ## Roadmap, release plan, backlog, Gantt chart **Sofia:** But the team still needs to know what ships when. Where does that live? **Alex Tutor:** In other documents, one level down. A **release plan** says 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”. **Alex Tutor:** The **product backlog** is the ordered list of stories and bugs for the next sprints. A project plan, often drawn as a Gantt chart, tracks tasks, owners and dependencies. All useful, each with a different job. **Sofia:** So my Gantt chart would have been a project plan pretending to be a roadmap. **Alex Tutor:** Exactly. And look who's typing in the chat. **Lucy:** Quick question: Ian says you're making a roadmap with dates for 40 features. Does that mean I need estimates for all 40 by Friday? We barely understand half of them. **Alex Tutor:** That's the hidden cost of a dated feature list: someone has to estimate everything up front, long before anyone knows what the solution will be. Those numbers are guesses dressed up as a plan. > **Exercise:** Match each document to the question it answers. **Alex Tutor:** Now back to Ian's message. His request is “dates”; the reason sits in its second half. What does he actually need? > **Exercise:** Ian asks for each of the 40 requests in the spreadsheet with a month next to it, “so sales and marketing can plan around it”. What does he most need from the roadmap? **Alex Tutor:** Lucy's question deserves its own check. True or false? > **Exercise:** To build an honest roadmap, engineering should first estimate every request on it for the whole year. ## When a roadmap turns into a promise **Brandon:** Hi all! Quick one: I told PurrPoint that bulk ordering for clinics will be ready in April. They're about to sign for all 14 of their clinics. Can you put it on the roadmap for April? **Sofia:** Oh no. This is exactly it, isn't it? **Alex Tutor:** It's the classic pattern. Once people read a roadmap as a promise, dates leak into contracts, sales starts selling things that don't exist yet, and every slip costs you a customer's trust. ![A salesperson hands a client a signed contract with a page torn from the planning board stapled to it, while the product team watches nervously.](https://productovi.com/courses/outcome-based-roadmaps/inline/what-is-a-product-roadmap-illustration-4.webp) **Alex Tutor:** There are quieter symptoms too. The team ships everything on time, yet the numbers don't move. Features pass acceptance but don't solve the problem. People keep asking “why is this on the roadmap?” and nobody knows. **Sofia:** Should I just tell Brandon no? **Alex Tutor:** Not yet. A flat no leaves him looking bad in front of PurrPoint. Ask why: what problem do the clinics want solved? Then we can commit to solving that problem and put a date only on what we're confident about. > **Exercise:** Which of these are signs that a company treats its roadmap as a delivery promise? Select all that apply. ## Three checks for a good roadmap **Sofia:** Let me put it together. How will I know on Friday that my roadmap is any good? **Alex Tutor:** Run three quick checks. The **trace test**: point at any row and ask which goal or customer problem it serves. If nobody can answer, the row doesn't belong there. **Alex Tutor:** The **change test**: imagine we learn something in March that reshuffles the plan. Can we update it without breaking a promise to anyone? If not, it's written as a contract. **Sofia:** And the third? **Alex Tutor:** The **reader test**: Lucy, Brandon, Ian and a customer each open it. Does each of them find their answer, why, what comes first, what to prepare for, without booking a meeting with you? Three passes, and it's doing its job. **Sofia:** Ian will still want to know when things happen, though. **Alex Tutor:** Fair, and he'll get a sense of timing: what's now, what's next, what's later. Broad buckets instead of exact days. We'll build that in the third lesson. Now, back to Brandon. > **Exercise:** Brandon asks to put “bulk ordering for clinics, April” on the roadmap because he has already mentioned it to PurrPoint. What is the best reply? **Alex Tutor:** Before you write to Ian, try the three checks on a real situation. > **Exercise:** In March, CatChow learns that reminders don't reduce cancellations. Updating the roadmap now means calling three clients about the dates they were promised. Which check has this roadmap failed? ## Sofia answers Ian **Sofia:** OK. Sofia has to answer Ian today, or he'll assume we're drawing the Gantt chart. She's asked me to draft it. **Alex Tutor:** Start from what he needs: the board and sales want to plan. Offer that, and say what they'll see on Friday instead of 40 dates. **Sofia:** Should I mention Brandon's April promise too? **Alex Tutor:** Not in this message. One problem at a time; Brandon's turn comes next. **Sofia:** And no lecture on roadmap theory. **Alex Tutor:** Right. He's the CEO: two or three sentences, and make it easy for him to say yes. > **Exercise:** Write Sofia's reply to Ian (2–4 sentences): what she will bring on Friday instead of a dated list of 40 features, and how it still helps the board, sales and marketing plan. ## Brandon's April promise **Brandon:** So… April or not? PurrPoint's procurement manager is calling me tomorrow. **Sofia:** I'd like to understand what PurrPoint actually needs before we talk about April. **Alex Tutor:** Good. “Bulk ordering” is Brandon's guess at a solution. Behind it there's a problem: maybe clinic admins spend hours on the phone, maybe orders get mixed up, maybe prescription diets run out. **Alex Tutor:** Each of those problems has a different best solution, and some are far cheaper than a full bulk-ordering system. Help Brandon go into tomorrow's call with good questions. > **Exercise:** Write 2–3 questions Brandon can ask PurrPoint's procurement manager tomorrow to find out what problem “bulk ordering” is meant to solve. Don't promise a date or a feature. ## Someone else's “roadmap” **Alex Tutor:** Before Friday, let's practise on someone else's roadmap. Problems are easier to spot when it isn't yours. **Sofia:** Whose is it? **Alex Tutor:** A friend of mine is a PM at a small Ukrainian SaaS for accounting firms. Her director has just sent this to the whole company and to five key clients. **Sofia:** To clients? With exact dates? Brave. **Alex Tutor:** Read it twice: once as one of those clients, once as someone on the team. Ask what each of them will take away from it. > **Exercise:** Critique Docketly's “Product roadmap 2027”. ## What to remember **Sofia:** So on Friday Ian gets direction and priorities, not 40 dates. Lucy doesn't estimate everything. And Brandon finds out what's really wrong at PurrPoint. **Alex Tutor:** That's it. A roadmap earns trust by being honest about what we know, what we don't and why we're doing the work. > **Key ideas** > > - A **product roadmap** is a strategic communication tool: where the product is going, why, and what comes first. > - It shows a direction, not a delivery contract. Exact dates, scope and owners belong in the release plan, the backlog and the project plan. > - A dated feature list forces up-front estimates, turns into promises in contracts and hides the “why”. > - When someone asks for a feature by a date, ask what problem it should solve. **Alex Tutor:** Next time: your spreadsheet is full of outputs. We'll turn them into outcomes. - Next lesson: [Outcomes over outputs](https://productovi.com/courses/outcome-based-roadmaps/outcomes-over-outputs.md) --- Productovi Learning. Free, no sign-up needed to read.