How to Get Started with Outcome-Based Product Roadmaps
Outcome-based product roadmaps offer many benefits over traditional, feature-based ones including a strong focus on the value a product should create. But how can you introduce this new approach when an organisation is used to feature-based plans and stakeholders find it difficult to trust an outcome-based roadmap? To address this challenge, I introduce a four-step process in this article.
🎧 Listen to this article on my podcast: https://www.romanpichler.com/podcast/
Traditional vs Outcome-based Roadmaps
Before I share the four steps, let me briefly describe the main differences between a traditional, feature- and an outcome-based product roadmap. A traditional roadmap is essentially a list of features, which are mapped onto a timeline. Such a plan might work if there is little uncertainty, change, and innovation present, and you can correctly predict what the product should look like and do. But in today’s fast-changing digital product space, that’s hardly ever the case. Using a feature-based roadmap that fixes the product functionality for the next, say, twelve months therefore risks creating a product that offers the wrong functionality and creates little value for the users and customers.
Fortunately, a different roadmapping approach has emerged in recent years: outcome-based, goal-oriented product roadmaps like my GO Product Roadmap. Instead of determining features, you first and foremost consider the specific value the product should create — the outcomes it should achieve. These might include acquiring new users, reducing churn, increasing engagement, improving conversion, and reducing development time and cost by removing technical debt. To put it differently, instead of focussing on what needs to be delivered, you ask why it is worthwhile progressing 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 that state 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 trust an outcome-based, goal-oriented product roadmap. If you find yourself in a similar situation, then apply the following four steps.
Step 1: Set an Outcome-based Goal for the Next Three Months
To get started, set a single, outcome-based goal for the next three months. An example for an online shop might be “increase conversion by 5%.”[1] Make sure that the goal states the positive impact you want to make on the users/customers and the business. Avoid the pitfall of setting feature-based goals, such as “prioritise the search results” or “improve the search algorithm.” Think why, not what. Additionally, ensure that the goal is specific and measurable so that you can clearly tell if it has been met.[2]
Make sure you involve the key stakeholders and development team representatives in the goal-setting process. This helps you leverage their knowledge, creates transparency and strong alignment, and maximises the chances that they will follow the goal.[3] Aim to achieve consent. This means that nobody involved in the goal-setting process has any meaningful objections against the goal.
A great way to engage the individuals is to invite them to a collaborative workshop, which may take place onsite or online.[4] Ask a skilled facilitator to run the session especially when the attendees don’t know each other well and the level of trust is low. This frees you from having to facilitate and allows you to focus on setting the right goal.
Step 2: Use the Outcome to Determine the Features
With a specific, measurable, and outcome-based goal in place, determine the features that have to be delivered to meet the goal. A practical way to achieve this is to focus the product backlog on the outcome.
Start by removing any backlog items, which are not required to create the desired outcome. Delete or archive them. Then determine how the product has to change to meet the goal. Does the user experience have to be adapted? Do you have to add or change any functionality? Do you have to meet new or enhanced non-functional requirements including compliance standards? Are bug fixes and architecture refactoring work required to achieve the outcome?
Decline any feature requests that do not help you meet the goal. Use the outcome 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 part and parcel of a product person’s job, as I 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 has worked for you. What went well and what didn’t? Did you manage to meet the goal? How beneficial was using the agreed outcome to determine the product features? To what extent do management and business stakeholders support an outcome-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. Should you, for example, involve the stakeholders more closely in the goal-setting process? Should you do a better job of focusing everyone on the outcome? Should you be more ruthless and decline feature requests that don’t fit the goal?
If the approach was successful and management and stakeholders support it, you are ready to take step four.
Step 4: Build an Outcome-Based Product Roadmap
Having successfully used an outcome-based goal to determine the product features puts you in a great position to set 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 from my website.
The template above places the outcomes at the centre of the roadmap. It uses selected features. But these must help meet the goals. Additionally, they have to be coarse-grained and are limited to three to five capabilities per goal. You can learn more about using the GO Product Roadmap by watching this YouTube video.
But before you build your outcome-based roadmap, ensure that a valid product strategy exists. Such a strategy should state the users and customers who will benefit from the product, the needs the product will address, the business benefits it will offer, and the standout features which will set it apart from competing offerings — which is particularly important for commercial products. A handy template to capture the strategy is my Product Vision Board.
Once a valid product strategy is available, use it to determine the right roadmap outcomes. To achieve this, you have two options, as I explain in more detail in my book Strategize: First, you can derive the roadmap goals directly from the needs and business goals by breaking them into subgoals. Second, you can use your key performance indicators (KPIs) to discover outcomes such as increasing engagement and reducing churn — as long as these are aligned with the needs and business goals in the strategy.
Finally, don’t forget to involve the key stakeholders and development team representatives in the roadmapping work. As described in step one, invite the individuals to a collaborative workshop and co-create the product roadmap. This will help you make the right roadmapping decisions and generate strong buy-in.
Learn More
You can learn more about successfully working with outcome-based product roadmaps by attending my product strategy and roadmap training course and reading my book Strategize. Contact me if you need help with introducing outcome-based roadmaps to your team or organisation.
Notes
[1] For simplicity’s sake, I use a business-focused goal as an example rather than a compound one that covers a user/customer and a business benefit. While I prefer the latter, both methods work — as long you state the impact you want to achieve.
[2] If you use objectives and key results, OKRs, then you can view the goal as an objective, see my article OKRs and Product Roadmaps. Similarly, if you apply a Scrum-based process, you can regard the outcome as a product goal, as I discuss in the article Product Goals in Scrum.
[3] Involving people in the goal-setting process makes it more likely that they will work towards the outcome, as long as you attentively listen 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, which consists of the person in charge of the product, dev team reps, and key stakeholders, then invite the team members to the workshop, see my article Building High-Performing Product Teams.
[5] If you cannot decline a feature request, you lack the necessary level of empowerment to do an effective product management job, see my article 3 Empowerment Levels in Product Management.
This article was first published on www.romanpichler.com.
