Product Roadmaps vs. Product Plans
Roadmaps and Plans are very different artifacts with different purposes, and it is important to understand those differences and leverage them.
TL;DR
Roadmaps are NOT Plans. They are not a finite set of things you will explicitly do. Roadmaps are the outputs of a Strategy process. It’s important to understand the distinction between Roadmaps and Plans, how they are defined and how they are used to maximize company focus and drive business and product outcomes.
Let’s stop conflating the two. Roadmaps and especially Roadmapping are powerful tools when wielded correctly, yet far too many companies unnecessarily struggle with alignment and focus by using these tools poorly.
Bonus Content: I recorded an episode on the Talking Roadmaps podcast where we discuss Roadmaps vs. Plans. Have a listen.
https://www.talkingroadmaps.com/blog/if-it-looks-like-a-gantt-chart-its-probably-not-a-roadmap
Contents
- A Little Linkedin Post
- What is a (Delivery) Plan?
- What is a Roadmap?
- Plans vs. Roadmaps
- Moving from Objectives to Strategy to Roadmap
- Visualizing a Roadmap
- Conclusion
A Little LinkedIn Post
I recently posted something on Linkedin clarifying a common misconception about roadmaps. It kind of blew up with over 300,000 views, almost 2400 reactions and a great discussion in the comments.
It says:
Repeat after me:
A ROADMAP is a STRATEGY document. (3 times)
A ROADMAP is not a DELIVERY document (3 times)
Thank you for coming to my TED talk.
Click the link below to see the original post, read the comments etc. on Linkedin.
Several of the questions in the comments were regarding:
- a clarification about roadmaps vs. plans
- why a roadmap can’t also be a delivery document
- what a strategy document is etc.
So here’s my more detailed take on it.
The first issue to overcome is clarity on definitions. The language we use in business, and especially in Product, is often ambiguous or even incorrect. We need to have clarity on our terminology and be clear and intentional in the words we use. It’s a problem we should work actively to solve. If you want to dig in on language clarity, I’ve written about that topic in the article below.
What is a (Delivery) Plan?
A “Delivery document” is a Plan. The word “Plan” has multiple meanings (of course), but the one that applies best in this context is:
plan. n. a detailed proposal for doing or achieving something.
Note the word “detailed”. When we think of a release plan or a development plan, it means something that is the result of a planning process; a process that:
- defined specific requirements and/or objectives
- scoped work and individual tasks
- attempted to identify potential challenges
- estimated effort and available resources to complete required tasks
- sequenced/prioritized those tasks to address dependencies etc.
The output of that planning process often (but not always) looks like a Gantt chart, broken down by task, often showing who will work on tasks, when each task is expected to start and end, any dependencies across tasks etc. i.e. something like this:
The people who need to see THIS plan are the people involved in the work or overseeing the work. This typically includes Engineering, Product Management, Design, Project Management (if you have that) and anyone else in related roles.
Even if you don’t get this granular in your plans, the key point is that work items have be scoped out with high confidence, and target delivery or execution dates must be determined and communicated.
Note the bolded terms: work items, scoped out, high confidence, target delivery or execution dates. These are all important aspects of a PLAN.
Organizations like Sales, Marketing etc. don’t really need to know all the details of the work, but definitely want to understand the outputs — i.e. what will be delivered and when. That information can be extracted from the plan and presented in a much more digestible and meaningful way for them.
The format of that “more digestible” information depends on the frequency of delivery and the questions those teams need answered. One format (and definitely NOT the only format) is a simple timeline of deliverables. e.g. something like:
Note that in this diagram, nearer term items —in March, April, May — have some target dates associated with them, whereas June-August don’t. That’s because you may have more clarity and confidence on those nearer term deliverables as they are likely in progress, whereas those in June-August still have a bit of uncertainty in their implementation.
But all of this represents work in progress or committed work, though the work in the latter months of the plan may change if priorities change.
The idea here is that this PLAN has been agreed upon, prioritized and scoped to minimize the risk. It is relatively short term in timeframe as well.
What is a Roadmap?
Now that we have clarity on a Plan, let’s talk about Roadmaps. This one is a bit tougher because the word roadmap is used in multiple contexts and even the business/product definitions of it can be blurry.
To remove as much bias as possible from the definition, I decided to consult the all-knowing ChatGPT to give me a definition of a Product Roadmap. Here is the response.
A product roadmap is a strategic plan that outlines the high-level goals and objectives of a product or product line over a specific period of time. It serves as a visual communication tool that helps teams to align their efforts and coordinate their work towards a shared vision for the product. — Source: ChatGPT
Now, I’m glad that ChatGPT didn’t hallucinate and give a wrong answer. The fact that the word “strategic” is in there, along with “high-level goals and objectives” is what is most important.
Some may quibble over the term “strategic plan”, but the point is that a roadmap is about strategy/objectives and that’s what I’m going to dig into here, as that was the core message in my LinkedIn post.
BTW, If you want to more background on Roadmaps, read the following Twitter thread or the associated academic paper. The paper helps clarify key points about roadmaps, their implementation and use.
Here’s a link to the paper itself:
Getting back to the topic at hand, I use the following diagram to discuss Objectives, Strategy, Roadmaps etc. and show how they are related.
I won’t explain everything in the the Vision Stack — that’s fodder for another blog post — but the key point is that roadmaps are the OUTPUT of a strategy and roadmapping process and help tie together Vision, Objectives etc.
Roadmaps don’t exist in and aren’t created in a vacuum. They’re not a bucket or container for work. And we simply don’t “put things on the roadmap”.
Moving from Objectives to Strategy to Roadmap
This section is intentionally brief, as it is a big topic, but I want to explain it so that it is clear how the roadmap items are defined. i.e. how they are the output of a process.
NOTE: I give a full-day workshop on Objectives and Strategy to Product Teams. If you’d like more information on that workshop, please contact me.
Objectives can be business objectives (grow revenue, expand business footprint in Mexico etc.) or product objectives (increase onboarding effectiveness, localize product to specific locale etc.). In most cases, Product objectives should align with and support specific business objectives.
Objectives should be Specific, Measurable and Timebound.
NOTE: these are the S, M and T from SMART Metrics. I don’t focus on the A (Achievable) and R (Realistic) as I find SMT to be sufficient when working with teams.
Specific should be self-explanatory. We don’t want generic objectives like “Improve our market share”.
Measurable means quantitatively measurable. “We want to expand our business footprint in Mexico” is NOT measurable. “We want to increase our revenue in Mexico by 35%” is measurable.
Time-bound is critical. It defines (by) WHEN you want to achieve the objective. “We want to increase our revenue in Mexico by 35% in CY (Calendar Year) 2024” is time-bound.
Time-bound objectives are important. They define a time target, and by inference (or sometimes explicitly) a starting time for when activities must occur.
So our objective is: Increase our revenue in Mexico by 35% in CY 2024
Note that you need all three — Specific, Measurable and Timebound. Remove any one of them, and the objective becomes vague and rather useless. e.g. removing Measurable — Increase our revenue in Mexico in CY 2024 — is just a generic statement.
Decomposing the Objective
Without getting too detailed, let’s assume the company has an existing sales partner in Mexico. The partner has been somewhat active, but it’s clear to the company that the partner cannot simply increase their results by 35% on their own.
Thus, in order to achieve the objectives, the company, which sees Mexico as an important market, is going to set up a direct sales office in Mexico and collaborate with the partner to extend reach and penetration into accounts.
Additionally, given analysis done by the partner, onboarding customers to the software is very time consuming for the partner. Thus the company is going to add better onboarding capabilities and content to the product.
Finally, to address pressure from a competitor also selling in Mexico, the company is going to launch an extended marketing effort to raise awareness of their product in key Mexican market segments.
Thus we have:
- an SMT Objective to grow revenue 35% in Mexico by end of 2024.
- a direct sales and partner engagement Strategy.
- a number of Tactics that cover product enhancements, sales hiring in Mexico, and improved marketing efforts.
All of these tactics must be worked on in 2023 and be ready for launch by early 2024 to achieve the objective by end of 2024. Can you see the roadmap forming?
Some of these are Product items — new onboarding content — and some are business items — opening a sales office, hiring, new marketing efforts etc.
The details of all of these have not been worked out — a plan or plans need to be created, scoped etc — but the big ticket items are clear and can be decomposed and laid out in a [strategic] roadmap.
The company may have several objectives — i.e. beyond just growth in Mexico. Each of those Objectives should be decomposed into Strategies and Tactics and the combined Tactics (that would include both Business and Product activities) would form a roadmap for the company. The Product parts could (would likely) be published as a Product Roadmap, but the connections back up to Objectives and other related activities should not be lost.
Visualizing a Roadmap
As for a visual representation, roadmaps are often presented as a series of (expected) deliverables or actions, bucketed into broad timeframes like quarters or half-years. The following is a format I use and recommend.
It shows a series of themes down the side and timeframes across the top, with specific roadmap items in the main body.
Most roadmaps don’t explicitly show uncertainty, risk, assumptions or strategy in their visual representation. This information is shared verbally or via other supporting slides or documents. It’s important to understand that the visual — which can be in many forms — is just one part of the overall roadmap. The context and details are often more important than the visual, and should be presented and explained in any roadmap discussions.
Plans vs. Roadmaps
The following table compares and contrasts Plans and Roadmaps. This should help you distinguish them.
Timing
The timescale of roadmaps is multiple quarters or years (tied to timeframes of associated objectives, strategies etc), vs. the timing for most software delivery plans which is on the order of weeks or months. Of course, in some cases there could be longer term plans, but in those cases, the strategies and roadmaps would be even longer as well.
Focus
By definition, the focus of a roadmap is direction and strategy, meaning that it conveys where you are headed and at a high level (via the strategies driving it) how. A plan, that is the result of analysis, work decomposition, scoping etc. is focused on commitment and delivery; i.e. describing a confident path to delivering what is needed.
Inputs
Planning processes and Roadmapping processes have different inputs. A roadmapping process takes overall business and product objectives as inputs, along with defined strategies and associated tactics to achieve those objectives. Planning process take requirements, tasks, priorities, available resources, and other constraints as inputs and workout an efficient way to deliver what is needed. The difference in the inputs and obviously difference in the outputs of Plans and Roadmaps are stark.
Accountable
In most companies, Product Management is accountable for the Product Roadmap, working with leadership to define objectives and strategies, incorporating input from Sales, Marketing, Services, Engineering etc.
Likewise, in most companies, Engineering is accountable for the development Plan as they have the headcount and technical expertise to do the needed analysis, scoping etc. They don’t work in a silo though. They work with Product Management and groups like UX/Design to scope and sequence the necessary work.
Budgeting/Cost
Budgeting and costs are not explicitly part of most roadmaps. There may be some investigation into potential costs of some initiatives, if there is some potentially large capital outlay — e.g. hardware, manufacturing, acquisition etc — but detailed costs are not normally considered when creating a roadmap.
In contrast, when making a plan — an execution or delivery plan — then costs are explicitly part of the calculation; whether in terms of team costs, size, allocation etc. This may not always be explicit — i.e. looking at salaries, expenses etc. — but there will be costs on some level factored into the plan.
Risk
A roadmap will contain items of varying risk levels. Typically those further out in time have higher risk/uncertainty associated with them than nearer term items, but that is not always the case. Items that are not under internal control — e.g. an OEM of 3rd party technology or a new product capability where discovery and analysis are required, may also be deemed high(er) risk, and work will need to be done to uncover hidden assumptions or answer important questions to reduce the risk associated with them.
When planning happens, an explicit part of that activity is de-risking activities. We can’t eliminate risk, but we can reduce it in areas that are under our control. Thus, while a Roadmap will contain items of low, medium and high risk, a plan typically only contains low and some medium risk items.
Working with Roadmaps and Plans
So the question arises, if Roadmaps and Plans are distinct (but related), how should teams and companies work with them to maximize their benefits?
This is a great question (if I do say so myself 😀). This is an area where a lot of companies make missteps and end up conflating the two. Let’s take a step back.
Product Roadmaps are outputs from a strategy process. i.e. they contain important action items that must be met to achieve key objectives. Companies want to maintain focus on these above all else. i.e. not get distracted by shiny objects, short term opportunities or other diversions.
Product Plans are the basis for development and execution on near term product priorities. These will include required roadmap items, but will also include other (possibly tactical) activities such as bug fixes, smaller functional enhancements, customer commitments, technical rework etc. i.e. there are many things that aren’t coming from the roadmap that must also be completed as a normal course of business.
I use the following diagram to illustrate how Roadmaps and Plans should be used together.
Whether you create releases with significant functionality or release continuously, the point is that the focus should be on the roadmap items, as they align with your key objectives and vision, and other tactical work, while addressed, doesn’t take focus away from that work.
So the Roadmap feeds into the Plan in an ongoing pattern driving overall alignment and focus.
Conclusion
Roadmaps and Plans are different beasts. They contain different information, serve different purposes and address different needs. They are complementary though, and when used appropriately, drive alignment, focus and efficiency.
So let’s keep the distinction clear, and benefit from tools that help us connect objectives and strategy with activities and actions. Because, quite honestly, that connection is often the missing piece between successful companies, and also-rans.
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 <===
