Outcome-based roadmaps offer many advantages over traditional, feature-based roadmaps, including a strong focus on the value a product should create. But how do you introduce this new approach when an organization is accustomed to feature-based programs and stakeholders have difficulty trusting a results-based roadmap? To address this challenge, I present a four-step process in this article.
Listen to the audio version of this article:
Traditional versus results-based roadmaps
Before I share the four steps, let me briefly describe the main differences between a traditional roadmap, a feature, and a product outcome-based roadmap. A traditional roadmap is basically a list of features, mapped on a timeline. Such a plan might work if there is little uncertainty, change and innovation, and you can correctly predict what the product should look like and do. But in today's rapidly changing digital product space, this is almost never the case. Using a feature-based roadmap that fixes product functionality for, say, the next 12 months, risks creating a product that offers the wrong functionality and creates little value for users and customers.
Fortunately, a different roadmapping approach has emerged in recent years: outcome-based, goal-oriented roadmaps like my GO Product Roadmap. Instead of determining features, you first consider the specific value the product should create—the results it should achieve. These may include acquiring new users, reducing churn, increasing engagement, improving conversion, and reducing development time and cost by removing technical debt. In other words, instead of focusing what Should be delivered, you ask Why You should promote the product.
However, I find in my coaching work that management and business stakeholders can be very attached to feature-based plans and expect to see roadmaps indicating when a feature will be delivered. In such a situation, it can be a big ask to let go of detailed, feature-based plans and rely on a results-based, goal-oriented product roadmap. If you find yourself in a similar situation, use the four steps, shown in the infographic below and explained later in this article. (You can Download the infographic by clicking on it.)
Step 1: Set a result-based goal for the next three months
To get started, set a single, results-based goal for the next three months. An example for an online store could be “Increase conversion by 5%”.[1] Make sure the goal states the positive impact you want to make on users/customers and the business. Avoid the trap of setting feature-based goals, such as “Prioritize search results” or “Improve the search algorithm.” to think WhyNo what. Additionally, make sure the goal is specific and measurable so you can clearly tell if it has been achieved.[2]
Make sure you involve key stakeholders and development team representatives in the goal setting process. It helps you leverage their knowledge, it creates transparency and strong alignment, and it maximizes the chance they'll go after the goal.[3] Strive for consensus. This means that no one involved in the target setting process has significant objections against the target.
A great way to attract the people is to invite them to a collaborative workshop, which may take place on site or online.[4] Ask a skilled facilitator to run the meeting especially when the participants do not know each other well and the level of trust is low. This frees you from the need to facilitate and allows you to focus on setting the right goal.
Step 2: Use the result to determine the features
With a specific, measurable, results-based goal, determine the features that must be delivered to meet the goal. A practical way to achieve this is to focus the product backlog on the result.
Start by removing any backlog items that are not required to create the desired result. Delete or archive them. Then determine how the product needs to change to meet the goal. Should the user experience be adjusted? Do you need to add or change any functionality? Do you need to meet new or enhanced non-functional requirements including compliance standards? Are bug fixes and architecture rework required to achieve the result?
Reject any requests for features that don't help you meet your goal. Use the result as your decision tool and stick to it – unless it becomes invalid. Don't make the mistake of accepting a feature to please a stakeholder or avoid a difficult conversation. Saying no is an integral part of the role of a product person, as I will discuss in more detail in the article 5 Tips for Saying No to Stakeholders.[5]
Step 3: Review the approach
At the end of the three months, review how the new approach worked for you. What went well and what didn't? Did you manage to meet the goal? To what extent was the use of the agreed result to determine the product features? To what extent do management and business stakeholders support a results-based roadmap?
If the approach was somewhat but not entirely successful or the level of support is still low, repeat steps one and two and set another goal for the next three months. Consider what you can do differently this time to be more successful. Is it, for example, worth involving the stakeholders more closely in the goal-setting process? Should we do a better job of focusing everyone on the outcome? Should you be more ruthless and reject unfit feature requests?
If the approach has been successful and management and stakeholders support it, you are ready to take the fourth step.
Step 4: Building a roadmap for a results-based product
Having successfully used an outcome-based goal to determine product features puts you in a great position to define outcomes for the next six to twelve months and build an outcome-based product roadmap using a template like my GO Product Roadmap shown below. You can download it along with a helpful checklist by clicking on the image.
The template above places the results in the center of the roadmap. It uses selected features. But these must help meet the goals. Additionally, they should be coarse-grained and limited to three to five abilities per target. You can learn more about using the GO product roadmap by viewing This video is on YouTube.
But before you build your results-based roadmap, make sure you have a valid product strategy in place. Such a strategy should specify the users and customers who will benefit from the product, the needs that the product will address, the business benefits it will offer, and the salient features that will differentiate it from competing offerings – which is especially important for commercial products. A useful template for capturing strategy is my product vision board.
Once a valid product strategy is in place, use it to determine the right roadmap outcomes. To achieve this, you have two options, as I explain in more detail in my book strategy: First, you can derive the roadmap goals directly from the business needs and goals by breaking them down into sub-goals. Second, you can use your own key performance indicators (KPIs) to discover results such as increased engagement and reduced churn – as long as these align with the business needs and goals in the strategy.
Finally, don't forget to involve key stakeholders and development team representatives in the roadmapping work. As described in the first step, invite the people to a joint workshop and create the product roadmap together. This will help you make the right road mapping decisions and create a strong buy-in.
Remarks
[1] For simplicity, I'm using a business-focused goal as an example rather than a complex goal covering user/customer and business benefit. Although I tend to prefer the latter, both methods work – as long as you specify the effect you want to achieve.
[2] If you use goals and key results, OKRs, then you can see the goal as a goal, see my article OKRs and Product Roadmaps. Similarly, if you are implementing a Scrum-based process, you can refer to the result as a product goal, as I discuss in the article Product Goals in Scrum.
[3] Involving people in the goal-setting process increases the likelihood that they will work toward the outcome, as long as you listen carefully to their suggestions and concerns, as I explain in more detail in my book How to lead in product management.
[4] If you work with an extended product team, consisting of the product owner, representatives of the development team and key stakeholders, then invite the team members to a workshop, see my article Building high-performing product teams.
[5] If you can't decline a feature request, you lack the level of empowerment needed to do an effective product management job, see my article 3 Levels of Empowerment in Product Management.