Outcome-based Roadmaps: Explanation and Guide
Learn how to create effective outcome-based roadmaps with our comprehensive guide.
Develop product roadmaps or strategy? You’ve probably heard of outcome-based roadmaps.
They’re proposed as a better alternative to feature-based roadmaps. The idea is that, since you’re focusing your planning on the outcomes you want, you’re less likely to become simply a feature factory, pumping out new features.
In this article, we will explain what outcome-based roadmaps are, how they differ from other types of roadmaps, and provide examples to help you decide whether they are right for your organization. We'll also provide guidance on creating your own outcome-based roadmap and discuss some best practices to keep in mind.
What is an outcome-based product roadmap?
An outcome-based roadmap is a visual plan that helps show how you’ll execute your product vision and strategy. The key characteristic of an outcome-based roadmap is that you prioritize outcomes and then align your activities and resources to achieve those outcomes.
Like all product roadmaps, outcome-based product roadmaps are designed to keep your teams aware of your product plans so you’re all rowing in the same direction, together.
What distinguishes the outcome-based roadmap is its focus on customers and business value. That’s different from, say, feature-based roadmaps, which focus on producing features that may or may not deliver value to customers.
Here are some key elements of an outcome-based roadmap:
- Clear outcomes: The roadmap should identify specific, measurable outcomes or results that you’re aiming for and they should align with your product vision and strategy.
- Milestones and timelines: An outcome-based roadmap usually includes time frames for key milestones and their associated target dates. This helps in tracking progress and ensuring accountability.
- Features and initiatives: The roadmap identifies the features, activities, initiatives, or projects that need to be executed to achieve the desired product outcomes. These activities are chosen based on their potential to contribute to the defined outcomes.
- Resource allocation: The roadmap takes into account the necessary resources, such as budget, personnel, and technology, needed to execute the activities and initiatives outlined.
- Measurement and evaluation: An outcome-based roadmap includes mechanisms to measure progress and evaluate the effectiveness of the initiatives or projects. This allows for continuous improvement and adjustment of the roadmap as needed.
By focusing on outcomes rather than just activities, an outcome-based roadmap provides a strategic framework that helps organizations or individuals stay focused on their goals and make informed decisions about resource allocation and project prioritization. It allows for flexibility and adaptability while providing clear direction for your teams and stakeholders.
Outcome-based roadmaps vs. feature-based roadmaps
Outcome-based roadmaps and feature-based roadmaps are two different approaches to strategic planning and product development. Here's a comparison between the two:
- Focus: An outcome-based roadmap emphasizes the desired outcomes or results that need to be achieved; feature-based roadmaps focus on the development of specific features or functionalities of a product.
- Purpose: Outcome-based roadmaps aim to align activities and resources with the overall goals and objectives of the organization or project; feature-based roadmaps aim to prioritize the implementation of various features.
- Approach: Outcome-based roadmaps identify specific outcomes, define measurable objectives, and determine the necessary steps or initiatives to reach those outcomes; feature-based roadmaps identify and prioritize individual features or enhancements based on factors such as customer feedback, market analysis, or technical feasibility.
- Benefits: Outcome-based roadmaps keep the focus on the big picture and the impact the project or initiative aims to achieve; feature-based roadmaps provide a more detailed plan for feature development.
- Measurement: For outcome-based roadmaps, progress is measured based on the achievement of outcomes and their impact; for feature-based roadmaps, progress is measured based on the completion of features or milestones outlined in the roadmap.
While both roadmaps have their merits, the key difference lies in their focus.
In practice, organizations may use a combination of both approaches, starting with an outcome-based roadmap to define the overall goals and desired outcomes, and then adding details about the specific features they plan to build that contribute to those outcomes. This hybrid approach allows for a balanced view of both the high-level objectives and the detailed execution of the project or product development.
Outcome-based roadmaps vs. goal-based roadmaps
The line between outcome-based roadmaps and goal-based roadmaps is fuzzy. They have a lot in common, especially their focus on how your product plan aligns with the product vision and goals. Many resources use the two interchangeably.
In a research paper, Jürgen Münch and his colleagues at Hochschule Reutlingen identify them as distinct roadmap strategies. From what I can see, the main distinction between the two lies in their level of granularity. Outcome-based roadmaps focus on broader outcomes and their associated impact, whereas goal-based roadmaps break down the outcomes into specific, measurable goals and tasks.
In practice, I think the distinction between the two isn’t so important. The point is that you include your larger goals on your roadmap so that you don’t become a feature factory. Instead, you are prompted to make sure the features you prioritize are in line with your business goals.
Outcome-based roadmap examples
Example 1: The first example comes from Jeff Gothelf. It includes your longer-term strategic theme as well as your quarterly objectives and key results (OKRs). Then it has the features that you might build to achieve those OKRs.
One type of outcome-based roadmap described by Jeff Gothelf. Source.
Example 2: Our second example comes from Jason Doherty. Again, he includes the vision and long-term goals at the top of the roadmap. Then, there are themes that represent goals for user behaviour in swimlanes on the left. Then features are put in those swimlanes and organized into sections based on when you’re working on them: this quarter, next quarter, and sometime in the future.
A second type of outcome-based roadmap described by Jason Doherty. Source.
Is an outcome-based product roadmap right for you?
Now, let's explore whether it is right for you. Here are some of the pros and cons.
Pros of outcome-based roadmaps
There are several reasons why companies move towards outcome-based roadmaps. Some of the reasons include:
- Flexibility. Outcome-focused roadmaps provide the development team with the flexibility to prioritize additional or alternative features as the context changes or more insights become available.
- Collaboration and alignment. Outcome-based roadmaps ensure that all stakeholders are on the same page and prioritize features based on the outcomes that are most important to the business.
- Focus. Outcome-based roadmaps provide the development team with a defined focus to work towards—one that is centered around delivering business value.
- Agility. Outcome-based roadmaps provide greater opportunity for alignment with agile methodologies like scrum or Kanban, and provide a more strategic view of the work in progress.
Cons of outcome-oriented roadmaps
Outcome-based roadmaps also have some drawbacks. Some possible disadvantages include:
- Too flexible. Outcome-based roadmaps can become too fluid. Your stakeholders might want to know exactly what features you’re planning to build and when.
- Less focus on user needs. Some teams prioritize business goals at the expense of users’ needs, which can limit the success of the product.
- Difficulty in breaking down goals. It may be difficult to break goals down into manageable pieces without a more granular, feature-based approach.
- Takes more time. It can take more time to create and manage outcomes-based roadmaps than other more traditional types of roadmaps because it involves the extra step of establishing, agreeing on, and measuring the goals.
When to use outcome-based roadmaps
So should your team adopt outcome-based roadmaps? Here are some contexts when it probably makes sense.
Big-picture planning. Outcome-based roadmaps are valuable when creating higher-level strategic plans for your organization. They help align the roadmap with the overall strategic objectives, ensuring that the initiatives and projects are geared towards achieving desired outcomes.
Customer-centric approach. If you prioritize customer satisfaction and want to deliver value to your customers, outcome-based roadmaps can be beneficial. By identifying the outcomes or problems your customers want to solve, you can design your roadmap to address those specific needs and ensure customer success.
Agile and adaptive environments. Outcome-based roadmaps are particularly useful in agile or lean development methodologies. Instead of specifying detailed tasks and features upfront, you define the desired outcomes and allow teams to experiment and adapt their approach. It promotes flexibility and innovation.
Uncertain or evolving environments. In dynamic environments where requirements and market conditions can change rapidly, outcome-based roadmaps provide a more adaptable approach. Rather than committing to a fixed plan, you focus on achieving the desired outcomes and adjust your strategies based on feedback and emerging information.
Remember, outcome-based roadmaps are not mutually exclusive to traditional feature-based roadmaps. In some cases, a combination of both approaches might be appropriate, depending on the specific context and needs of your project or organization.
How to make an outcome-based roadmap
The process of making outcome-based roadmaps is relatively simple, although it requires some planning and long-term thinking. Here are the basic steps to follow.
Tip: Check out our guide on building a product roadmap for more detail.
Step 1: Establish your product vision and strategy
Every roadmapping exercise should start with a clear understanding of your product vision and strategy, and this is especially important for outcome-based roadmaps. Figure out: what is the big picture “why” of your product?
Learn more: Product vision and strategy guide
Step 2: Define your desired outcomes
As part of that exercise, decide the specific business and product outcomes you’ll aim for that sprint, month, or quarter. Some possibilities include:
- Reducing monthly churn rate by 5%
- Increasing trial-to-paid conversion rate to 10%
- Expanding seats from current customers by 5%
And so on. Make sure that there are clear metrics that you can use to measure progress toward each outcome.
Step 3: Collect feedback and feature requests
Next, make sure you have the infrastructure to systematically collect feature requests and product feedback from your customers. That way, you’ll know which features can help you produce the outcomes you’re seeking.
For example, you’ll know which features your churned customers wanted, which features your free trials want, which features your active customers are asking for that might encourage them to buy more seats, and so on.
That means making sure that all your customer-facing teams (customer success, sales, customer support, etc.) can easily centralize the feedback they get into one place where your product team can access it.
Step 4: Identify features to achieve your outcomes
Now, for each outcome, identify the features or improvements that will help you achieve it.
For example, if you're trying to reduce churn, figure out what actions you can take to move the needle on your churn rate.
In practice, this list will look a lot like your product backlog or feature request vault. And if you use a tool like Savio, you’ll be able to look at each feature request and see how many churned customers, current customers, and others are requesting the feature.
Step 5: Prioritize the features to your roadmap.
Now, choose the features you’ll build first.
This isn’t easy—In fact, it can be the most difficult part.
I’ve written about prioritization before, so if you want detailed advice, you can check out those pieces:
- The Savio method for prioritizing feature requests
- How to prioritize features to your product roadmap
- Prioritization frameworks
Here’s the biggest tip I have as you move forward: use your customer feedback to help you decide what to build. Listening to your customers helps you build a product they actually want and also helps you build loyalty.
Step 6: Allocate resources and set timelines
You’ve got your priorities, and they’re based on your goals. Now make sure they fit in your Dev budget and assign rough dates for when you think they’ll be done.
Remember: roadmaps are planning documents and they are uncertain. That means that you (and your stakeholders!) should be prepared for them to change.
Step 7: Decide how to display the information
You’re building an outcome-based roadmap, so you want to display those outcomes clearly. You may also want to show the product features associated with those outcomes.
But there are a number of ways you can display a goal-based roadmap visually.
- Savio uses Kanban roadmaps
- Jason Doherty and Jeff Gothelf use their own designs
- You could even use a Gantt chart roadmap design
That decision is also connected to the roadmapping tool you decide to use—Powerpoint, Google Sheets, a purpose-built roadmapping tool, or something else.
Make all those decisions at this step.
Step 8: Communicate the roadmap to all stakeholders
At this point, you just need to share your roadmap with your stakeholders.
Get feedback from internal stakeholders. Make any changes necessary. Then publish and share with the rest of your internal and external stakeholders.
Outcome-based product roadmap best practices
Here are some best practices to keep in mind when creating your own outcome-based roadmap:
- Put the focus on outcomes: Ensure that everyone involved understands the overall outcomes you’re striving towards. Your roadmap should be outcome-driven, not feature-driven.
- Be data-driven: Establishing key metrics and measuring progress towards desired outcomes can help encourage decision-making based on data rather than assumptions or assumptions rooted in beliefs. Consider basing your roadmap decisions on customer evidence.
- Collaborate with stakeholders: Involve all stakeholders in defining the business outcomes of the project. Stakeholder buy-in can improve the chances of achieving the desired results.
- Respond to change: Be prepared to make adjustments as you execute your plan. Outcome-based roadmaps are flexible and need to be regularly evaluated, with iterations being made to ensure progress toward the desired outcome.
Other roadmap types to consider
Not settled on the outcome-based roadmap? There are several other options available depending on your specific needs and circumstances.
Roadmap types by what information is displayed
Roadmap types by workflow framework:
- Agile roadmap
- Scrum roadmaps
- Kanban roadmaps
- Feature-by-release roadmaps
- Traditional waterfall roadmaps
Roadmap type by design style
Kareem is a co-founder at Savio. He's been prioritizing customer feedback professionally since 2001. He likes tea and tea snacks, and dislikes refraining from eating lots of tea snacks.
Prioritize high-value Feature Requests
Centralize customer feedback from HubSpot, Intercom, and Slack.
Prioritize high-value features sorted by churned revenue or MRR.
Close the loop for Sales and CS by automating status updates from JIRA.