“I asked my team to prepare a roadmap and they simply created a list of all the features and issues they wanted to handle. That’s not what I was looking for!”

That’s what T., the CEO of an AI-based healthcare startup told me last week when he approached me for help.

T. is not alone.

If you were ever asked to prepare a roadmap, felt a little puzzled but did your best, and got unhappy/cold/no response at all, you know what I am talking about.

The problem is that most CEOs don’t know exactly what’s wrong with what you gave them, they just know it’s not what they need. That’s understandable given that most CEOs are not product people. Obviously, in this situation, the CEOs can’t provide guidance as to what a good roadmap looks like and help you get to what they really need.

That’s why I decided to create this 3-part guide on how to write a strategic roadmap. It is meant to help product leaders deliver better roadmaps, and also to help CEOs guide their leaders in the process and manage expectations.

Use this guide as an opportunity to have an open discussion between the CEO and product about what the roadmap really is and what it should include. While these guidelines work for most companies I have seen, you might find out that in your case you need something slightly different. Create the variation that works for you.

What Is a Roadmap

Let’s start by looking at the word roadmap. It is a road-map. A map that is meant to guide you in your journey. In a tech company, it is the map through which you navigate the company to product-market fit or growth (depending on the company stage).

It is so important (and so commonly misunderstood) that I would like to say it very clearly:

A roadmap is a strategic document. It is NOT a work plan. It is a guide, and also a communication and alignment tool.

This guide includes 3 parts:

• Part 1: the components of a good roadmap
• Part 2: the roadmap building process
• Part 3: how to use the roadmap once it’s ready

You are reading part 1 now, parts 2 and 3 will be published in the following weeks.

The Components of a Good Roadmap

Goal

In order to navigate to anywhere, the first question you need to answer is where to. “Where” in the product language means what is it that you are trying to achieve.

Each roadmap needs to have at least one goal. For startups specifically, I recommend no more than one goal at a time. Prioritize your goals before you prioritize your features.

The following questions can help you find your goals:

• Where does the company need to be in terms of business results to be able to raise more money? (or alternatively use a revenue goal you already have)
• What does it take to get there? How many customers, what is the average deal size, what types of customers do you need to go after?
• What is preventing you from getting there today?

Note that customer requests and issues can be included as part of your answer to the last question above, but it is imperative that they are only included within the context of the previous questions. Not every feature request you get belongs in the roadmap.

Goal examples:

• Increase the conversion rates from POC to long term contracts
• Get 5 big logos using and endorsing our solution
• Reduce customer churn
• Address a new customer segment with an existing product
• Increase usage and engagement of an existing product (indicating that the product becomes more valuable for the users)
• Reduce operational costs of the product in order to be able to scale and reduce CAC

And I could go on and on. Note that these examples do not include features, and many of them do not even relate directly to the product. They provide the business context as to why you are doing what you are doing and where you are expecting to be once the roadmap is fully implemented.

Reasoning

As with everything in product management, the next question is “why”.

It needs to be clear why these are the right goals, and that they will really get you to where you want to be.

Your roadmap document should describe and explain that. Note that bullet points are not enough here – you need to elaborate on your logic and line of thought there, so that anyone reading it can agree or disagree, but they know what to address.

Take the opportunity to have the discussion at that level – what are the right goals for the product? More often than not, this opens up a broader discussion regarding business strategy and goals for the entire company.

Don’t be afraid of that discussion. It’s a good one to have. If there is unclarity or disagreement at that level, you better open it and debate it openly now – before you move forward to implementation which might be in the wrong direction.

I can’t stress enough how important this discussion is. No good can come out of ignoring the subject, leaving the questions open or even worse – unasked. As a product leader, steering that discussion is part of your job, even if you don’t have the answers.

Route

Once your destination (AKA goal) is clear and agreed upon, you need to find the right path to get there.

The route includes a set of large milestones with clear logic between them.

For example, if your goal is to improve the conversion rate between POC and long term contracts, you need to understand what are the barriers to get there today.

