Outcome Roadmaps

Product Managers are working hard the last few years to get their organizations to focus on Outcomes over Output. The goal is simple, by giving product teams a mission to achieve an outcome, with the right mix of cross-functional skills, practices, and autonomy they are best positioned to deliver results.

While this is simple in theory, putting into practice is a little trickier. In this article, I provide some simple examples to help apply the concepts.

What is an “Outcome”?

Very simply we can define an “outcome” as the consequence or result of an action. Within the realm of software product management, we think about the action usually as some type of development activity. While from a broader business perspective we can also think about everything we do (and don’t do) as actions that drive outcomes.

The specific outcomes we are most interested in as product leaders are those that have an impact on our customers and our business. Generally, we want to plan to drive positive impact while reducing negative impact or risk of negative impact.

In Joshua Seiden’s excellent book Outcomes over Outputs, he has an interesting definition:

// An outcome is a change in human behavior that drives business results.

Seiden ties his definition to human behavior which is hard to argue with at some level. If you can create a better widget that makes a tree fall in the woods but this does nothing to increase user or business benefits, who cares?

The definition leaves vague who the human(s) is that changes their behavior, which is excellent in my opinion. There are many human stakeholders that can change their behavior in a manner that positively impacts business results. Let’s take a look at some example measurable changes in behavior from different stakeholder perspectives:

Customer Stakeholders (users, managers, buyers, sponsors, influencers, etc.)

Reduce individual user time to complete a given business process by 20%
Decrease number of users necessary to handle a given business process by 10%
Reduce error rate in completing a data entry form by 50%
Reduce customer turnover by 10%
Reduce rate of false-positive security events to review from 100:1 to 75:1
Enable users to stop using a redundant product.
Reduce errors in automated migration of data from competitor tool to zero.
Eliminate security exceptions required for high-risk issues.

Business Stakeholders (developers, devops, sales, marketing, customer success, support, CEO, shareholders, board of directors, etc.)

Reduces average sales cycle duration from 6 months to 2 months
Reduces the risk of a failed security audit
Enable the customer to support ratio to increase from 100:1 to 150:1
Increases employee satisfaction score from 7.8 to 9 out of 10

Other Stakeholders (customers of your customer, regulators, community, auditors, analysts, thought-leaders, etc)

Increases social media references by thought leaders from 5 to 10 per month
Increase ranking on Chartis RiskTech 100 by 10 positions

At times it can be a bit strained to describe the “change” in terms of “human behavior”. That said, it is a good working definition until a better one emerges through practice.

Regarding the “drive business results” fragment. This is critical and cannot be overlooked. It makes no sense to intentionally change human behavior if it does not tie to desired business results.

The desired business results we are seeking should be articulated through your product strategy.

[Product strategy is how] we make the product vision a reality, while meeting the needs of the company.

Marty Cagan

Tweet

Feature Roadmaps

A traditional Feature Roadmap is a schedule of planned feature releases that look anywhere from 6 to 24 months into the future. Frequently these look like Gannt Charts that not only specify a specific feature to be delivered but also give the reader visibility into how long the team believes it will take to develop and release.

Features are the specific capabilities that describe the distinct capabilities of our products when we market them. A Feature Roadmap is primarily made up of the list of marketable features that you want to discuss with your customers and prospects. For internal stakeholders, this roadmap will often include enabling deliverables for future features as well.

What is wrong with Feature Roadmaps?

Under waterfall-based new product development, product management would conduct significant up-front research to define a Market Requirements Document (MRD). This document would capture all the market context, competitive environment, and capabilities required. For many, this would then get converted into multiple detailed Product Requirements Documents (PRD) that would detail the functional and non-functional requirements. Then through collaboration with design and development teams, a general architectural design would be created, then a list of features with development and QA estimates associated.

The product manager would then prioritize these features, including enablers, and negotiate from there with business stakeholders and development on how to balance priorities and capacity constraints to chart the best possible course ahead. Many firms would have a sign-off commitment at this point on the roadmap.

At this point, this roadmap and variations of it, would get published and shared across internal teams for planning alignment and externally with customers and prospects. This commitment to future deliverables was demanded by internal and external stakeholders.

Sales & Marketing could coordinate launch and other go-to-market activities
Customer Support could plan for training and resource needs
Professional Services and 3rd Party Systems Integrators could be trained and update their project planning templates
Customers get insight into when they will want to pay for upgrades to derive value they are waiting for
Prospects can make buying decisions comfortable knowing the vendor is planning to deliver that critical feature the need to be confident signing the contract

The main problem with all of the above… it simply never worked in practice as planned. As soon as a roadmap was agreed to, facts on the ground would change and features would get changed or delayed.

While already broken, as the industry moved from waterfall to agile practices, upfront commitments tied to feature roadmaps became untenable. Agile teams want to focus on the work in the next 3-6 months, sometimes only the next 2 weeks. Asking teams to do minimal design and estimate effort on features planned a year from now goes contrary to the Principles of Agile.

Yet, for many software product managers and executives, the Feature Roadmap continues to be a requirement to do business and coordinate internal activities. Frequently, this puts stress between product management and development teams, that gets solved either by having product management make guesses on feature designs and estimates to put a straw-man plan together OR drag some design leads in to reluctantly participate in the process.

