Beyond “Outcomes Over Outputs”

Consider a range of mission-types (or mission scopes) for a product development team:

1. Build exactly this
2. Building something that does [some operation, some workflow]
3. Building something that lets customers do [some task]
4. Solve this customer problem
5. Improve the experience for [some segment of users/customers]
6. Optimize this metric
7. Generate this short-term business outcome
8. Generate this long-term business outcome

I often meet with teams/individuals that are eager to be more “outcome oriented” (3/4+). The reasons vary, but center mostly on 1) the belief that it will create better outcomes for the business, 2) that “the business” somehow doubts or diminishes their expertise and just chases success theater, and 3) the desire for more challenging, impactful, and intellectually rigorous work.

“Outcomes vs. Outputs” has become a rallying call for consultants, individuals, and teams alike. What’s not to like, right?

The other day I asked a team in this situation whether they would undertake a “Build exactly this…” effort if they knew it was going to be beneficial to the business.

Of course we would! But…(all the reasons that never happens)

Which got me thinking. You have to divide the issue.

How does the company:

• make the best product decisions possible?
• connect those product decisions to a coherent high-level product strategy?
• show real impact — connect even the most prescriptive work/actions all the way up to high-level business results (essentially “walking the tree” from 1 to 8 above)? Prescriptive or not, did it work?
• talk about uncertainty and nested bets/assumptions. Namely, address the fact that most “problems” (even very open ended goals like 6 “Optimize this metric”) are in themselves solutions to higher level problems/goals? Are there fundamental bets which are beyond question…at least in the near/mid term?
• engage employees both in terms of linking their work to real impact AND allowing them to flex from a career perspective by enjoying more autonomy, flexibility, and room for creativity?

These are important distinctions because many organizations lack the ability to link anything non-sales related to impacts and/or larger strategic bets, let alone to empower front-line teams to deliver outcomes. Even sales targets are in “service” to short-term business outcomes (not long term viability of the business, the mission, etc.). Additionally, there is zero awareness on the part of teams — or most staff, even — about the higher level assumptions and “bets” driving more prescriptive near-term goals and how it all “fits together”. So…the issue is way beyond “empowering” teams (though that is important). Sometimes product teams will need to build “exactly this”… then what?

Consider the spectrum here ranging from 1–3 hour tasks to 3+ year foundational bets for the company. Before talking about whether Team A should be given a rough mockup, or be tasked with doing their own research, you should probably map these horizons for your company. How does it all fit together?

Because even if Team A is tasked with “solving this customer’s problem” (4), you’ll still need a way to connect it to short and long-term business outcomes. If you can’t, you’re just getting bogged down in a theoretical discussion on team autonomy and whether it leads to a subjectively better near-term, lower-level outcome. (This is why the “outcomes vs. outputs” discussion tends to stall, and settle on generating some short-term customer “outcomes”).

Here’s another take on a “bet graph” from Henrik Kniberg’s Spotify Rhythm talk:

This type of coherence is rare when focusing on near-term outcomes only.

A great example of the problem is how OKRs (objectives and key results) are commonly perceived by individuals and front-line teams. Near-term goals are almost by definition more prescriptive, even when stated as quantitative “results”. When I ask front-line folks — product teams especially — about their OKRs, I invariably hear something like:

These are all well and good, but I don’t know how this all fits into the bigger picture. What we’re doing now is laying the groundwork for success in future quarters and years. And what about the goals these tie into beyond this quarter? Are people held accountable for whether those things work out? Or do they wipe the strategy slate clean every year and start over? How do we hold ourselves accountable to measuring whether the strategy is actually working?

Hitting the OKR is not enough. Knowing that hitting the OKR will drive some future outcome that is 1) impactful for the business, AND 2) meaningful for the employee is vitally important, and something lost in various incantations of MBO (management by objectives). Why? Without the underlying coherent story — spanning multiple time horizons — the OKRs are just a process hoop, and without “closing the loop” there is no learning:

Does anyone ever go back and check whether hitting the OKRs made any difference? Or for that matter, when we build stuff — either taking orders, or coming up with it ourselves — do we ever go back and review our decisions?

Really, it’s the CONTEXT that matters, as Spotify noticed when they shifted away from OKRs on the individual level:

We noticed that we were putting energy into a process that wasn’t adding value. So we decided to ditch it and focus on context and priorities instead. We make sure everyone knows exactly where we are going and what the current priorities are, and then we let the teams take responsibility for how to get there.

What I think I’m getting at with this post is that “outcomes over outputs” or “evidence-driven development” or “beat the Feature Factory” sounds great. It really does. I personally believe that teams tasked with generating outcomes (vs taking tickets) are more likely to generate positive outcomes for themselves, their business, their customers, and sometimes even society. I’ve written extensively about Feature Factories. But it takes a ton more than intent, and you will always have a spectrum of nested bets of varying time horizons, levels of certainty, levels of prescriptiveness, and “up-for-debate”-dness. In other words, you think the problem is just outcomes over outputs and “trusting the teams”, when in fact the issue runs a good deal deeper.

It takes:

• Short(er) feedback loops when possible
• A coherent map/graph of short, mid, and long-term bets
• A willingness to review all decisions and impacts… prescriptive, or otherwise, short or long-term, experiments or “foundational” bets
• A way to link every action — even the mundane daily ones — to that map of short, mid, and long-term bets
• Beyond “bets” … a way to share and build a deep understanding of the company’s strategy, core beliefs, and the “why”
• Talking about uncertainty, the quality of decision making in conditions of uncertainty, and the enivitable failures
• Trust in expertise, and a willingness to nurture and develop team members and their desire for more autonomy and responsibility. Employee “engagement” beyond throwing teams a bone by letting them “solve a problem”

It’s my belief now that the “outcomes over outputs” refrain is more of a proxy discussion for a couple 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.

So, in summary…consider where your teams operate. Map the everyday work back to foundational company bets, and accept the uncertainty in everything. And finally consider whether it is more a question of context/story, outcome awareness, and coherence across the full “bet graph”, than whether Team A builds from a mockup.

Every problem is a nested solution to a higher level problem….