You can come up with a list like:

• Reduce onboarding and setup time
• Improve system stability
• Include must-have features that your competitors have
• Increase user engagement during the POC

The route needs to make sense when looking at it from the outside, as a whole. It needs to be clear how one step leads to the other, and how eventually you will move from point A (today) to point B (where you want to be).

In the example above the milestones are also listed as goals, and there is little to no dependency between them. But it is clear how each of them is helping to achieve the conversion rate goal.

This can be part of a longer route and a larger goal, which includes something like:

• Fully support the ideal customer and use case (and smooth conversion from POC to long term contracts is an indicator that you are in the right direction)
• Scale that scenario to be able to support many such customers with identical use cases
• Expand to support additional, slightly different use cases and customer profiles
• Go after a new customer segment which is fundamentally different

In this example, obviously, there is a dependency between the larger milestones and their order matters.

When you choose your route, again reasoning is important. Explain why these are the right things to work on, and not others. Add data and evidence to support your claim. Lay down your fundamental assumptions, and see which ones you know are true and which require more validation.

As I said in my article about trial-and-error, the overall route needs to be plausible. It needs to be something that seems possible, at least on paper. Validation can be added along the way, but if it doesn’t make sense on paper, it won’t make sense in reality – no matter what.

If there is more than one goal, show a clear path to each goal. Only once you have a clear path to each (with reasoning and everything else mentioned above), you can combine the paths to an uber-roadmap that sums up what it looks like for the entire company. Don’t mix the routes before you know what each route looks like and you are confident that it makes sense. Doing so will only confuse you and your audience.

ETA

Part of knowing if a certain route is good or not is knowing how long will it take us to get there. If we get to the train station after the train has already left, even though we had the correct route it didn’t help us much.

In the tech world, “trains leaving the station” could be:

• You will not meet your goals for the next funding round and will run out of money
• Your competition will get there first and have a first-mover advantage
• Your pace will be too slow for too long, preventing you from adjusting according to market feedback or making any significant progress
• You will be able to meet only some of the goals, but all of them are must-haves for your success

Note that the ETA doesn’t need to be accurate at the day level. I deliberately used here ETA and not timeline – the E stands for ‘Estimated’. As a rule of thumb, a quarter is enough, and if you go longer than a year forward you can be even less granular. The idea is to help you assess your route and get an order of magnitude of when will you be at each point in time.

Remember that the plan itself will change anyway, so your goal is not 100% accuracy.

Risks and Mitigation

If you want to increase your chance to succeed, think in advance about what can go wrong and prepare for it.

Play devil’s advocate, think about the worst-case scenario and see if you need to change or add anything to the plan in order to make the risk more worth taking.

Do it now, while you still have time and you are not in the middle of the crisis. When the crisis comes, you will be much more prepared and your chance to succeed increases.

Add measurements and checkups that will help you assess the risk and understand how far are you in your route, and how close to the worst-case scenario.

What You Are Not Going to Do

“The best strategy is ‘no’ “

Michael E. Porter

What you are not going to do is as important as what you are going to do. This is your opportunity to say it loud and clear and get everyone’s alignment on it.

If you don’t know what is it that you are not going to do, you are probably not crisp enough on the “yes” part. Look at all the product requests you get and assess them compared to the route that you have chosen. Whatever doesn’t fall into this route should be excluded.

In rare cases, this will lead you to find that your route needs to change, but don’t do it lightheadedly. Remember that you calculated your route looking at the bigger picture and company strategy, and you need to use it to create focus. If you start piling additional features onto it, you will lose the road.

It takes some courage to say ‘no’ to customers’ and executives’ requests. As I said earlier, you should not be afraid to have this discussion. In the worst case, you will say ‘yes’ eventually and get to your starting point. But from my experience, that’s not the common case and this clarity that you create before you start marching will pay itself off very soon.

You should now understand what a roadmap is – I hope you no longer think it is a list of features and dates. Next week I’ll elaborate on the process that you need to follow in order to build it. Stay tuned.