As Feature Roadmaps get circulated internally and externally, the business locks itself into plans that may or may not be well aligned with their evolving priorities. As time goes on, if better solutions to problems are identified, past commitments can’t easily be moved. Everyone becomes unhappy:

Executives, Sales, and Support are unhappy with the lack of agility
Executives lose confidence that the roadmap reflects the business optimal value
Product Teams become feature factories pumping out whatever is on the plan
Customers don’t understand why everything is constantly late
Customers don’t understand why the future they get doesn’t solve the problem they thought it would
Product Managers wonder why they can never get anything strategic done

To solve these pains, some organizations force more upfront planning to get stronger commitments on the roadmap. Product Managers are forced to explain how a feature planned in 9 months drives a specific business goal.

These reactions only tend to exacerbate existing pains. There is a better way.

Ultimately, what customers and the business want are outcomes. Rather than committing to roadmap plans that specify a schedule for feature delivery. It is now considered best practice to plan based on outcomes rather than features.

While this takes a mindset shift for many internal and external stakeholders, the focus on outcomes enables a roadmap that closely connects to the product strategy without creating the feature fiction.

By focusing on outcomes, Autonomous Product Teams are given the freedom to perform timely product discovery to find the most effective way to solve for a given need. These cross-functional teams are the best source of innovative solutions. Predefined features committed months ahead on a roadmap are frequently inferior or, simply, wrong.

Detailed Example in Practice

Customers are complaining about an inefficient workflow. It takes 2 minutes to review and act on each security event in a queue. Users think this is far too long. This issue has been raised to execs from account management teams as degrading user satisfaction and making it hard to get referrals.

Based on anecdotal feedback from one key customer, a PM decides adding more info to the incident details screen will help and places “Additional Incident Details” on the Feature Roadmap. Based on priorities this is scheduled for 6 months from now after getting some estimates from the product team.

Under an Outcome Roadmap, the PM prioritizes “Reduce average incident review from 2 minutes to 90 seconds” instead of deciding on a specific feature. This ties directly with the business goal to increase “Customer Referrals by 2x this year”. The deliverable determined to be one of the next delivery priorities.

As the product team gets to work on this challenge, they will perform research on the underlying cause and identify multiple potential solutions to the problem. In this case, the team identifies that the core issue is slow navigation and page loading is causing significant overhead. By adding keyboard shortcut navigation, reducing page load time by 75%, and slightly optimizing information display they were able to cut average review time to 75 seconds.

This combination of improvements ended up taking half the time estimated for the “Additional Incident Details” feature and provided a UX. Further, if the team identified these other improvements while working on the prescribed feature, they would not have had the flexibility to swap solutions as too many customers now expected that specific feature and they did not want to disappoint them. Further, given the tight scheduling, they would not have the time to do both enhancements.

If the goal is to find the best solutions that drive business results, why commit to broken Feature Roadmaps when there is a better way?

Outcome Roadmap Characteristics

Outcome Roadmaps can be written in multiple ways, just like Feature Roadmaps may take multiple formats. However, there are a few characteristics that are emerging as best practice:

Outcomes Focus – Rather than listing specific features, these roadmaps communicate a plan for addressing prioritized outcomes. The exact features to address the needs are unknown when defining these roadmaps. Each outcome maps clearly to strategic goals.
Now, Next, Later – Timing is split into major timeframe buckets that reflect how product teams actually work and plan together.
No hard deadlines on outcomes – Desired outcomes often come with a quantifiable definition. The exact metric targets are often arbitrary but based on a good understanding of market context and alignment with product strategy. As the team iterates to achieve that target, the product manager needs to continuously validate if they have achieved sufficient success to consider it done.
Continuously Updated – Unlike Feature Roadmaps that were born out of waterfall methodologies, the Outcome Roadmap is perfectly suited for Agile methodologies.

Conclusion

An Outcome Roadmap requires a different mindset from executives, product teams, and other stakeholders. They work best within cloud-based software that is continuously delivered and continuously integrated. However, they can also provide value to on-premises enterprise software companies by better aligning strategic planning with Agile methodologies.

For companies stuck on Feature Roadmaps, even those with nice Investment Themes and indications of relationship to strategic goals, consider performing some small experiments of shifting toward Outcome Roadmaps. If we can agree that outcomes are what matters than your roadmap has to reflect that.

Leftovers

This article glosses over many topics that arise when working with Outcome Roadmaps. I intend to cover these in future articles. Here are some examples.

Commitments. Sometimes it is critical to make a commitment to the market for your business to function. A major example is adhering to regulatory compliance requirements on a certain schedule like GDPR, CCPA, PCI, UK Equality Act, or many others. These legal requirements vary in how prescriptive they are but are often table-stakes to continue your applicable product business.
Converting Outcomes to User Stories. Ultimately, a solution needs to be designed that intends to address the outcomes and Scrum teams work from a backlog of user stories (and other tasks).
OKRs. Objectives and Key Results map directly into the Outcome Roadmap concept I have described.
Process for Building Outcome Roadmaps. Teams need Vision and Product Strategy to guide them but a collaborative approach to setting measurable targets to outcomes is important.
Measuring Outcomes. If you intend to deliver measurable results based on the features you ultimately deliver than you must measure the results. Many organizations deliver a feature that theoretically will achieve a given benefit, but never follow-up. If you don’t measure the actual results you can never say whether or not the effort was a success. Measurement is key to learning and making your next prioritization decision.