How to create a Real (Strategic) Roadmap — Part 1
If you want to create a real (strategic) roadmap, then you need to understand what roadmapping really is.
TL;DR
Roadmaps, actual strategic roadmaps, when created correctly are an incredibly valuable tool to define direction, create alignment and bring focus within a company. Sadly, most companies and Product teams create artifacts that they call “roadmaps”, but which are really just wishful thinking delivery plans with little connection to overall business objectives and strategy.
Creating strategic roadmaps is neither complex nor time-consuming, but it does require a different way of working than what most companies follow. The change to make is to start with clear objectives (which many companies don’t have), then make strategy choices (also missing in many companies) on how to achieve those objectives. Those choices will define the key actions or activities that will be visible on the roadmap. As I said, not hard, just different. 😃
NOTE: This article turned out to be a fair bit longer than I had first intended. So I decided to break it up into two parts. The second part can be found here: Part 2.
Contents
- Purpose of a Strategic Roadmap
- What a Roadmap is NOT
- The Vision Stack
- What is Strategy?
- Objectives — What Are You Trying To Achieve?
- The Strategy Process That Creates a Roadmap
- Some Additional Info
- A Little Feedback Please
The word roadmap is one of those terms, like (legal) brief, that has a common language definition but also has an industry-specific definition. When used in the legal context, every lawyer knows exactly what a brief is, what it should contain, what it is used for and how to create it. Sadly, that’s not the case with the word roadmap, when used in business, and especially in the Product context.
As can be seen in the chart below, the term “product roadmap” has gained prominence in the last 40 years, with a big increase in its usage in the late 90s and early 2000s and then even more growth from around 2012. This shows a clear correlation between the rise of tech, and especially the Internet and SaaS, and the rise of the usage of the term product roadmap.
The dictionary definition of roadmap is:
roadmap: n. any plan or guide to show how something is arranged or can be accomplished:
e.g. your roadmap to financial independence.
While this is a good common language definition, we (in Product) need to realize that “any plan or guide…” is not at all sufficient for our needs. We need something more specific and targeted. A roadmap is NOT a plan. When thinking about a (Product) Roadmap, we need to be able to easily distinguish it from a (Product) Plan. The two are NOT the same.
In Product — and I’m being specific to our domain here — a Roadmap is a strategy document.
One definition I use is:
“A roadmap is a statement of direction and strategy.”
(as opposed to a plan which is a statement of commitment and delivery.)
Janna Bastow, founder of ProdPad states:
“A roadmap is a prototype of your strategy.”
According to Steve Johnson at Product Growth Leaders:
“Roadmaps are evidence of strategy. Not a list of features”.
And here’s an academic paper on roadmapping from 2021. It describes a roadmap as:
“A map depicts, implying that it is a graphical representation of something. In the case of a roadmap, it graphically displays a firm’s strategy.”
The common element in all of these definitions is STRATEGY. A roadmap is a strategy document. It is NOT a delivery plan.
You can read more details on the the distinction between roadmaps and plans here:
Roadmaps aren’t limited to Product Roadmaps. There can be different types of roadmaps: business roadmaps, technology roadmaps etc. But product roadmaps are the most common ones. I’ll elaborate on business vs. product roadmaps in Part 2.
The key point is that roadmaps are AN OUTPUT of a strategy process, visualized and represented for clarity and communication.
The “roadmap” represents a time-oriented visualization of the key actions, deliverables or goals/outcomes you need to enact your strategy; to achieve your objectives.
Purpose of a (Strategic) Roadmap?
Understanding the purpose of a roadmap is important. What’s the point of creating something if we use it in incorrect ways. What I say in the video below is:
“The biggest benefit and purpose of a roadmap is to identify priorities and direction. So, where you’re going and what’s most important. And the basis for that comes from strategy and objectives…clearly thinking that through and communicating it to others.”
Again, a roadmap is not about delivery and commitment. A well executed roadmap will have a story behind it that you can use to communicate to others. That story is based on the objectives (what you want to achieve) and the strategy (choices on what you will/won’t do) to achieve those objectives.
Objectives/Strategy provide focus and clarity on what is important. If you define clear and meaningful objectives, and discuss and then choose options for how you (as a team/company etc.) can achieve those objectives, you will bring clarity and alignment to your team and the actions that are important. i.e. your priorities.
This process, if adopted, will prevent you from being distracted by shiny objects or ‘strategy of the week’ situations. In short, it’s a rational and effective way of winning in business.
And here’s the podcast/interview I was on — Talking Roadmaps — where I specifically answer this question — What is the purpose of a roadmap? — as well as several other questions. Just press play. It is all cued up to the exact spot.
What a roadmap is NOT
Before I go further, I want to clarify some misconceptions of roadmaps and talk about what is NOT a roadmap.
1. A Roadmap is NOT a list of features to build
This is probably the biggest problem and misconception with most roadmaps. I made this mistake in the past, creating “roadmaps” showing features that would be built. But, as Steve Johnson said “It’s not a list of features.”
Here’s a “roadmap” I created very early in my Product Management career. Over 20 years ago. Yeah…I cringe looking at it today. It’s just a bunch of features to be built. Zero connection to objectives or any strategy, or in fact any reality. It was created in conjunction with the VP of Engineering. I think we got about 20% of it done because it wasn’t scoped and our company priorities changed constantly.
I was watching a presentation recently and the speaker said:
“Here’s our roadmap for the next three sprints.”
No. I shook my head. That’s not a roadmap, that a plan.
Even if the “roadmap” was for the next three months (vs. three sprints), it would probably still have been a plan.
If it wasn’t explicitly created based on clear objectives and strategy choices, then it’s NOT a roadmap.
NOTE: Exceptions are possible. This is not to say that there can never be features on a roadmap. If they are an output of the strategy process, that’s fine. The point is that the roadmap is NOT simply a list of features to be developed.
2. A roadmap is NOT a list of commitments
Another misconception many people have about roadmaps — actual STRATEGIC roadmaps — is that they are a list of commitments. i.e. that items shown “on the roadmap” are strict commitments that will be delivered.
This comes from two directions. The first, from people who create “roadmaps” that are a list of features to be delivered and then presenting them as such. [Like the person mentioned earlier]. The second, is from people who receive roadmap briefings seeing a list of features that (at least by implication) are delivery commitments.
I can’t blame the second group for the misconception, because the first group — Product Management — has laid that expectation in their laps.
If a sales rep showed you their current “sales funnel” and listed close dates for each opportunity, why would you argue with them? But we know that’s not what a funnel is. It’s simply the current state of things and a projection into the future of what MAY happen, based on current knowledge and intentions.
To a certain extent, that’s what a roadmap is. It’s a projection into the future of our intentions based on what we want to achieve (objectives), how we believe we can achieve those objectives (strategy) and what we know today. But, and this is a fact, this will likely change as market/company conditions change, and as we learn more and make decisions about how to respond.
NOTE: Exceptions are possible. This is not to say that there can never be commitments on a roadmap. If they are an output of the strategy process, that’s fine. The point is that the roadmap is NOT simply a list of commitments to be completed.
3. A roadmap is NOT a bucket we fill with work items
This is related to both items above, but also needs a bit of explanation. I’m sure you’ve heard someone say (or perhaps you’ve said this yourself) when discussing a potential product feature or request from an executive or important customer.
“OK. Thanks. We’ll just put it on the roadmap.”
I used to say that as well, way back. It was a convenient way to placate someone of influence who was making a request/demand. This was back when I used to conflate roadmaps and plans; before I understood strategy and how an actual strategic roadmap could be very helpful to my work.
Eg. I once managed a product and localization for Japan was always 3–4 quarters out. It was “on the roadmap” because the Japanese office had asked for it, saying they couldn’t sell the English language product there. To appease them, I told them I would put it “on the roadmap”. But penetrating the Japanese market was never really an objective, so guess what? It never got done, even though it was “on the roadmap”. Other actual objectives always took precedence over Japanese localization.
Given that the roadmap is the OUTPUT of a process, we can’t add things to it (the output) just because someone important asks (or demands it). Sure, we can add that item to our plan — even our “long term plan”, and we can, if needed, show it as a deliverable in a plan slide (assuming we have people and abilities to complete it).
Document the WHY
But we should be clear as to WHY that item is there. Because everything we commit to, everything we decide is important enough to invest other people’s time and effort into — and I’m not just speaking about Engineers here — should be done with a clear understanding of WHY.
Keep in mind that anything built must be marketed, sold, supported etc, so it’s not just Engineers—but everyone downstream who will touch that feature — whose time and efforts are being committed when we commit to building something. The costs add up and we have to understand that and remember that.
That WHY could be objectives and strategy or an external reason not under our control (e.g. regulatory requirements) — i.e. good reasons for WH. But it could also be because a leader said so, or someone else committed to it (without proper consultation) — i.e. not so good reasons for WHY.
Ultimately, regardless of the reason, we should have clarity on WHY something is important and why it is important enough to commit to, vs. not committing to it and doing something else. And we should always remind people of those WHYs, because they (Sales, Execs etc.) will usually forget.
The Vision Stack
I would be remiss if I didn’t show the Vision Stack (quickly) and share how these things — Objectives, Strategy, Roadmap and Plans — all relate. I explain this in more detail in this video, but given I’m referencing them all here, I do want to share the diagram and a quick description of it.
The topline direction for any product is set via the Vision (either formal or informal). To move towards that vision, we define and execute on Objectives that align with that Vision. Objectives that don’t align with the Vision should be avoided.
Strategy is the aligned set of choices we make to achieve those Objectves. The key action items coming out of those choices become elements of Roadmaps, and those are further refined and augmented into shorter term Plans.
The flow from top to bottom is structured and clear, IF teams understand and follow through on this process. One challenging area for many companies is the connection between Business Vision/Objectives/Strategy and Product Vision/Objectives/Strategy. The most important connection to make, and where companies fail the most, is between Business and Product Objectives.
If followed, this cascade, from Vision/Objectives down to Roadmap and then Plans, brings clarity and alignment within teams and organizations. It explicitly defines what is important and where focus should be. Each layer feeds into the one below it, thus Product Roadmap items/actions feed into Product Plans, contributing to keeping that work focused and align with Objectives and Vision.
NOTE: If you would like help with this process to define any of these and bring more clarity and alignment with your org or leadership team, please contact me. This is an area of focus for my consulting work.
What is Strategy?
Strategy is another word that needs some definition, as different people will think of and understand it in wildly different ways. The dictionary definition of strategy is:
strategy: n. a plan of action or policy designed to achieve a major or overall aim.
Now this an acceptable definition (I like the word policy and the implication to achieve a goal/aim), but the use of the word plan is problematic for me, as we need to make a clear distinction between strategy and plan.
I like Roger Martin’s language around strategy. It’s easy to understand and make a clear distinction between strategy and plans. Martin describes strategy as (I’m paraphrasing just a little bit for clarity):
strategy: n. an integrated set of choices that work together and reinforce each other. The result positions the organization on a playing field in the best way possible.
The key words here are integrated choices, reinforce, and positions.
Integrated choices — both words are critical. Strategy is choice. We choose what to do, and thus what not do. We chose where to focus, and thus where not to focus. We can’t do everything for everyone. If you’re not making a choice, it’s not a strategy. And those choices are “integrated”. i.e. They’re not random and disjoint. They align and support each other.
Reinforce — those (integrated) choices must work together and reinforce each other. They must have some coherence to them. They can’t just be a set of disconnect choices.
Positions — The integrated choices place the company (or product) in a position to win. It doesn’t automatically mean the company/product will win, but the set of choices have been thought through and increase the probability the company will succeed, as compared to other choices they might have made.
So, choices are critical. But many companies and leaders don’t want to make these choices. Often, they (falsely) believe it might constrain or restrict them in the future. But unless you make those choices, you likely end up doing a bit of everything, which is never a great idea.
If you want to dig a bit deeper into strategy, see this article:
Additionally watch this video by Roger Martin where he distinguishes a strategy from a plan.
A Little Aside
You may have heard this joke or a version of it:
A group of Product Managers are at a conference. The speaker asks the audience to name a movie that describes their company strategy.
One person speaks up and says “Our company strategy is Mission Impossible.” A round of laughter fills the room.
Another person speaks up and says, “Our company strategy is Gone in 60 Seconds.” More laughter.
A third person speaks up and says “Our company strategy is Everything, Everywhere All At Once.” A round of loud applause breaks out as most of the audience agrees and sees the same in their company.
Objectives — What Are You Trying To Achieve?
The integrated choices you make, have a purpose behind them— they don’t exist in isolation. You make them to achieve an objective of some kind. Roger Martin uses the term winning aspiration. At first, I was uncomfortable with this term. It seemed contrived, but I guess he chose it to explicitly avoid already common words like objectives, goals etc. Here’s how Martin explains it (paraphrased slightly):
‘I use aspiration because I like the word: “a strong desire to achieve something high or great” according to Merriam Webster, or “steadfast desire or longing for something above one” according to the Oxford English Dictionary. That is the meaning I want: strong desire combined with high goal.’ — Roger Martin
Regardless of the language — Objective, Winning Aspiration etc. — you need to start with what you want to achieve and have clarity and alignment on it.
I’m going to use the word Objective going forward, as it’s simple, most people are familiar with it, AND I’ve already used it in the Vision Stack. 😃
There is a clear connection between Objectives — Strategy — Roadmap, and therefore talking about a roadmap without talking about Objectives and Strategy is pointless.
You can’t create a (strategic) roadmap out of thin air. It’s not simply what you’re going to work on. That’s a plan at best, wishful thinking at worst.
I use the following definition for Objectives:
Objective: n, a specific, measurable, time-bound target or aspiration you wish to achieve.
In my view, good objectives must have (at minimum) three attributes. They must be:
- Specific (S)
- Measurable (M)
- Time-bound (T)
NOTE: These are the S,M,T portions of the SMART metrics framework. The other two — Realistic and Achievable — are important, but not as important as the other three, so I exclude them in this context.
So something like: “Reduce average activation time (i.e. time from signup to realizing core product value) from three weeks to two weeks” sounds good, but it is missing one of the key factors. It’s missing the time-bound part.
i.e. by when do you want to reduce the activation time to two weeks? In one month? In three months? In six months?
The answer matters. If the target is to do it in one month (for all new customers), that would require a very different set of choices than if the target is six months.
It’s critical to have well-defined objectives. Even if you’re working on a hypothesis — i.e we don’t know if we can reduce activation from three weeks to two weeks, and if we can, we don’t know how long it will take — having clarity on what you are trying to achieve and by when— gives you and your team focus and will drive behaviour.
e.g. if you have 6 months, you may decide to spend time doing experiments and testing different approaches before committing to a strategy. If you only have one month to do it, you might just have to make some quick choices and implement them and hope for the best.
The Strategy Process That Creates a Roadmap
Now that we’re clear 😃 on Objectives and Strategy, let’s dig into the strategy process further.
A strategy process — a means of defining the choices that will best position us to achieve objectives — must start with an objective: What do we want to achieve?
The process — simplified a bit for this blog post — is as follows:
- Define a clear SMT objective you want to achieve for your business or product.
- Understand the market or customer context/situation related to this objective.
- Identify a variety of different options you might pursue that would help you achieve that objective.
- Use questions such as “What Do We Know” (WDWK), “What Would Have To Be True?” (WWHTBT) and “How Might We?” (HMW) to get to those actions*.
- For each of those actions, identify any implicit assumptions that could prevent you from succeeding in them or reducing your chances of success.
- Test those assumptions (experiments, additional research, smaller initiatives to learn from etc.) to increase confidence in achieving them.
- Based on this knowledge, make your choices on which approaches/actions you will take to achieve your objectives.
- Sequence those actions over time (in rough time buckets, not dates) based on when you need to achieve that objective.
- Repeat this process for any other objectives you have.
Once you’ve done this for all your objectives (there should only be a few), you’ll have your first cut at your strategic roadmap.
* NOTE: For more information on the WDWK, WWHTBT and HMW questions, see the section Use Objectives to Imagine the Future in this article.
In Part 2…
That’s the end of Part 1. In Part 2, I’ll dig into the following:
- A working example of creating a strategic roadmap
- Business roadmaps vs. product roadmaps
- How roadmaps contribute to plans
- Ways to visualize roadmaps
- Additional thoughts and comments.
Some Additional Information
I want to share two things that provide additional information on this topic.
First, is this great video with andrea saez. Andrea creates excellent Product content. In the video below, she gives some great advice on roadmaps. I highly recommend it.
Also, here’s the Linkedin post I made on this very topic. There are over 200 comments with lots of questions and discussion. Lots of good info and elucidation on roadmaps and strategy.
A Little Feedback Please
If you’ve read this far, thank you. I’d like some feedback on the article to make it better. It should take just 1 minute, but will really be valuable to me. Thanks in advance.
===> Click Here <===
