Product Vision, Strategy, Roadmap
We keep using these words, but what do they mean?
Product organizations often discuss needing a (new) product vision or strategy, or will talk about what is on their roadmap. However, what is sometimes lost in these discussions is the unfortunate fact that none of these terms have clear definitions, and in fact some people call different concepts by the same names and the same concepts by different names. So in order to help clear up some of the confusion, I collected some definitions and references and will attempt to put them together in a bit of a coherent framework.
Almost everyone who talks about these concepts includes a hierarchy like this — let’s call it the product strategy pyramid:
However, what the content of the different levels of the hierarchy is varies by who you talk to. Let’s break them down one by one.
Vision
Company Vision and Mission
To understand what a product vision can be defined as, we actually have to start at the company vision and mission, since product vision and strategy should ladder up to the company mission/vision. In contrast to the term “product vision”, these are somewhat more well defined. Here is a concise definition from management consultancy Bain & Co.:
A Mission Statement defines the company’s business, its objectives and its approach to reach those objectives. A Vision Statement describes the desired future position of the company. Elements of Mission and Vision Statements are often combined to provide a statement of the company’s purposes, goals and values. However, sometimes the two terms are used interchangeably.
What is important about the company mission/vision is that it is relatively stable — it should be broad / ambitious enough that it can remain constant for many years.
Most tech companies have a mission and/or vision statement. Perhaps the best known is Google’s mission “to organize the world’s information and make it universally accessible and useful”.
Product Vision
The product vision should act as a “north star” for all product development. Sitting at the tip, it should be the most succinct and most stable element of the product strategy pyramid. However, what exactly it should look like isn’t exactly well-defined.
Some, like Richard Banfield, Martin Eriksson and Nate Walkingshaw in their book “Product Leadership” describe that a product vision should be equal to the company vision (/mission), or at least at the same level:
The company vision is unlikely to change much. Pivoting a company or product doesn’t necessarily mean changing the vision. If described correctly, a vision will be timeless and not connected to technology or trends.
Product management coach Roman Pichler argues that a vision should not be too constraining in terms of the how, but rather just answer the following questions:
What is your purpose for creating the product?
What positive change should it bring about?
An example of a product vision conforming to this very high-level definition is the product vision for Yammer, Microsoft’s enterprise social network: “Empower and connect every person across an organization to maximize their impact”. This reads like a company mission statement (notably, one different to the overall Microsoft mission statement “to empower every person and every organization on the planet to achieve more”), and if Yammer was (still) an independent company, it might actually be. What’s worth noting is that this kind of product vision talks about the outcomes only, not how they are achieved — you could build a product that’s not an enterprise social network and still have the same vision; you could even make a non-digital product with the same vision (organize employee discussion groups, perhaps).
The second, slightly more specific kind of vision is exemplified by product roadmapping software Aha. Their definition of a product vision sounds similar enough to the one above:
A product vision represents the core essence of its product or product line. It also sets the direction for where a product is headed, or the end state for what a product will deliver in the future.
However, the example given is actually quite different: “For Fredwin Cycling, the vision is to be the #1 social fitness cycling application on the market.” Two notable differences to the high-level kind of vision: firstly, this vision is specific about what the company is building (a “social fitness cycling application”). Secondly, this vision can actually be achieved. In contrast to the Yammer example above, in which people could always become even more connected (unless mankind ever evolves to form a Borg-like collective), being the #1 social fitness cycling application is an attainable goal (there are only a fixed number of these apps, and once you define what being #1 means, such as highest revenue, largest user base etc., you’ve got a goal post you can hit).
The last definition that is mentioned frequently (e.g. here, here, here) is some version of the following template:
For (the target customers)
Who (have a certain need),
Our product is a (product category)
That provides (compelling reason to buy).
Unlike (the product alternative),
Our product (has these key differentiators).
This template is originally from “Crossing the Chasm” by Geoffrey Moore. It is worth noting, however, that its stated purpose in that book is not a vision (which should be future oriented), but rather a positioning statement, which is a marketing/selling tool describing the current offering (and actually intentionally narrowing down the description to just one use case). Therefore, when using this template, one has to be careful to not just describe the status quo but actually make it something worth striving for.
The two interesting points about this template are that it focuses on a customer need to be solved, and that it forces one to think about differentiation / competitive position. Whether the latter belongs in the vision or should be pushed down to the level of strategy is up to debate.
Product Strategy
In contrast to the vision, which should have a lifetime of many years, a product strategy is typically seen to look at a horizon of months to a few years.
Given the differences in how the (product) vision is defined, it’s not surprising that there’s no consistent definition for how a product strategy looks either. There are two types of definitions of product strategy I found: a high-level version and a goal-oriented version. I will go into detail for both of them.
High-level definition of product strategy
This definition pulled together by the team of product management podcast “This is Product Management” is one of the more high-level ones, which could stay stable for years (notably, it has quite a bit of overlap with the most detailed “vision” template above):
The product strategy describes who your customers are, how your product fits into the current market, and how it will achieve business goals.
In a very similar vein, Roman Pichler defines product strategy as follows:
(…) the product strategy should describe who the product is for and why people would want to buy and to use it; what the product is and why it stands out; and what the business goals are and why it is worthwhile for your company to invest in it (…)
Especially if the vision is open-ended in terms of how it can be achieved, this kind of product strategy puts “meat to the bone” in terms of how the product will deliver on the vision, but also how it will be successful both versus the competition and as a business.
However, this definition of strategy isn’t immediately actionable: While it might help with prioritizing ideas for “strategic fit”, it doesn’t directly help spark those ideas.
Goal-oriented definition of product strategy
The second kind of definition of product strategy is a more actionable one. As one example, in “Product Leadership”, Banfield/Eriksson/Walkingshaw define product strategy as a set of goals to be reached over the next year:
The vision gives rise to specific product goals. These product goals could be things that must be accomplished over the next year — for example, growing revenue, reducing churn, and improving customer satisfaction — or they might be more strategic product goals.
Melissa Perri, CEO of Produx Labs and Product Institute, writes:
Product Strategy is a system of achievable goals and visions that work together to align the team around desirable outcomes for both the business and your customers.
In an example she walks through for Uber, it becomes evident that her understanding of strategy is a longer-term (1+ year) goal along the lines of “Decrease wait times in cities where it is over 10 minutes to less than 5 minutes by January 30, 2018" along with supporting shorter-term (a few months) goals like “onboard at least one driver for every 50 people in each city by January 30, 2017".
In contrast to the previous definition of product strategy, this one is extremely actionable: in the Uber example, one can immediately start brainstorming how one might increase the number of drivers that are onboarded.
The approach has two major shortcomings though: Firstly, the link to the vision is relatively weak. Making a jump from the level of “make the world a better place” to “increase metric X” requires a lot of analyzing the current strength and weaknesses of the product and its position in the marketplace, and based on that prioritizing what metric is the most important to move right now. Arguably, that discussion itself is as important as the goal that results from it, and therefore should be part of the strategy.
Secondly, especially with a singular goal as a strategy, chances are that not all work that you have to do over the lifetime of the strategy will contribute to that goal. In the Uber example above, it’s unlikely that the entire product org would have been focused on improving driver onboarding. Having a more high-level strategy can serve better as an umbrella for all work that is going on in the product organization.
Product Roadmap
While “roadmap” is the concept that at its surface seems clearest, it is actually also ambiguous.
The “This is Product Management” definition of the product roadmap is maybe the one that most people would give intuitively:
The product roadmap describes what products and features will be built to realize the strategy and vision, who is responsible for building those product features, and, sometimes, an estimate of when those products and features will be released.
So the question here is only if the roadmap includes dates or not, right? Not so fast. The biggest problem with this definition is of course that in a lean/agile world, we might not know yet what “features” we will build to achieve the goals we have. We know what problems we will work on, but the solution will be found through an ongoing process of discovery and iteration. This is certainly true for everything that’s further than a few weeks out (of course, we know the features we are working on right now, but if that’s all that’s on our roadmap, then the roadmap will be very empty).
Accordingly, the definition given by Banfield/Eriksson/Walkingshaw in “Product Leadership” is to focus not on features but rather problems:
Because it’s a strategic document, what you want to convey in your roadmap is not a series of features or solutions but themes around the customer problems you intend to focus on and why.
Janna Bastow, founder of ProdPad, agrees:
Theme-based roadmaps start with a problem statement and move towards a solution, rather than start with features and struggle to keep up with a far more rigid roadmap.
In the same vein, she continues her argument that this kind of roadmap shouldn’t contain concrete dates, but rather just time horizons: now, near term, future.
Theme-based roadmaps have a clear advantage in lean/agile organization over feature-based ones, which are always subject to a lot of revision and provide a false sense of certainty. However, they might require gathering stakeholder buy-in since they are not necessarily the first thing that people expect when they hear “roadmap”.
Putting It All Together
For all layers of the product strategy pyramid, there are different definitions, and none of them are inherently right or wrong. As with so many things in the life of a product manager, it all comes down to alignment with stakeholders: everyone needs to agree what a product vision / strategy / roadmap looks like before you can go ahead and create one.
Having said that, here’s my take on the matter after having reviewed a lot of writing about the topic:
The vision makes most sense when it describes customer benefits at a high level, without going into details in how they will be achieved, what the differentiation and market position is etc. This makes the vision future-proof so that it can truly serve as long-term guidance. In a one-product company, it often will be best if company mission/vision and product vision are the same, reducing confusion and making sure there is actually one north star to follow.
The product strategy, in my mind, needs to be explicit about “how we will win”. This means talking about how value will be delivered to the customer/user, how the product is differentiated from the competition, and what the business model is. Ideally it also describes how you will build up a sustainable competitive advantage, and what growth loops you will employ. I think that the Moore template discussed in the “vision” section above might actually be a good discussion starter to set a product strategy — it does need additional context and nuance though (for instance, most products aren’t sold to just one narrow customer group or solve only one narrow customer problem).
This definition of product strategy, as mentioned above, is less directly actionable than the goal-oriented one, and I think that well-functioning product organizations do need goals. However, I believe that the goal-setting process needs to be based on the strategy, not be the strategy. That way, the strategy can stay stable and you can still have actionable goals — for example, using a quarterly OKR process.
For the product roadmap, anything that promises concrete features too far out in the future is inconsistent with the lean/agile approach, so in my opinion, a theme-based roadmap should be used, with higher fidelity for themes that are currently being worked on, and much less fidelity (most likely only a description of problems/opportunities and goals) for anything further out. In the same vein as for the product strategy, goals for individual themes can be defined as part of the goal setting process.
Putting it all together, we might show an expanded product strategy pyramid that looks like this:
The vision outlines the high-level purpose and benefits that the product should bring, and serves as the “north star”— stable for years, and guiding all product development. The strategy focuses on customer/user value, competitive position (differentiation and competitive advantage), and how business value is generated (business model and growth loops). High-level goals that stem directly from the strategy are set and revised in a quarterly OKR process. The themes in the roadmap are prioritized based on input from the strategy, but also based on the high-level goals set in the OKR process. In addition, theme-level objectives will also be set as OKRs.
I hope this review and discussion was helpful. If it was, please drop me a 👏 below, or leave a comment. Also feel free to follow me on Twitter where I share interesting product management articles I come across daily.
