“Outcomes over outputs” sounds great — but why is it so hard?
The tech industry holds “outcomes over outputs” as an axiom.
Outputs are what we build. They’re the features we ship, the user stories or epics we produce, the bugs we fix, and the code we put into production.
Outcomes are the differences we make as a result of our output. They’re the user problems we solve, the possibilities we discover, and the behavior we change.
The reasons for focusing on outcomes instead of outputs are clear:
We’ll save time. We don’t spend time working on features that don’t produce the result we want.
We’ll stay customer/user-focused. Customers don’t want features, they want their needs met.
We’ll create more value for our business. Solving customer problems increases our bottom line.
Product management veteran Jeff Patton summarized it well in User Story Mapping:
“Your job isn’t to build more software faster. It’s to maximize the outcome and impact you get from what you choose to build.”
Despite outcomes over output being noncontroversial, most companies rarely practice this. This essay is an attempt to understand why.
Few companies actually focus on outcomes
I once talked to an Engineering Manager at Spotify about their read on its agile culture:
“Most people think we’re perfect at agile. We’re not. Our cultures and beliefs about agile differ from city to city, office to office.”
Spotify, a company revered for its outcome-oriented culture, still has room to grow. Let that sink in for a second.
While I don’t have numbers on this, my hunch is that few companies have it in their DNA to focus on outcomes. I’d guess that Google, Amazon, Netflix, Facebook, Airbnb, and Spotify do, but I can’t say for sure (I’ve never worked there). Even if it’s in their DNA, I’m sure each company has room to grow.
John Cutler, Product Evangelist at Amplitude, did a survey on practices product teams do. In it, folks reported that…
less than 20% of teams do “actual” User Stories
less than 5% of teams actually acknowledge failed projects
less than 5% of teams practice outcome-based roadmapping
less than 1% of teams used metrics tied to customer value
We know that focusing on outcomes is good, but few teams actually do it. And organizations that do champion it still have room to improve. Why is that?
There’s gotta be a million reasons, but let’s highlight three.
Why Focusing on Outcomes is hard
Reason #1: Maximizing outputs is often rooted in larger, systemic forces
Say you’re starting a new job as a Product Manager at a large, well-known tech company. You’re stoked about helping your team focus on outcomes instead of outputs.
Your boss tells you you’ll get a bonus if your team averages 40 points per sprint.
At your first all-hands, you hear leaders talk about ”the numbers”, how the company is doing better than its competitors, and the latest features shipped.
You ask your team how familiar they are with agile and they say ”very familiar,” but when you ask them what business outcomes they’re focused on, you hear “we’re not sure, but here’s what we shipped.”
In other words, you realize you’re working in a feature factory. Your bonus is tied to your team’s velocity, your leaders care most about maximizing output, and your team isn’t clear on how their work impacts the business.
How do you counteract a culture that’s focused on maximizing output, especially when you’re a new PM trying to put your best foot forward?
Making the shift towards focusing on outcomes means we have to surface our organizational assumptions. These are assumptions behind incentives, budgeting, strategy, team autonomy, hierarchy, and safety.
“It’s my belief now that the ‘outcomes over outputs’ refrain is more of a proxy discussion for a couple of deeper discussions around incentives, pull vs. push management, coherence, psychological safety, transparency, building trust and autonomy as a team, strategy, and focus. It’s the convenient, no-brainer, never-lose tagline. Who doesn’t want outcomes? But when we frame these other questions, it gets more nuanced.”
Reason #2: Sometimes we have to experience the cost of not changing
We don’t practice what theory tells us unless we see that it solves a problem for us. And we usually don’t see that it solves a problem until we experience some pain or friction.
A friend of mine who’s a CTO at a fintech company put it well:
“Most fintech companies go through a phase of endlessly pumping out features before realizing they need to focus on outcomes. Fintech companies try to beat their current competitors on features. Then, a new player comes out and does what that company does, but cheaper, or better on other areas that different customers care about.”
It’s sort of like telling people they need to exercise. We know the benefits of exercise, but we don’t do it until we see belly fat, feel a dip in our energy levels, or even experience depression.
Sometimes we have to experience the costs of maximizing outputs to make room for a different approach.
Reason #3: We bias towards action at the expense of making sense of our context
Say you’re a product leader stoked on outcomes over outputs. You decide to push this philosophy onto your team. You ask your PMs to read User Story Mapping and implement it with their teams.
Turns out it didn’t work. Your PMs found ways to go around it, because they’re incentivized to maximize outputs (Reason #1).
Copying a solution from a different system and pasting it into our own often backfires. We saw this with design leaders copying Buzzfeed’s product design roles for their own team:
“The reality is that the BuzzFeed role documents are just that: BuzzFeed’s role documents. They were written by myself and other BuzzFeed Design Managers, for the team we wanted to build, within the context of BuzzFeed as a company. They reflect our biases, whether toward totally transparent design processes or designers writing code, and are the result of years of learning and iteration. Through that lens, it makes a ton of sense that those same documents can’t and shouldn’t be airdropped into another organization”
Organizations are complex systems (or systems with a large amount of interacting components). And complex systems don’t have predictable solutions because of the volume of interactions between components. Solutions in a complex system are created by probing, sensing, and responding, rather than pulling some framework off the shelf.
Putting yourself again in the product leader’s shoes, what you could do is share the opportunity to your team (“What would it look like for us to focus on more outcomes instead of outputs?”) and invite them to craft an experiment. Your system will tell you whether the experiment is going in the right direction or not. And your team will thank you for it.
Knowing is different from doing
Few companies are outcome-focused because knowing is very different from doing. Focusing on outcomes instead of outputs is a cultural shift, and if we don’t want this shift to backfire, we have to examine our own assumptions before taking action. Knowing this, I hope we’ll be more empathetic toward why this gap exists as we continue to maximize our impact.
What else gets in the way of focusing on outcomes? What have you seen?