Three more reasons “outcomes over outputs” is hard

“Outcomes over outputs” is an axiom in tech. Yet most companies are still output-focused.

Last month, I wrote an essay that tried to understand why so few companies work in an outcome-focused way. I came up with three reasons:

  1. Maximizing outputs are rooted in larger systemic forces.

  2. Meaningful change starts with experiencing the cost of not changing.

  3. We bias towards action at the expense of making sense of our context.

I asked others for reasons they’ve seen, and folks’ responses got me to think more bit more about it. This essay is a follow up from my last essay that shares three more reasons why it’s hard for companies to be outcome-driven.

Note that these reasons aren’t mutually exclusive from our initial three reasons. Organizations are complex systems, and complex systems have a way of intertwining problems, as we know.

1. We’re not careful about what we measure.

We make what we measure, and we often measure arbitrary metrics.

“Since we’re seeing our daily active users go up, page views go up, velocity going up, and time on page going up, we’re killing it, right?!”

Metrics like daily active users, page views, and velocity rarely tell us anything about the value we’re creating for our users. If these metrics go up or down, that doesn’t tell us what we should do differently. However, we don’t challenge them. Our leadership cares about them, our boss cares about them, our bonus is tied to them, and frankly, they’re easy to measure and manipulate.

Paul Graham puts it well in thirteen sentences for startups:

7. You make what you measure.

…Merely measuring something has an uncanny tendency to improve it. If you want to make your user numbers go up, put a big piece of paper on your wall and everyday plot the number of users. You’ll be delighted when it goes up and disappointed when it goes down. Pretty soon you’ll start noticing what makes the number go up, and you’ll start to do more of that. Corollary: be careful what you measure.

Because we know it’s in our nature to improve what we measure, we need to choose ones that reflect the value we strive to create. Otherwise, we risk destroying our company:

If you give a manager a numerical target, he’ll make it even if he has to destroy the company in the process.
— W. Edwards Deming

2. We can’t serve our customers with a traditional budgeting process.

Consider this anecdote that Melissa Perri shared in Breaking the Build Trap:

‘They turn all these business cases into a giant roadmap for the year, give them out to each team, and fund the projects. At the end of the year, if they do not deliver what’s on the roadmap, they do not get as much funding next year.’ ‘Do you realize what that means, Melissa?’ he asked me. ‘That means that, if a team finds a way to build a product cheaper — or finds that the product shouldn’t be built at all — they are building it anyway because they will be penalized if they don’t spend all their money.’

It’s asinine that many “product-led” companies budget with the assumption that their yearlong roadmap is what’s most valuable to their business and user.

I’d also suspect that these business cases are based on zero user research. Which means we’re spending tremendous time and resources building features with zero-to-little evidence that our users want these features.

In short, the same companies that vow to stay close to the customer, so that they can respond quickly to precious intelligence about market shifts, cling tenaciously to budgeting — a process that disempowers the front line, discourages information sharing, and slows the response to market developments until it’s too late.
— Jeremy Hope & Robin Fraser (in HBR’s Who Needs Budgets?)

It’s impossible for customer-facing teams to sense and respond if their organization’s budgeting process disempowers. True outcome-driven companies allocate their resources on-demand, which minimizes costs and allows teams to be responsive to their customer’s needs.

3. We use a framework to be more outcome-driven, and it backfires.

As a framework nerd, I fall into this trap constantly. “What’s a framework I can use to nudge my client/company to work in an outcome-driven way?” Somehow, frameworks trick our brains into thinking two things:

  1. Frameworks will convince our clients, managers, and teams that “our” way of working is superior

  2. Frameworks are the end-all-be-all solution

So we try the framework. And guess what? It doesn’t work. In fact, everyone hates it. We get discouraged and go back to working in the old way.

The flaw with going all-in on a framework is that we don’t clarify the actual outcomes we’re trying to improve. We treat “outcomes over outputs” as a methodology problem rather than a service design problem.

No framework will produce contextual positive change. In fact, going all-in on Holacracy, agile, OKRs, or Spotify squads can actively perpetuate the same command-and-control, predict-and-plan, and manage-by-objective habits you’re trying to eliminate.

So if frameworks don’t work, what will? Small time-bound experiments.

How do you create small time-bound experiments? Go back to the ole Lean Hypothesis, but apply it to your team/org:

We hypothesize by <implementing this change>, we will <solve this problem>, which will have <these benefits> as measured by <this metric>.

Don’t look for how we can be like X or work in Y way. Envision how we can produce better outcomes, and design for that.

Not being outcome-driven is a symptom of a larger problem

Again, three more reasons it’s hard:

  1. Most metrics don’t measure customer value.

  2. Most budgeting processes prevent teams from solving their customer’s problems.

  3. Most frameworks backfire our attempts at driving meaningful change.

Transitioning from outputs to outcomes will be messy. The reason is it’s a symptom of a larger problem that has to do with how your company measures, budgets, allocates resources, distributes authority, shares information, fosters trust, and creates psychological safety.

If your organization isn’t outcome-focused, resist your initial instinct to solve it. Seek the problems behind this problem, clarify the outcomes you want to improve, and propose experiments that may achieve these outcomes.