The question executives asked in almost every planning review I sat in this week, 5 ways to design a roadmap so it answers that question first, and 4 books on showing how sure you are.
Roadmaps get designed less carefully than almost anything else a product team makes. What’s worse, they get read by the people with the most say over what happens next. I spent a good part of this week in planning reviews, and the same question came up in nearly every one: is this list what you’re committing to with the team you have, or does it depend on resources nobody has approved yet?
It’s a fair question, and most slides couldn’t answer it. A list of bullets under a theme gives every item the same weight. The thing already in build sits next to the thing someone thought of last week, in the same font, with the same confidence. At one point a senior leader looked at a list like that and said, in effect, that he didn’t know how to feel about it. That’s a design problem. If we shipped a screen where a saved item and an unsaved item looked identical, we’d call it a bug.
Here are the approaches I saw work, across different teams.
-
Tag every item by stage. Discovery, define, or build. Anything in build implies someone approved it, so the tag does a lot of talking for you. It also protects the early ideas, because nobody mistakes them for promises.
-
Mark what isn’t funded, visually. One team color-coded the work that depended on new resources and put the rest on a separate “below the line” slide. The questions they got were sharper and shorter. The presenter also volunteered which items were riskiest because they were the least understood, which earned a lot of trust in about 10 seconds.
-
Separate the dates from the best efforts. There are usually 2 or 3 things with a firm deadline and a longer list of things you intend to do. Say which is which, and be careful what you attach to a launch date or a marketing moment, because every date you add is flexibility you give up.
-
Show where the list came from. The strongest slide I saw laid out the customer’s journey end to end as cards, each with what the team invested in this year and what’s planned next. When someone asked, “How did you get to this list?” the answer was already on screen: every item mapped to a point of friction.
-
Ask the room what it wants first. One presenter opened with a single summary slide of her 3 areas and let the executives pick the order and the depth. It took a minute, and the whole session went to what they cared about most.
If we shipped a screen where a saved item and an unsaved item looked identical, we’d call it a bug. Most roadmap slides ship that way.
Two things fell flat often enough to mention. Walking through the tracker project by project got redirected every time, usually with a request for 2 or 3 themes, because the audience above the room won’t look at 12 launches. The slide that was missing most often was the simplest one: what we heard from customers, why it matters, and what we’re building because of it.
The second is a caution for anyone who synthesizes research. One slide of “top customer themes” covered only the feedback that supported the team’s favorite initiative, and it got caught right away. It read as working backwards to justify the idea. The presenter took it well and agreed to rerun the analysis across everything, which was the right call. Curating your evidence costs you more than a weak slide does, because it makes people doubt your strong ones.
None of this needs a new tool. If you’re a designer and your PM partner is building a roadmap deck this quarter, offer to help with it the way you’d help with a screen. Ask what state each item is in and how someone would know by looking. They’ll probably take you up on it.
Four books on showing how sure you are.
The shelf
