Consider a range of mission-types (or mission scopes) for a product development team:
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:
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”).
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’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….