Congratulations! You created a product strategy that you feel confident with. You validated it enough with the market and you know it’s time to start moving forward with it. The product itself might be very far from where your strategy should take it, and you need to create a roadmap that will take you there. 

A Roadmap Is Not a Work Plan

I can’t start talking about a roadmap without making sure we are talking about the same thing. Many people (product leaders and their managers alike) see roadmaps as a work planning tool. While it is related to planning the work, the roadmap is not the right tool for managing your backlog. It is a planning tool at a much higher level. 

Think about it like explaining to a friend how to get from their house to yours. You are going to explain accurately enough so that they know what to do at each point in time, and when is the time to take a turn. But you are not going to tell them where they would have traffic lights that they need to stop at, or when they would need to stop for gas. You are also not going to mention every crossroad they will pass unless it is meaningful to the overall route.

Like the example above, the roadmap needs to be clear enough so that everyone understands how it gets you to where you want to be. It means that anyone reading it must understand where you are going and why these are the right things to do to get you there. It also means that it needs to be at a high enough level (3-5 parts) so that everyone can understand the big picture and not drown in the details. Remember that it doesn’t need to include every line of code that is going to be written, only the major parts.

Here are 3 methods to translate your product strategy into action. They will help you keep your roadmap at the right level.

Method 1: Reverse Engineer Your Path

The roadmap always has a timeline. So let’s say you want to create a roadmap for the upcoming 12-18 months (there’s no point in planning for longer periods of time in most cases), the first step is to define your goals for the end of this period. The best way to think about it is to “stand in the future” and report backward. A great way of doing so is using the PRFAQ format that forces you to think of press-worthy statements. What would you tell the press in 18 months? What would they choose to emphasize? What would your customers tell them?

Once you have defined your end goal for 18 months, ask yourself what needs to happen (what will you need to achieve) in the months before that. For example, let’s say that in 18 months you want to demonstrate that you have successfully entered a new market segment, and say that you are in the enterprise software market. This can be translated into specific goals of what success means (for example, at least 10 big companies working with the product on a daily basis). To get there, you need to have more companies starting to work with the product a few months earlier, say 6 months, to give you time to nurture them and get them to embed your product in their daily processes. Not all companies will convert so you must have more than 10 companies, say 15,  starting to use your product 12 months from now. 

What does it take to have 15 companies starting to use your product 12 months from now? It means that 6 months from now the sales team must be able to show at least a demo, but most likely the product would need to be ready for POC. You might want to have design partners as part of the process, so that can be another milestone.

This is a simplistic example, but you can clearly see here the path: first, we will be ready for POC, then we will make the first sales, then we will nurture the customers to make sure they are happy with the product and see a ton of value in it. There are many details missing here, but the big picture is seen clearly and makes sense.

Method 2: Tackle the Highest Risk Early

When you need to embark on a major effort that also entails a lot of unknowns, for example starting a new product or a whole strategic pivot, the uncertainty and the risk are very high. One way to reduce the risk is to tackle the highest risk first so that if you fail, you fail fast.

You should start by identifying where the most risk is. To do so, go back to your product pitch, and start distinguishing facts (things you know are true) from assumptions (things you don’t know or don’t know for sure to be true). Out of the assumptions, highlight the ones that if they turn out to be wrong, your entire strategy collapses. These are your key points, the ones that your entire pitch relies on. They are often related to the problem you are solving for your customers and their incentive to solve it since these are the things you have the least impact on and are much harder to figure out on one hand, and are the foundation of your entire story on the other.

Once you identified these risks, prioritize them and build a validation path to each of them. Your roadmap can then be expressed by the assumptions that you validate, one after the other. It can look something like this: prove that diversity is important enough for organizations to pay money for, prove that they are willing to solve it with technology, prove that they like our approach to the solution.

This method is known as the riskiest assumption test (RAT for short), and it, too, leaves your roadmap coherent and at a high level. Note that this is suitable for new ventures mostly. Once you proved the riskiest assumptions, you will find the other two methods listed here more suitable.

Method 3: Identify Gaps and Close Them

This method is looking at the way ahead of you and identifies the main obstacles you would need to overcome to get to your goal. Ask yourself where are you most struggling today? Which gaps are absolutely critical to close if you ever want to achieve the desired outcome? What is preventing you from getting there? 

This method is often suitable for relatively mature products that want to grow to the next level. For example, you might look at your customer journey and see where you have trouble today. It might reveal things like “we must make the product valuable for using at least on a weekly basis and not sporadically as it is now”. You can look at where your customers are struggling today, and realize your product is not enterprise-ready. If you look at where sales are struggling, you might realize that you need to change your entire business model, or that you must adopt a bottom-up sales approach (or at least address the needs of other personas within your customer companies). 

A roadmap built by gaps is easy to understand: this is where we want to be, this is what’s preventing us to get there, so if we close these gaps and don’t find other ones along the way, we will be able to reach our goal. Note that it is important to make sure that the list is exhaustive since the whole point is that once all of these gaps are closed the goal can be reached.

You can also mix and match these methods, to give you a more holistic view of what needs to be done. Whichever approach you choose, remember that 80% of your roadmap is the background and the alignment on the goals and strategy, 10% is the path (that’s the part listed here), and only 10% is the actual features and timelines. To keep your roadmap understandable at the highest levels, make sure that all the features and timelines appear in context, and refrain from adding all the nitty-gritty details. Sometimes, less is more.