Author: Jeff Gothelf & Josh Seiden
Date read: Feb 22, 2020 —Mar 6, 2020
Format of book: Paper
Link to book: https://www.amazon.com/Outcomes-Over-Output-customer-behavior/dp/1091173265
Link to Podcast: https://www.mindtheproduct.com/outcomes-over-outputs-josh-seiden-on-the-product-experience/
In the old days, when we made physical products, setting project goals wasn’t that hard. But in today’s service- and software-driven world, “done” is less obvious. When is Amazon done? When is Google done? Or Facebook? In reality, services powered by digital systems are never done. So then how do we give teams a goal that they can work on?
Mostly, we simply ask teams to build features — but features are the wrong way to go. We often build features that create no value. Instead, we need to give teams an outcome to achieve. Using outcomes creates focus and alignment. It eliminates needless work. And it puts the customer at the center of everything you do.
Setting goals as outcomes sounds simple, but it can be hard to do in practice. This book is a practical guide to using outcomes to guide the work of your team. “Josh’s crisp volume brims with insight about how to fly at just the right level — the level of outcomes. If you’ve ever wondered how M your MVP should be, or how to get more R in your OKRs, this book will help.” — Nick Rockwell, CTO, NY Times
Outcomes over Output is an insightful idea that helps us determine what work to focus on and how to measure it. Outputs, in the software world, are the features we build for customers, which may or may not bring value. Outcomes are the measurable human behaviors we’re seeking to drive results.
Honestly, I read this book because I liked the title and goodreads reviews. I’ve been interested in other ways in measuring work and understanding ideas like OKRs better.
Output: The features we create that leads to an outcome.
Outcome: The change in (customer/employee/company) behavior we’re seeking that provides value.
Impact: The high-level impact that the outcome is having.
No disagreements. I can see how thinking in Outcomes would take a mental shift and extra effort upfront.
Chapter 2 — Using Outcomes
I think this chapter had the most definitive definition and practical application of Outcomes over Output.
An outcome is a change in human behavior that drives business results. Outcomes have nothing to do with making stuff. Though they sometimes are created by making the right stuff. Instead outcomes are the changes in customer, user, employee behavior that lead to good things for your company, your organization, or whomever is the focus of your work (p. 12)
It's common to get caught in this kind of confusion — mistaking “making stuff” for making progress, and mistaking shipping features for being done…But when you're making software products, Done is less obvious. When is Microsoft Word done? When is Google done? Or Facebook? In reality, software systems are never done. (p. 13)
Outcomes, or the human behaviors that drive business results, are what happens when you deliver the right features. Ideally they happen when you've delivered as few features as possible. (p. 14)
You can manage the team by telling them what to make: that’s called managing outputs. It’s a problem because features don’t always deliver value. You can manage a team by asking them to target some high-level value, like growing revenue. That’s called managing impact. It’s a problem because it’s not specific enough. What you want is to manage with outcomes: ask teams to create specific customer behavior that drives business results. (p.16)
When you combine outcome-based targets with a process that's based on running experiments, you really start to unlock the power of agile approaches. (p. 18)
To find the right outcomes to work on, we start with a simple question: “What are the customer behaviors that drive business results”… Because outcomes are things people do, they're both observable and measurable. This is incredibly important part of outcomes because it lets us use them as a management tool. (p. 25)
So, outcomes let you write better OKR by asking you to step back from your work, consider the meaningful business results that you're trying to achieve and express all that in easy-to-measure terms of customer behavior. (p. 35)
Instead of building plans around the outputs that you'll make, it often makes more sense to plan around themes of work, problems to solve, or I'll comes to deliver. (p. 40)
This is a critical part of orienting your workaround outcomes: if you're trying to figure out what is going to work for your users, you need there early feedback in order to steer your progress, which in turn requires early collaboration across the whole team. (p. 53)
I think someone with any role in an organization could get something valuable out of this book. The customer focused and measurable outcome approach is very appealing and makes a lot of sense.