Getting Started With Outcomes
In Outcomes Over Output, I’ve written about how teams can be more outcome-centric in their work. In this series, I’m answering reader questions.
Recently, a reader contacted me with this question:
Hi Joshua. Recently I’ve read your “Outcomes over Output” book and listened to your podcast appearances. Man, it just blew my mind and shifted perspective on product management . Many, many kudos for your work!
Recently I’ve started at new company as head of PM and guess what. They are output-driven. But they are looking for a change. Do you have tips on what early wins we should aim for to shift gears towards more outcome-driven company?
My plan is to understand vision, business goals, biz model, map out customers journey, get data on each step, understand WIP and start mapping outputs to outcomes. Once that is set start deploying OKRs for whole org. alignment and start experimenting to reach defined KRs. Really appreciate your feedback and suggestions.
I try to avoid blanket advice for “how to get started”, because everyone’s situation is so different. That said, there are a couple of things about working with outcomes that apply broadly, so let’s start with these.
Use Outcomes When Uncertainty Is High
Despite the fact that I write a lot about outcomes, I still believe that setting your targets as outputs can be a good way to work. Outputs work well when you are confident that the thing you’re going to make will solve the problem. Building an e-commerce site? You’re going to need users to be able to log in, create accounts, check out, etc. No need to debate whether you need those features. Just build them.
On the other hand, we often work on problems where the answer is not so clear. That’s when we turn to outcomes. For example: our e-commerce platform is designed to allow groups of people to buy large lots of expensive items at a discount. How will that work? How will groups form? What features will those groups need? What will sellers need? When you’re building parts of a system when there’s a great deal of uncertainty—that’s a good time to use outcomes.
So my blanket advice for people who want to be more outcome-focused is to find a project where uncertainty is high and stakeholders might reasonably want to take an exploratory approach to reducing risk. Pilot your outcomes-centric approach on a project like this.
Pilots are important
My second piece of advice is related to the first. Don’t try to boil the ocean. Start small. Find the right project and start there, then build on your success (and failure). Outcomes have a lot of appeal to systems thinkers (like me :-) and we tend to want to tackle system-level problems. Resist the urge. Start small and grow.
Start Where You Are
Blanket advice only goes so far. Everyone’s context is different, and you’re going to need to take context into account when you try to adopt any method. So, here’s some advice to help you get started in some common situations that I’ve encountered in my work.
1. Your team has a contractual obligation to build specific things.
In this situation, it’s nearly impossible to switch to an outcomes-oriented approach. For example, if you work at a studio or product development shop, you typically have contracts with your clients that specify certain deliverables. Once you’ve got a contract like this in place, there’s almost nothing you can do to move from outputs (ie, your deliverables) to outcomes. The only way out of this bind is to write different contracts. At my last studio, we wrote contracts that were time-and-materials based. That model allowed us to work together with our clients to figure out the best output to create to help our clients achieve their desired outcomes.
If you’re in this situation, you can get started by working with your client to find a pilot project with a relatively high amount of uncertainty about the right thing to build. Then, work with your client to create a contract / statement-of-work that allows you to discover answers together.
2. You work in a large organization, and you divide work among teams by assigning specific deliverables to specific teams.
This one is similar to the contract problem. You’ve got an internal “contract” to produce certain things. Other teams are depending on you to produce a specific thing, so you can’t experiment with different outputs.
There are a couple of ways around this. One is to work with the group of teams to align around a specific outcome together, then assign each team a specific part of the problem. For example, perhaps you offer video editing software tools, and you want to increase use of your mobile app. Team A might work on making the setup process easier. Team B might work on making it easy to produce your first video. Team C might work on making it easy to post videos to social platforms, etc. In other words, segment the work by understanding the customer journey, and having teams improve outcomes in each part of the journey.
Sometimes though, your internal contract exists because another team is the internal customer of your work. For example, you might produce an API that other teams depend on. Or maybe you work on the design systems team. In both cases, other teams are dependent on your work to get their jobs done. Guess what, you have internal customers! You can optimize for their outcomes too. Your key measure here is usually adoption. Are we producing features that internal customers are adopting? Can we measure the usage of our work? Can we promise them better outcomes, not simply more features?
3. Your manager doesn’t want to give up the control that comes with outputs.
Being a manager is a hard job. You’re held responsible for the work of the teams that report to you, so you have an incentive to make sure they’re delivering results. Sometimes though, managers try to do this by diving down into the details and getting overly specific about directing the work. They mistake delivering stuff with delivering results. They’ll manage the team by specifying in great detail what stuff the team should make — in other words, they’ll dictate outputs.
With managers like this, it’s useful to help them reframe success. You want to show how, by reframing the team’s work in terms of outcomes, you’ll be more successful and in turn, help them be more successful.
4. Your leaders want to work with outcomes, but you and they are not sure how to get started.
This is an ideal starting place. Pick an initiative with some uncertainty. Pick one where getting it right will be valuable. Pick one where getting it wrong won’t be catastrophic. With your pilot identified, begin to map the outcomes you’re trying to create. Use impact mapping, or outcomes mapping, or journey mapping to understand the relationship between what people are doing and the results you’re seeing. Gather data. But don’t get lost in analysis paralysis. Just get started. Give yourself enough time (3 months?) to iterate.
Then blog about it, because we’d all love to hear how it goes!
What Have You Encountered?
Have you been trying to shift your work to be more outcome-focused? How’s it going? I’d love to hear from you. Leave a comment or shoot me an email with a question!
