Outcome Based Roadmaps: Unleash The Power Of A Shared Vision and Purpose
--
At Denver Startup Week this year (2019), Kelsey Stevenson, Thomas Vela and I presented a talk on Outcome Based Roadmaps which proved to be quite popular! This post is a summary of our talk and a link to our presentation.
Note: This is a repost of this original article.
TL;DR: Give me the slides!
Here’s a link to a PDF of our presentation: https://drive.google.com/open?id=1iOJxWwjKvo8eXDdBf-3xkBlqv-CfGkjC
Avoiding The Feature Factory
Many software teams struggle to deliver value to customers. More often than not, it’s because product and engineering teams stopped talking to customers. Or they don’t measure whether what they delivered (features) had the desired impact. They are stuck in a feature factory, just “building stuff” and churning out features — and hoping that someone will use it.
Did customers like what we just released? Can we improve the feature? Are customers getting value out of the feature? If you don’t measure this stuff, and don’t talk to customers, you’ll be unlikely to have an impact on the market.
Shipping a feature does not equal success. Changing customers’ behavior in measurable and positive ways is what leads to success.
Luckily there is another way.
Roadmaps vs Release Plans
A Release Plan is a list of features and dates.
A Roadmap on the other hand is a document intended to communicate the strategic direction of the company — what are our goals, what are our outcomes, and how will we win in the market.
Since everyone likes a good Netflix story, here’s the Netflix roadmap from 2007:
Many companies really only have a release plan. They try to predict the impact of multiple features, at scale and over time, many months in advance. Executives like this kind of “certainty” and control, even though teams rarely deliver on the roadmap as planned, and the features delivered rarely have the needed impact. This list of features and dates gets labeled as a “roadmap”, but it’s lying.
These kinds of companies don’t measure whether they are achieving their strategic objectives (if they even have them written down), or there isn’t any direct connection between each feature and the company’s trailing impact metric indicators (eg. total user count, ARR etc.). We just ship features blindly at some date, and hope that they’ll deliver an impact.
There is a better way.
From Outputs to Outcomes
Features are Outputs. They are what we create.
As a result of applying our developers, product team, UX experts and QA staff (our Resources), we do software development (our Activity) that leads to a feature being released to the market (an Output).
The vast majority of software teams ship features and then declare success!
However, what modern product teams care about is whether the thing we just shipped had the desired Outcome.
An Outcome is a measurable change in customer behavior.
The goal of any Feature you ship to a customer should be to change the customer’s behavior in a measurable and positive way. If you ship a feature, and it doesn’t have the desired outcome, did you succeed? We would argue: nope.
There could be many reasons why your feature didn’t achieve the desired outcome. For example:
- the idea that you had wasn’t the right idea
- the first version you shipped wasn’t very good, and you need to iterate on it until you improve it
- you didn’t solve the customer’s problem, provide a customer gain, or perform a job that they needed doing.
Measure Outcomes to Iterate To Success
In order to do know whether your feature worked you have to know:
- what success looks like for each feature
- how to measure success
- then you need to measure it.
For every feature. Every time. Outcomes (changes in customer behavior) should are the impacts of our features and the need to be:
- Measurable
- Aligned to a company goal; and
- Focused on the customer.
If we want to achieve our Product Vision and have an Impact on the market, we have to know what Goals are going to get us there.
As consultants and product leaders, we see most teams operating without a clear vision of what they want their product to be or a clear strategy for how to get there. If you already have a clear and compelling product vision, you’d be in the minority of customers.
A product strategy is not a plan. A product strategy is a decision making framework that teams use to make decisions over time in order to achieve the product vision.
Start with a Product Vision and Goals
Step 1: Start with a clear and compelling Product Vision. Make it clear why your product should exist. Where do you want to be in 5 year’s time? Your product vision should be timeless. In order to get somewhere, you need to know where you’re headed. The product vision provides a north star to your engineering teams, so they are all moving in the same direction.
Example Product Vision: Be the #1 mobile workforce management application for hotel maintenance across the Americas and Europe
Step 2: Create 2 to 3 Goals for your company for the next 1–2 years that, if achieved, would result in your realizing part of your product vision. Goals should be specific and measurable (ideally SMART goals), and should result in the success of the company if you achieve your goals at scale. Be specific, for example:
Example Goal: Be used daily by 4% of hotel maintenance crews in European target markets by July 30 2021
Now Focus On Outcomes
Step 3 is to focus on which customer behaviors you need to change in order to achieve your goal — your Outcomes. These could be things like signup rate, conversion rate, customer satisfaction, items created etc. Make it Specific, Measurable, Achievable, Realistic and Time-bound (SMART). Notice the focus on the customer here. This is about them.
Here’s an example:
Customers create a work order in their native language within 5 min of app download by 31 Dec 2019And another example:
At least 80% of all users manage at least 5 work orders weekly, whereas today they manage 2 work orders weekly.Notice the format: customer behavior <A> changes from <x> to <y> over timeframe <t>. It’s best to include your starting and target metrics when defining your outcomes — which of course assumes that you can measure where you are today, which is a key component of managing by outcomes.
If you use the OKR format at work, then:
- Goals are your Objectives
- Outcomes are your Key Results.
Create Opportunities
Step 4: Identify Opportunities for changing customer behavior. Opportunities are:
- Customer Problems,
- Customer Gains,
- Customer Pains, or;
- Jobs To Be Done
which, if solved, would lead to the desired outcomes.
As Marty Cagan observes, teams need to have deep knowledge of the customer, the data, and the market in order to solve the problems of customers, and create products that are valuable, usable, feasible, and viable.
Product Strategy
At this stage you have:
- A clear and compelling product vision
- A set of goals that will lead to you achieving your vision
- A set of measurable outcomes you want to achieve, focused on the customer
- A set of customer problems/gains/pains/jobs as opportunities that you need to solve in order to provide customer value.
Notice what we don’t have at this stage: features, stories, ideas, solutions. Before we wrote a single line or code, or created a single word of text, we have a clear definition of success, and a clear set of things we need to focus on to achieve our goals.
Most product teams don’t start here. Most product teams implement features that a CEO or SVP thought up while sitting in the shower that morning. Known as the HiPPO method (Highest Paid Persons Opinion), according to a study by Jez Humble in 2012, over 60% of all feature teams use this as the method for deciding what to build. Success is defined as shipping. And yet, only 1 in 7 product features achieves any kind of measurable impact.
Ideas are easy.
Solving customer problems and achieving objectives is hard.
Having a strategic framework to use to measure success allows empowered and cross-functional product teams to iterate on features and solve problems until the desired objectives are met.
Ideas, Solutions and Features
As we mentioned above, most features come anointed-from-on-high by the company’s leaders, unconnected to any coherent strategy. Feature teams build features like contractors, and shipping is defined as success: regardless of whether your outputs lead to the desired outcomes. We measure engineering team velocity and shipped features and declare success.
Delivering the Wrong Feature Faster Still Delivers No Value
High performing product teams however use data and customer feedback to measure whether features are achieving the desired objectives. Every feature is measurable at release and desired outcomes are known in advance. They iterate on features (using Lean Startup techniques such as Build-Measure-Learn) until successful. They know what success looks like, and they know what their goals look like.
The people best placed in a company to be able achieve outcomes and goals are those building the features and those closest to the customers. This is usually the product teams, the product managers, the engineering and ops teams. Ideally all these people will be on the same cross-functional product team, and not siloed off in departments. If that’s how you’re organized today, then managing by outcomes might not work for you.
Step 5. Hand the outcomes to cross-functional product teams, and let them:
- Generate ideas based on the opportunities you negotiated with them
- Validate which ideas actually solve the customer’s problem, using data and customer feedback (the UX team is your friend here)
- Create Features based on validated Solutions to customer’s problems.
- Iterate on features until success is achieved.
A highly recommended technique to clearly articulate the connection between outcomes and solutions is the Opportunity Solution Tree from Theresa Torres. In Confessions of a Former Feature Factory PM Dave Chalmers gives some great tips for making the opportunity solution tree concrete within an organization. The idea is to write down and make very explicit
- which ideas you think will solve the opportunity
- what experiments, hypotheses or possible solutions you tried
- what the result was and whether to proceed with the feature, abandon the idea, or whether to run a new experiment to improve the idea.
Writing it down keeps you honest, holds you accountable by making your thinking explicit to leadership, and in larger companies acts to share learning between teams, and over time.
Only when you have validated your ideas through experiments should you proceed to creating a Feature and Stories and building production ready code. The best teams avoid building features that create no value.
The Outcome Based Roadmap
The roadmap is therefore a strategic communication device used to communicate to our leadership and teams:
- What our vision and goals are
- What outcomes we’d like to achieve to get there
- How we’ll measure success
- What our current focus is
- Some indication of timeframe
Since the Roadmap communicates the strategy, it focuses on the Vision, Goals, Outcomes and Opportunities.
The release plan focuses on the Stories, Features, Ideas and Solutions.
Opportunity Solution Trees help to make your experiments and learning more concrete to leadership.
As much as I’m allergic to putting timeframes on roadmaps, the reality is that you’ll need to provide some guidance to executives on timeframes and sequencing. Usually listing time horizons in terms of Current, Next and Future is the way to go. Always list your vision and goals on the roadmap, to ensure your outcomes tie back to your goals. You can group your outcomes into Themes if that makes sense as well — often this helps make your strategy concrete. For working with Rally and Jira this will make a lot of sense.
Putting it all together you get the Outcome Based Roadmap:
Something that often works well is to list current features in development for the “current” time period only to give executives a sense for “what’s in progress right now” versus what the strategy is for the next quarter or sometime later. There are some great examples of this technique in Product Roadmaps Relaunched by Todd Lombardo, Bruce McCarthy, Evan Ryan and Michael Conners, which is a book we highly recommend.
Some great links to other outcome based roadmap examples can be found here:
- Melissa Perri: Effective Product Roadmaps
- Elena Sviridenko: Outcome Driven Roadmaps
PS: if you haven’t read The Build Trap by Melissa Perri, stop what you’re doing right now, go buy a copy, and thank us later!
Wrapping Up
Managing products by outcomes is hard. You have to have a clear vision and strategy. You have to empower your teams to solve problems and iterate to success. You have to manage by objectives, and get out of the way. You’ll have to embrace uncertainty, and give up managing products using projects. You have to hire and train teams that will own the outcomes, which takes a lot of talent, psychological safety and trust. You need a DevOps culture to be able to safely test ideas in production with real customers and get feedback and data.
Think you’re too big to manage like this? Amazon, Netflix, Google and Facebook manage products this way — and they’re arguably bigger than you. Think you can’t do this because you’re too highly regulated? The UK Government did it.
Switching to managing products by outcomes is something you should work up to over time, especially if you are currently sales led or engineering led. Go slowly, make lots of small changes over time, and above all create alignment around a shared vision of the product using your roadmaps!
Manage by outcomes. You’ll be glad you did.
Jason Doherty, Kelsey Stevenson and Thomas Vela
