Product Roadmap Hierarchies: Why Speaking the Same Language Matters
This article first appeared in Medium.
We’ve all been there, right? You’re in a meeting, talking with execs and other leaders, and everyone uses the same jargon and terminology. The meeting progresses. Heads nod. Everyone seems excited and on the same page. Still, you have this sense that the words tossed around don’t mean what the speaker thinks they mean. The famous quote from Inigo Montoya from the classic movie Princess Bride often comes to mind. While, at best, this can be amusing (in a sardonic humor sort of way), at worst, it will create confusion, false expectations, and generally slow progress.
I’ve seen this play out specifically as it relates to a product strategy and product roadmaps. And while this issue can happen at any company of any size, I think it is most common (and destructive) at mid to large size companies. The maddening part is the insidious nature of how this can all play out; the confusion is at first subtle, the expectations begin as reasonable. Everyone walks out of the strategy planning session feeling good. But then the slow swirl begins, and — at the risk of sounding overly dramatic — you need to get in front of it before it becomes a full-on F5 tornado and destroys the path in front of you.
So, how do you avoid the insidious misinterpretation of language regarding your product strategy and roadmap? You need to establish a product strategy structure and define a product roadmap hierarchy that everyone understands and buys into. Reiterating the company strategy, establishing the roadmap hierarchy, and clearly defining the different levels are some of the initial foundational exercises you must complete to develop an effective product operations model.
You have one of two places to start, depending on where you are in the year. You can either begin by establishing the structure of the product strategy or by defining the product roadmap hierarchy. Ideally, you would start with the strategy framework, but nothing will fall apart if you start with the elements of the roadmap. They are distinct — but connected — components.
Establishing Your Product Strategy Framework
You can hardly walk through the product management “business help” landscape without tripping over a book, LinkedIn post, or — ahem — blog article on the topic of product strategy. My point is that plenty of resources (and POVs) can be a good starting point for your company. I’ll cover just a few, but by no means is this meant to be either exhaustive or a statement that these are the only ones you should look at.
Melissa Perri wrote about a Strategy Framework in her well-known book Escaping the Build Trap. I particularly liked the simplicity of the strategic intent as a company’s “current area of focus.” The general structure of a product strategy as described in Escaping the Build Trap:
The strategic intent should establish the decision-making framework for roadmap development and prioritization. If helpful, you could also loosely think of a strategic intent as a 3–5-year OKR. Generic examples of a strategic intent and goal:
Expand our e-commerce business: Increase revenue from our e-commerce business by $30 million in 5 years.
Achieve operating efficiencies: Decrease operating costs by 20% in 3 years.
Double revenue growth in our B2B market: Increase revenue growth from 10% to 20% YoY.
Perri’s book suggested that a large company should have no more than three strategic intents at one time, and a small to mid-size company may only have one. I agree with this approach — less is more. Also, your strategic intents should evolve as you achieve them, and you should periodically focus on a new challenge to achieve your company’s vision. As such, companies should revisit strategic intents yearly but plan to update/replace them with a new strategic intent every 1–3 years, assuming you are progressing towards your goal.
Your product initiatives should be the “how” for achieving the strategic intent. In my experience, initiatives typically have a 12-36-month horizon. Some initiatives can certainly be completed in less time. Still, these are often broad problems to solve with a series of capabilities and features needed to achieve the initiative's goals. Initiatives could also be the “zoomed out” view of your roadmap if you needed to share the highest level view of where the product is going over a multiple-year horizon.
Capabilities, then, are the “bottom brick” of the product strategy framework. In Perri’s book, she calls these “options,” meaning options the product team can explore (i.e., do discovery on) to find out how best to solve the problems defined in the initiative. Calling these capabilities is more intuitive to me, but essentially getting at the same thing. Capabilities are, of course, made up of features, which is often how a roadmap gets represented. For many stakeholders, though, a capability is the right level of detail without getting too deep into the weeds.
For fun, another similar product strategy framework I’ve come across that I like for its simplicity is the “product strategy stack” concept, albeit there are more layers to this one than the one I highlighted above. A product strategy stack is another way to structure — or template — a product strategy, starting with the company-level Mission and Strategy. You will see this as some variation of
Mission: Why does the company exist? What is the contribution the company is making to its customers, its community, and the world?
Vision: Defines where the company wants to be in 3–5 years and what value it will deliver to its customers in the context of the company mission. (You can combine mission and vision into one statement).
Company Strategy: The plan for how to bring the vision to life.
Product Strategy: is the plan for how a specific product (or product line) will help drive the company’s strategy.
Product Roadmap: The sequence (and often timing) of when initiatives, capabilities, and/or features will be implemented in support of the product strategy.
Product Goals: The measurable outcomes of the product roadmap — similar to key results in the OKR framework.
The product strategy stack implies a double-click in a few of these layers, so there is additional info to unpack. For example, the company strategy could include different elements about the core values, target market, goals, and objectives. At the same time, the product roadmap can consist of various levels, such as initiatives, capabilities, and features.
Understanding the company mission and vision is the foundation for either approach. Depending on the size of your company, there may also be a product-level mission and vision. Either way, you want to capture that and include it in your strategy documents and artifacts to give your teams visibility to the bigger picture. Sometimes, using a version of a business or product strategy canvas-style template can be an efficient way to create a condensed artifact to use as a resource. However, I always modify the template, and you should feel empowered to do so if you decide to adopt one of the dozens of canvas templates out there.
Defining Your Product Roadmap Hierarchy
Now that your product strategy framework is in place do not overlook the simple act of defining the different levels of your roadmap. I touched upon some of this above. Like the product strategy frameworks, you can define this in multiple ways. So, in terms of the elements that make up your roadmap, this is one common hierarchy which is actually a sub-set of the product strategy structure from above.
Initiative: This is the high-level strategic goal or opportunity. Initiatives are the bridge between product strategy and the product roadmap.
Capability: Broad areas of functionality that a product needs to enable standalone elements of a customer experience or journey (ex: self-service account management, in-app chat support, etc.).
Feature: Specific functionality that a capability needs to deliver a complete experience.
You can also insert “product” as a level here; I would insert it below the initiative level, but I’ve also seen it listed above initiative in the hierarchy. Additionally, you will frequently see “epic” inserted above — or in place of — a capability or a feature. As I’ve said, there are several ways to construct the roadmap hierarchy. Use the one that works best for your company’s context. My only advice is to limit the levels to limit unnecessary complexity.
Using the example above, your product strategy and roadmap framework would look like this, along with broad time horizons for each layer.
In this situation, the strategic intent acts as an actionable summary of the company and product strategy. There should be a cadence for reviewing these elements aligning with the broad timeline horizons. Each element should also have a metric, key result or KPI associated with it so that you can evaluate your progress objectively.
The Path Forward
To reiterate, the goal here is really to get everyone in your company — at all levels — on the same page so everyone understands
The company vision and strategy that is the foundation of everything;
The product strategy and how that enables the company vision;
How the roadmap hierarchy is structured and supports the execution of the product strategy.
As I said at the beginning of the article, some of this is just basic alignment. But remember, understanding these basics will help your product teams communicate with stakeholders more effectively and help prioritization run more efficiently. Like a freshly paved road, your product strategy and roadmap will be an enabler that will smooth a more direct path to your vision. By removing the confusion caused by inconsistent definitions and differing interpretations of your strategy framework, you’ll avoid the potholes of confusion that can throw you off, slow you down, and damage your product vision.
A consistent product roadmap hierarchy with a clearly defined strategy is more than a tool — it’s the language your teams need to stay aligned, efficient, and focused. There is no one right way to do this (though I would argue that there are better ways!). The most important thing is that you put this foundation in place so that your product strategy — and operations — can become an enabler and not an obstacle in your pursuit of your company’s mission and vision.
