OKRs ≠ Strategy

OKRs (objectives and key results) are a critical tool. I helped bring them to my last company. Using OKRs successfully made us more objective and quantitative in how we built products.

My favorite part of OKRs is the KRs (key results).

It’s easy to be sloppy in our thinking when conceiving product initiatives. We often prioritize doing things that we “know” must be done. But our intuition is riddled with biases. Assumptions about focus and scope are nested in each initiative.

Asking ourselves, “What is the key result for this initiative?” forces us to think about what matters to achieve the critical business outcomes. KRs are slicing mechanisms. Through the OKR process, we often discover short paths to outcomes that we previously assumed would require much more work. Sometimes, through contemplating KRs, we realize that projects we were convinced must be done actually don’t fit with company priorities and therefore shouldn’t be done after all.

One of the basic principles of OKRs is that they should not be task lists. If your key result is “We launched project X,” it means that you lack an objective measure of why project X is important.

While we’re taught that OKRs should orient around outcomes and not outputs, I’ve never been part of an OKR process where we don’t at some point give up and say, “Ok fine, let’s allow some of our OKRs to be our project list.”

It often unfolds like this:

We sit down to write OKRs only to realize that we don’t have the metrics we need to objectively measure our work. So then, we make a key result to instrument metrics. By the time our quarterly OKR cycle is over, we haven’t done the actual work. Or, if things go super fast, we made the metric and shipped the work, but we run out of time in the OKR cycle to see if our work achieved the result or not – it might take 180 days to know for sure. Then, in the next OKR cycle, we shift priorities and embark down a totally different road without closing the loop on the previous cycle of work.

Making your KRs a laundry list of projects to ship gets more tempting with each hour of OKR planning, even for those who start the process with pure intentions.

The root problem with how most companies do OKRs is that they enter the process with strategy debt.

John Culter describes it brilliantly in his article, Persistent Models vs. Point-In-Time Goals:

There is a big difference between persistent models and work (or goal) related models. OKRs, for example, are a work related model. Work related models involve a specific time-span (e.g. a quarter). The team attempts to achieve The Goal by end-of-quarter.

Meanwhile, a north star metric and related inputs persist for as long as the strategy holds (often 1-3 years ). The constellation of metrics serves as a belief map, driver diagram, or causal relationship diagram. It explains our mental model for how value is created and/or preserved in our product/system.

The North Star Playbook that John refers to is an example of how “strategy” can be expressed. For metrics-driven companies, a strategy is a model for (1) how types of events and work influence measurable outcomes, and (2) how leading indicators influence lagging indicators. It’s a map like this:

My last post, Metrics-driven product development is hard, explains the diagram in detail.

If you already have a strategy, that is, a persistent model of how your business functions, the OKR process is radically more effective and efficient.

Imagine starting an OKR process where everyone already knows the important metrics for the business and how previous work has influenced it. So instead of asking “what is a measurable key result for this initiative that we want to do?” you ask “what can we do to move this metric that is critical to the business?”

When a company lacks a persistent model of their strategy, people feel the gap and try to model their strategy in the form of OKRs. But using OKRs as the sole articulation of your strategy is toxic overkill. Not every metric that is important to your business should have a time-based goal tied to it at every moment. It’s OK to declare that a metric is meaningful without actively doing anything to move it. OKRs don’t have a concept of that. They're blunt instruments.

At DoubleLoop, we believe you should build a persistent model of your company strategy, in the style of the Northstar Playbook, before you do OKRs.

Here’s what a strategy visualization in DoubleLoop looks like (or watch the demo video):

By modeling a strategy that’s independent of time-based goals, you get a lot of the same benefits as OKRs. You clearly articulate the “why?” behind your work. With DoubleLoop, your strategy visualization is populated with live metric data so you can quickly see what’s working and not working in your strategy.

From there, you can selectively deploy your strategy with key results as needed. The majority of your metrics may not have key results at all. It’s fine to try to move a metric up or down without a clear target. It takes cycles of tinkering before you have a sufficient feel for the metric to design a key result for it.

In DoubleLoop, you can optionally add key results to metrics, as much or as little as you choose to. And you can update your OKRs whenever the time is right, which is probably not quarterly.

Branches of your product strategy will likely stay fixed for long periods of time, even years. You shouldn’t feel like you have to revise the whole thing every quarter. Some branches of your strategy might change every week, others might never change.

Focusing first on the persistent model of your strategy is your ticket off the quarterly OKR hamster wheel.

Thanks to John Cutler and Sumit Gupta for reviewing a draft of this article.