A retailer's KPI dashboard carried a churn line for eleven straight quarters: "Customer churn rate, target under 5%." It sat between "warehouse pick accuracy" and "call centre first-response time," reviewed in the same five-minute scroll as both. For most of those quarters it held near target. Then a low-cost competitor opened online in the same category, and churn drifted to 7%, then 8%, then 9%, one steady climb with no single quarter dramatic enough to trigger anything. Nobody owned a decision about it, because a KPI doesn't ask for one. It just asks whether the number is still where it's supposed to be. By the time anyone asked what the company was actually going to do about the competitor, eighteen months of erosion had already happened under a metric that looked, every quarter, like routine.
That's the failure this pair of instruments is built to prevent, and it goes wrong in both directions.
An OKR (Objectives and Key Results) commits to changing something that isn't true yet. A KPI (a Key Performance Indicator) holds a line you already hold. Neither is the better instrument. Each is the wrong one for what the other is for.
The real difference is the layer, not the format
Most comparisons stop at format: an OKR is a qualitative goal with a few measurable results, a KPI is a single ongoing number. That's true and it's not the useful part. The useful part is what each instrument is for.
An OKR is for the strategic bets, the new capability, the transformation, the things that don't work yet and that someone has chosen to make work. A KPI is for the steady-state work that already runs the business: the payroll that has to clear, the server that has to stay patched, the support queue that has to hold its service level. Force the steady-state work into OKRs and the few real bets drown in routine, every objective collapsing into a version of "deliver everything we were already doing." File a real bet as a KPI, as the retailer did with its churn line, and it stops getting the scrutiny a bet requires. It becomes a number that's allowed to drift for a year and a half before anyone treats it as a decision rather than a data point.
Side by side
| OKR | KPI | |
|---|---|---|
| Answers | What are we choosing to make true? | Are we holding the line we already hold? |
| Before you start | Not yet true. That's the point. | Already true, and meant to stay that way. |
| Owner | The team making the bet | The team running the operation |
| Reviewed | Quarterly, against progress on the bet | Continuously, against a threshold |
| Green means | The bet is working | Nothing has broken |
Two ways to get it wrong
Steady-state work forced into an OKR. "Keep average response time under four hours" is a KPI wearing an OKR's ceremony: a quarterly tracker, a confidence score, a review meeting, none of it changing what the metric actually is, which is a line the team is holding, not a bet it's making. When Your OKR Is Really a Task List covers this direction in full, including how to spot it before it eats a whole planning cycle.
A real bet filed as a KPI. This is the direction the churn line shows, and it's the one that gets missed more often, because a KPI dashboard has no field for "this used to be routine and isn't anymore." The tell is a metric that was fine for years and has started drifting, reviewed at the same cadence and with the same shrug as everything around it. The fix isn't a better target. It's promotion: someone has to notice the world changed, pull the number out of the steady-state review, and turn it into an Objective with a theory behind it, a chosen segment to defend, a capability to build to defend it, the same Missing Middle any real OKR needs. A KPI that's drifting is not a KPI problem. It's an OKR that hasn't been written yet.
Both, on the same team, at once
They're not alternatives. A single function usually needs both running at the same time, aimed at different things.
| Function | KPI (steady-state) | Objective (the bet) |
|---|---|---|
| Customer support | Average response time under 4 hours | Make first-contact resolution real for the customer calling about our three most common problems |
| Retail operations | On-time delivery rate above 97% | Make click and collect the shopper's default for the customer we've chosen to win |
| Finance | Days sales outstanding under 45 | Make same-day cash application the norm for the finance team, not the exception |
| Engineering | Uptime above 99.9% | Make a new customer's first integration something they finish themselves, not something we spend six weeks doing for them |
Look at retail operations. The click-and-collect Objective didn't replace the delivery-rate KPI; it ran alongside it. The KPI kept the existing promise to shoppers honest while the OKR went after a new one. That's the shape to aim for in any function: a KPI holding what already works, an Objective aimed at what doesn't work yet, both visible in the same review rather than competing for the same slot on a tracker.
The two questions that sort it
Before you decide which instrument a metric belongs in, ask this in order.
Is it true right now? If yes, and the job is to keep it true, it's a KPI. Set a threshold, review it on a normal cadence, move on.
Is it not true right now, and has someone actually chosen to make it true? If a metric is drifting and nobody has made that choice yet, it's not an OKR candidate. It's a KPI that needs a decision before it earns the promotion. Write the OKR only once the choice exists behind it, not as a way of manufacturing urgency around a number nobody has actually decided what to do about.
This is the other half of what an OKR is: not just the shape of the instrument, but which of the two jobs it's built for. The OKR pillar has the full Missing Middle argument behind both directions of this failure. The Closing the Strategy-Execution Gap course teaches the full chain from choice to capability to Key Result.