Listen to the audio version of this article:
Traditionally, a product roadmap is a feature-based plan that assigns capabilities like registration, search, and reporting to a timeline.[1] Such a roadmap essentially states when a piece of functionality will be delivered. This can be reassuring for customers and stakeholders. But unfortunately, it has several drawbacks, including the following two:
These drawbacks are avoided by using a different approach: an outcome-based, goal-oriented product roadmap. As the name suggests, this plan focuses on product outcomes, which are also referred to as product goals and objectives. Examples are acquiring customers, increasing engagement, and reducing cost. What’s more, using outcomes makes it easier to align stakeholders and guide development teams, and it helps discover the right product functionality and direct the product backlog.
Figure 1 shows what an outcome-based roadmap may look like using my GO Product Roadmap template, which you can download for free together with a handy checklist from my website.
Out of the five elements in Figure 1, the goal is the most important one, as it describes the customer/business outcome you want to achieve with your product. Strictly speaking, all other elements are optional. While the GO Product Roadmap still uses selected, coarse-grained features, these must support their outcomes. Goals come first, features second.[2]
| What about OKRs? OKRs, objectives and key results, are a goal-setting method originally developed at Intel in the 1970s. The objective describes what you want to achieve. The key results state the specific criteria that have to be fulfilled to meet the objective. If you use OKRs for your product, you can simply view the objective as the outcome. The advice I share in the remainder of this article will therefore help you set the right objectives.[3] |
As the outcomes on a product roadmap play such an important role, it is crucial to choose the right ones. To achieve this, I’ve found two methods helpful: deriving them directly from the needs and business goals in the product strategy and determining them with the help of key performance indicators (KPIs). Let’s look at the two techniques in more detail.
Derive the Outcomes from the Needs and Business Goals in the Product Strategy
To make the discussion more concrete, let’s use an example. Say that I want to offer a new healthy-eating app. Its product strategy states that the user need is to “reduce the risk of developing type-2 diabetes,” and the main business goal is to “create a new revenue source.” Let’s also assume that the business model I have chosen is freemium, giving away a free basic version and generating revenue through subscriptions.
With this information in place, I can ask myself what the first, concrete step to meet the needs and the business goals is. My answer might be, “help users understand their eating habits and acquire an initial user base.” What I have done here is break down the two higher-level goals stated in the strategy into a more specific outcome.[4]
Applying this method not only helps determine the right product goals. It also connects the product roadmap to the product strategy—the former is literally derived from the latter. To put it differently, the strategy forms the foundation for identifying the right product outcomes. Figure 2 illustrates this approach.
If I can see further than the initial offering, or MVP, I would derive additional outcomes. These might include assisting users in improving their dietary habits and expanding the user base, as well as supporting users in achieving greater fitness and generating revenue through subscriptions. Together, these goals form a meaningful narrative. They describe how the product is likely to evolve in the coming months: Each outcome is a step towards realising the overarching needs and business goals, thereby helping implement the product strategy.
Note that this method assumes that a product strategy and business model are available that have been validated: They don’t contain any significant risks and assumptions, and their statements are based on empirical evidence, rather than beliefs and opinions. If you lack such a strategy, follow the advice I share in the articles Product Strategy Discovery and How to Build a Strategy for an Existing Product before you continue to determine outcomes for your product.
Use KPIs to Determine the Right Product Goals
Deriving product outcomes directly from the product strategy works well for a product that experiences innovation and change, as it’s in the introduction or early growth stage, for example. But the method is not as effective for products that are stable or mature, that undergo incremental changes and smaller updates. Luckily, there is an alternative: using the product’s key performance indicators (KPIs) to identify the right product goals, as shown in Figure 3.[5]
Say that engagement, like daily active users (DAU), is a key indicator for my healthy-eating app and that it has been declining for the past three months. I may then want to choose a product goal that addresses the issue and improves the metric. This might be enhancing the user experience by simplifying an important user journey, or providing performance and stability improvements, depending on what causes the engagement to be low.
Another example would be an increase in software bugs and code complexity, which indicates that the product’s health is degrading and that the software is becoming more difficult to extend and maintain. In this case, I might choose a product goal like “decrease technical debt to reduce development cost” to address the issue.
In both cases, the outcomes identified must be aligned with the product strategy—they must help meet its user/customer needs and business goals. This ensures that the product strategy guides roadmapping decisions and that the roadmap and its outcomes implement the strategy.
As product people, we are sometimes so focused on shipping features that we mix up outcomes and outputs and end up using roadmap goals that are features in disguise—rather than describing the positive impact we want to achieve.
Let’s take my healthy-eating app again to illustrate this issue. Say that I want to explore what the product could do for the users, and I come up with “measure calorie intake and determine blood sugar level.” Do these statements then qualify as product outcomes? I don’t think so. They describe product capabilities and characterise the solution. But they don’t state why it is worthwhile to progress the product.
A good test is then to ask the “why” question, as suggested in Figure 4. For example, why would it be helpful to measure calorie intake? The answer would then reveal the true goal, such as “help the users improve their eating habits.” Therefore, be careful not to mistake features for outcomes, and ensure that your product goals always capture the desired outcome and not the output.
Once you’ve chosen the right outcomes and checked that they describe actual benefits, take the next step and get their size right: Roadmap goals should be no smaller than six weeks and not bigger than four months. Here is why: If an outcome can be accomplished in less than four weeks, it tends to be too granular and often resembles a short-term, tactical goal like a sprint goal. If it takes longer than four months to achieve it, it is too coarse-grained and does not offer enough guidance.[6]
If it turns out that the outcomes you have identified are too big or small, rework them until they are the right size. In some cases, this may require splitting a larger goal into two subgoals that can be met separately. I might, for instance, split an outcome like “help users understand their eating habits” into the following two goals: “help users understand their breakfast habits” and “help them be aware of what they eat for lunch and dinner.”
Some product teams like to work with quarterly goals. This can make roadmap planning easier and help manage stakeholder expectations. But there is no hard requirement for all outcomes on a roadmap to have the same size, and you should not be afraid to use smaller or bigger goals if required. For instance, if you discover that your product suffers from an increasing amount of technical debt that threatens its architectural integrity and makes it more expensive and time-consuming to add new features, you might want to set a two-month goal that addresses the issue, thereby deviating from the quarterly cadence—assuming that that’s enough time to carry out the necessary work.
It’s great to have a BHAG—a big, hairy, audacious goal—as the product vision and strategic needs and business goals that act as guardrails but aren’t necessarily measurable and time-bound. But when it comes to product outcomes, you should use goals that offer more concrete guidance and meet the following three qualities:
It is common in my experience to initially identify comparatively coarse-grained product goals, which are neither specific nor measurable. Consequently, they have to be reworked and improved until they are clear and contain a target, if possible.
With specific outcomes in place, make sure that you can clearly determine if a goal has been met and if the desired impact has been achieved. For instance, if your goal is to acquire between 5-10% new customers, determine how you are going to measure if the objective has been fulfilled. Does a successful acquisition require that an individual register with your website, for example? Or should you measure if the number of unique visits has increased? And what does “new” mean? Should the customers belong to the same market or market segment that is currently served, or do you intend to reach out to a new one?
Additionally, state by when the goal should be met. In the case of an acquisition goal, you might have to wait several days or even a few weeks after the software is released before enough data has become available so you can understand whether the desired benefit has materialised.
If, however, you find that making all the goals on your roadmap specific and measurable is too difficult at present, then focus on the first outcome, and ensure that at least this goal can be measured. Leave the other ones as they are for now and rework them when you review the product roadmap.
Finally, check that each outcome is feasible and can be achieved without violating sustainable pace and requiring people to work overtime. The best way to do this is to involve the development team members in identifying and refining the goals, as I’ll discuss in the last section of this article. Don’t pressurise people to agree to the goals. Instead, keep an open mind and adjust the outcomes or extend the allocated time frames if required.
Often, there is so much work yet so little time. It’s therefore tempting to use multiple outcomes per roadmap timeframe. For example, if you’ve chosen a quarterly cadence, you might opt for setting two or three outcomes per quarter.
While this might look good and possibly help appease some stakeholders, it carries the risk of slowing you down. Following multiple goals dilutes focus, undermines teamwork, and makes it harder to track progress. A better approach is to use one product goal at a time. This offers the following benefits:
You should therefore avoid setting several product goals for a given period. If you choose to use multiple outcomes, make it an exception, and don’t let it become the norm. If this is challenging, consider using smaller goals that can be achieved in shorter timeframes, together with the prioritisation approach I share in the next section.
The best product outcomes and the most amazing roadmap are of little use if the key stakeholders and the development team members don’t understand and support them. To ensure that the roadmap and its goals are truly shared, I recommend involving the individuals in setting the outcomes, preferably in the form of a collaborative workshop, as shown in Figure 5.
To structure the workshop, take the following five steps.
Consider using a dedicated facilitator to moderate the workshop, for instance, the team coach or Scrum Master. This allows you, the person in charge of the product, to focus on determining the right outcomes instead of having to ensure that everybody is heard and nobody dominates.[9]
Note that the product manager in Figure 5 has the attribute primus inter pares. This means that the individual is empowered to have the final say if no agreement can be reached. Collaborative goal setting does not mean that everybody gets their way or is necessarily super happy with every single outcome. It means leveraging people’s expertise to create product goals that help maximise the value the product creates and that attract as much support as possible.
An outcome-based product roadmap is not a fixed plan but an adaptive one. As market conditions, the competitive landscape, and technologies change, the roadmap, together with its outcomes, must be updated. This ensures that it continues to be a helpful, forward-looking plan that aligns the stakeholders and guides the development teams.
Reviewing the outcomes is best done as part of a strategy workshop, where the product strategy and the product roadmap are discussed together. The workshop should take place once per quarter, as a rule of thumb, and involve the individuals who have helped you create the roadmap.
Additionally, I recommend continuously reviewing the product performance using KPIs, as well as keeping an eye on the competition and relevant trends. This ensures that you spot opportunities and threats as early as possible so you can respond to them proactively and adjust the product outcomes as soon as possible, as I explain in more detail in the article Continuous Strategizing.
| A Note on Using AI to Determine Product Outcomes The work described in this article can be supported and partially automated by AI, especially in the following two areas: First, monitoring the product performance using the KPIs you’ve chosen. This includes analysing qualitative data like support tickets and call transcripts. Second, predicting the likely impact of outcomes, thereby helping you choose the right ones. But before you start heavily using AI, ensure that you are competent at manually setting the right outcomes and building effective outcome-based roadmaps. As the product manager, you must always be in charge of your product, own the strategic product decisions, and decide which outcomes your product should achieve. |
[1] I use the term feature to refer to a product capability, as a large piece of functionality that is bigger than an epic—which is a large user story.
[2] To learn more about the GO roadmap, read the article The GO Product Roadmap or watch the video GO Product Roadmap Introduction. To get started with outcome-based roadmaps, take a look at my article How to Get Started with Outcome-Based Product Roadmaps or watch the equally named video.
[3] See my article OKRs and Product Roadmaps to learn more about OKRs and outcome-based roadmaps.
[4] Note that I used a compound goal in the example to capture the desired outcome. The goal consists of two closely connected parts—a user part, “help the users understand their eating habits,” and a business one, “acquire an initial user base.” This allows me to clearly describe the specific value the product should create for the users and for the business. Additionally, it avoids the risk of neglecting the users’ needs by being fixated on business outcomes.
[5] This assumes, of course, that you have effective KPIs in place. If that’s not the case, identify the right indicators before you continue setting product outcomes. My article How to Choose the Right KPIs for Your Product will help you with this.
[6] Note that this guideline assumes a product roadmap is complemented with a validated product strategy and that it covers a 12-month timeframe. For longer plans and outcomes that are further out in the future, a bigger size might initially be appropriate. For example, on a two-year roadmap, the last two goals might cover a six-month period. If you employ outcomes this big, break them into smaller ones once you’ve started implementing the plan.
[7] The acronym stands for Reach, Impact, Confidence, Effort.
[8] To understand the likely effort required in achieving an outcome, ask the development team members to base the estimates on their knowledge and experience. See the article Release Planning Advice for more guidance.
[9] You can take this approach further, continue to involve the same people in strategic product decisions and form an extended product team. See my articles Building High-Performing Product Teams and Maximising Stakeholder Buy-in to Product Strategy and Product Roadmap.
This article explains how you can successfully implement the product operating model—based on my experience…
Every product has a strategy. But not all product strategies are clearly articulated, let alone…
Product teams play a key role in solving user problems and achieving product success. But…
AI has significantly impacted product management. But so far, most product teams have used it…
Stakeholder management is as important as it is challenging: Without the support of the stakeholders,…
Product strategy, OKRs, and KPIs are popular product management frameworks. But how can they be…