Thinking beyond Outcomes in OKRs

One of the most common quotes I hear from product teams or companies who have tried OKRs is that "it didn't work for them." Often, these companies tried to follow a blueprint of how to use OKRs (usually from a different company).

The reason why we seek a cookie-cutter approach for adopting frameworks like OKRs is that we want to be sure that we're doing it "right." At least that's how I felt when I got started using OKRs. I was continually seeking feedback or validation if my Key Results were "good" Key Results or if the meeting formats we had chosen were "correct." 

Over time, I had to learn that the main benefit of using OKRs doesn't come from adopting a one-size-fits-all process. It's about clarifying why you want to use them in the first place and how they will benefit your organization. This clarity is also vital for product teams that want to avoid OKR Theater.

The main benefit of using OKRs doesn't come from adopting a one-size-fits-all process. It's about clarifying why you want to use them in the first place and how they will benefit your organization.

For example, you might wonder is a Key Result "wrong" if it doesn't describe an Outcome? That’s a question I often hear when I start working with product teams struggling to make OKRs an amplifier of their work. Instead they find themselves overthinking their Key Results. OKRs can and should act as a powerful north star for product teams. But they shouldn't overshadow the practical effectiveness of a Key Result.

To me, that means: Outcomes over Output, but not at all costs.

Outcomes over Output, but not at all costs

Setting Outcome OKRs creates great benefits for product teams. They get more autonomy to pursue their product goals on their own, and they measure progress towards a result instead of ticking off tasks.

But there’s a risk in focusing exclusively on Outcome OKRs: it can lead to teams that lack a supportive environment or the right skills remaining stuck. Out of fear of not doing things right from the start, they would rather wait for the perfect moment instead of starting their journey toward Outcomes—even if it means utilizing Outputs to measure progress and success temporarily.

While the current emphasis on Outcomes enables all sorts of potentially positive changes for product teams, we, as an industry, are close to creating a Dogma. The dogma of only being a “real” product team if you focus on Outcomes. The dogma that Outcome OKRs are the only right way to utilize OKRs. The dogma of doing a thing right, before doing it at all, to learn from it.

The dogma of Outcome OKRs can lead to product teams being paralyzed by the attitude of having to do a thing right, before doing it at all, to learn from it.

And there’s a second risk: Outcome OKRs do not automatically lead teams toward creating and measuring success. It’s entirely possible to define Key Results that describe a behavior change but aren't measurable within and don’t change throughout a goal cycle. Therefore, teams need to be aware of whether they define their Key Results as Outputs or Outcomes AND how leading or lagging these Key Results are.

Ultimately, the decision to balance Outputs and Outcomes and leading vs. lagging indicators shouldn’t just be the result of a colorful matrix. It should be guided by your individual OKR System and it should help you use OKRs as a framework for setting and measuring goals in YOUR company.

Getting Started with Key Results

In an ideal world, an effective Key Result ticks three boxes:

• It's influenceable by the Product Team that came up with it.
• It changes at a cadence that allows the team to react and adapt its priorities.
• It describes a change in behavior rather than a task or feature.

But many product teams might not be able to meet all three criteria in their OKRs. Others may not have the inputs and data to articulate Outcomes. So, what to do in such situations? Do you try to pull Outcomes out of thin air and gut feeling? Or do you prioritize more Output-ish Key Results for the following cycle in order to generate user insights?

I believe that the latter is the more effective choice for most teams that are struggling with this. Instead of holding out to define Outcome OKRs until you “automagically” have all the correct data at hand, get started with what you have right now.

Instead of holding out to define Outcome OKRs until you “automagically” have all the correct data at hand, get started with what you have right now.

Even though Output Key Results may look like a glorified task list, continuously measuring the progress towards achieving them is a significant change from how most teams track progress. Utilizing OKRs with Outputs gives you at least an objective list of priorities and creates a regular occasion to discuss your progress.

Here are some common situations Product Teams encounter in defining Key Results and how to address them:

Prioritizing Leading Indicators

One thing that differentiates OKRs from other goal frameworks is the continuous revisiting of progress and adjustment of actions. After all, what's the point of setting and measuring a goal that checks all the boxes of being an Outcome but doesn't help you adjust your actions along the way?

What's the point of setting and measuring a goal that checks all the boxes of being an Outcome but doesn't help you adjust your actions along the way?

But a too rigid focus on Outcomes could result in a lack of feedback. If you limit yourself to “by the book” Outcomes at all costs, there’s a high chance that you end up with metrics that are 100% “certain,” but only measurable in hindsight.

If your primary goal for using OKRs is to shift people's mindset toward Outcomes, then, sure, a lagging Outcome KR might do the job. But if OKRs are used as a practical tool to measure progress and adjust priorities continuously, you need to identify more leading indicators.

If OKRs are used as a practical tool to measure progress and adjust priorities continuously, you need to identify more leading indicators.

Use leading indicators to enhance how you work today to avoid making decisions based on feedback that arrived too late to inform your work. Whether that leads to a more Outcome-ish or Output-ish KR should only depend on what type of Key Result helps you in your everyday decision-making.

This chart shows how leading and lagging indicators could align with different kinds of Key Results:

Taking the First Steps

For every product team that gets discouraged by an over-glorified definition of Outcomes, I would love to see at least one not holding back and instead getting at it. No matter how imperfect their starting point might be.

Don‘t follow a prescribed approach someone else came up with. Instead, gather the experiences from your experiments in YOUR context, solving YOUR challenges. And use the learnings from this journey to find your own approach to OKRs.