You might have heard that I’m writing a book on product leadership. It’s a long journey, especially for someone like me who takes their words very seriously. This year, I learned that November was National Novel Writing Month in the US, and decided to participate in a workshop that would help me speed things up.

As you can understand from the name, most workshops are about novels and focus on how to build the plot and the characters that drive it. Despite the fact that my book is non-fiction, I found these lessons fascinating and very relevant. My book, too, needs to tell a story and needs to have a coherent plot where one thing leads to another. Generally speaking, even when you try to explain something to people or convince them of something, it’s best to tell a story. It doesn’t need to be a fiction story, but people understand through stories much better than through facts or advice alone, and that’s true for any type of communication you have at work. 

When I left eBay my team prepared a farewell presentation titled “what’s your story?”. They named it after the feedback I constantly gave them on their presentations. One of the more senior PMs said that he remembers the first time he showed me his roadmap deck. He thought it was perfect and included everything there is to include in such a deck. But I looked at it and said “OK, so?”. He looked at me puzzled, and I explained that I don’t understand what is the message that he wants people to get out of it. What do you want me to remember or understand through this presentation? It took a few more iterations, but eventually, he created a roadmap deck that told the story of the roadmap in a way that people could understand the main takeaways.

These days you all need to present your roadmap to management, and many people are asking for a deck template. Here is the structure that I created that would allow you to tell the story of the roadmap in a way that people can understand.

Before we start, I want to highlight that the roadmap is not a work plan. You still need both, but separating them from each other gives you freedom. The roadmap brings the strategy to life, and therefore the roadmap story should start by clarifying the strategy. That’s what the first two parts are all about.

Part 1: What Are We Trying to Achieve

Every strategy starts with a goal. You need to make sure your goal is well-defined, and at a level that makes sense. For example, if you have an ARR goal that’s usually not enough. This ARR goal typically has many more assumptions behind it regarding the source of this ARR. Do we want many small deals or a smaller number of very large deals? Do we want it to come from a specific product or market segment?

Company-level goals are typically set by management, and as a product leader, it’s your job to help management clarify these goals further. Make sure you can paint a clear and detailed picture of what success looks like.

If you want to build a lego airplane, you need to have a good image of what this airplane would look like in the end. Note that this is a metaphor for your strategy, not your UX.

Part 2: What Is the Best Way to Get There

This high-level plan is your strategy. You need to explain the steps or phases that you will go through to achieve the goal you are trying to achieve. They need to make sense and your audience needs to understand exactly why this is the right path to choose, and how they all add up to your goal. 

That’s one of the hardest things to create in your strategy because typically there are many possible paths you can take, and you need to (a) create a path that makes sense and (b) explain why it’s better than any other path. 

If we continue with the lego airplane metaphor, this part is the instructions that come with the kit. Think how easy your job is once someone created the instructions for you. That’s what you want to do for your company.

Part 3: Where Are We on the Journey

Your strategy shouldn’t change that frequently. If you have done a great job in parts one and two, the next time around you can show progress along the same strategic journey. Even if you are only doing it for the first time now, most likely you are not on the first day of the journey. Planning happens when it happens, and usually along the lines of a journey that had already started.

To be able to decide where to go from here (part 4), you need to first identify and calibrate everyone on where you are right now. This is a good place to mention past achievements that will explain why you feel comfortable moving on to the next part of your journey.

For example, if your journey is along the lines of the general journey toward product-market fit, you might explain that you have identified your Ideal Customer Profile (ICP) and now are in the process of succeeding with a few of them. There are more details to it. You are most likely in the middle between stages in the journey (because planning happens when it happens) – maybe you have one or two customers that you feel you have already succeeded with but in order to truly feel that you have completed this phase you need about ten such customers. You might feel that you are doing well in getting people’s attention and trying out the product but not so well in converting them to ongoing retained customers. Take the time to explain your real current status. 

In our lego metaphor, this is where you look at what you already built and understand which steps in the instructions you had already completed.

Part 4: What Are We Going to Focus On Next

If you described your journey well in part 2, the next step should be relatively easy. Think about it: you outlined the journey and found where you are at, so now you need to keep walking along the lines of what you had already defined. The broader perspective you have on the journey, the easier it is to choose and focus on the next steps that make sense. 

If you follow the product-market fit example from above, it is clear that you need to focus on retention.

In our lego metaphor, this part is where you circle the steps in the instructions that you want to complete within the timeframe of the roadmap. Use it to set expectations correctly, it will serve you later.

Part 5: How Are We Going to Do So

So our focus for this roadmap is retention, but what undermines your retention today? Which gaps do you see that need to be closed? To answer these questions you probably need to conduct some research. Don’t try to fit in the features already in your backlog before you understand why they are the right ones to include and how they serve the strategy and goal.

In our lego metaphor, these are the specific blocks you need in order to complete the selected steps in the instructions. Unlike lego though, you don’t need to include here any line of code that is about to be written next year, not even everything you are going to do to tackle the specific issue at hand (say retention). Remember that these things are here to help the audience get it, so include the major things that help them understand.

Part 6: What Is Left Outside

This part is again a matter of setting expectations. I’m a big believer in stating bad news as clearly and as early as possible so that everyone can debate and adjust to them early on. The bigger the expected conflict is, the more important it is to say upfront that you are not going to include a certain area in your roadmap.

Use this as an opportunity to discuss and align, not as one-way communication.

Back to our lego metaphor, circle on the instructions the steps that are not going to be tackled within this roadmap. If you have specific features (lego blocks) that people are expecting and don’t fit into your focus, highlight them as well.

Part 7: High-Level Time Estimates

Eventually we need to know what to expect, so this part should give a ballpark estimate of when things will be ready. Ideally, you should focus on outcomes and not features. That is, when we can expect to have great retention rates rather than when we can expect to have the user management feature ready.

Part 8: Dependencies, Risks, and Mitigation

Creating a roadmap is not just about planning, it’s also about the ability to deliver. If you want to truly navigate your ship to success, you must understand how to tackle obstacles along the way, and the best way to do so is to think about major ones in advance. 

This is an easy part to add to your roadmap, but including it would help you position yourself as the leader who takes full responsibility for delivering success, and not just features.

Remember that the most important benefit of your roadmap is the discussions that happened when you built it and the decisions you made along the way. Everything else – the plan itself – will most likely change numerous times, but that’s how it’s supposed to work.

Happy roadmapping!