Optimize one OKR metric hard enough and people will hit the number — by routing effort away from whatever the metric was supposed to represent. This is Goodhart's law in action: a target creates a reinforcing loop that inflates the measure, and a balancing loop that quietly drains the unmeasured goal it was meant to protect.
Goodhart's law isn't a warning about bad people gaming metrics — it's a prediction about system structure. Any target strong enough to change behavior creates two loops at once: one that chases the number, one that sacrifices whatever the number left out.
Goodhart's Law Is a Systems Problem, Not a Willpower Problem
Goodhart's law states that any measure, once it becomes a target, stops being a reliable measure. The fix isn't hiring more disciplined people — it's recognizing that a target is an intervention that reshapes behavior, not a passive readout of it.
The law traces to economist Charles Goodhart, who observed in 1975 that UK monetary indicators broke down the moment the Bank of England started targeting them. The version PMs actually quote — "when a measure becomes a target, it ceases to be a good measure" — is anthropologist Marilyn Strathern's 1997 paraphrase, written while studying how audit culture distorted British universities.
A closely related idea, Campbell's law, from social scientist Donald T. Campbell, adds the mechanism: the more a quantitative indicator is used for decision-making, the more it becomes subject to corruption pressures and distorts the process it was meant to track.
Both laws describe the same structural fact: measurement is not neutral once stakes are attached to it. An OKR isn't a thermometer sitting outside the system reading the temperature. It's a lever inside the system, and pulling it moves other things too — usually the things nobody put a number on.
This matters because most OKR post-mortems treat gaming as a culture failure ("we need better values") instead of a structure failure ("we built a loop that rewards the shortcut"). Jerry Muller's 2018 book The Tyranny of Metrics documents this across medicine, policing, education, and business: wherever a single number becomes the basis for reward, people — rationally, not maliciously — optimize the number.
- Teachers taught to the test when test scores became the target.
- Surgeons avoided risky-but-necessary operations when "success rate" became a public scorecard.
- Call center agents rushed customers off the phone when "average handle time" became the KPI.
None of these required villains. They required a target and a system smart enough to find the cheapest path to it.
The Two Loops Hiding Inside Every OKR
Every gamed metric has the same skeleton underneath it: a reinforcing loop that pushes the number up, and a balancing loop that trades something else away to keep pushing it. Naming both loops — instead of just the number — is what separates an OKR review that catches gaming from one that celebrates it.
If you haven't mapped these loop types before, the complete guide to systems thinking for product teams and the deeper breakdown of reinforcing versus balancing loops in growth are the right background reading. Here's the compressed version for OKRs specifically.
The reinforcing loop: chasing the number
A team sets a target — say, DAU growth. Management attention, roadmap slots, and incentive pay all point at that number. More attention produces more tactics aimed squarely at moving it. Moving it produces praise, which produces more attention. This is a classic reinforcing loop: success feeds more of the same behavior, with no natural ceiling.
The balancing loop: sacrificing what wasn't measured
Reinforcing loops don't run in a vacuum — they draw on a finite resource. Chasing DAU through notification frequency draws down user goodwill. Chasing "tickets closed" draws down actual problem resolution. Chasing "commits per engineer" draws down code quality. As the resource depletes, the underlying goal (trust, resolution, quality) degrades even while the tracked number climbs — a balancing loop working in the opposite, unmeasured direction.
| Loop type | What it optimizes | What it depletes | Where you'll see it first |
|---|---|---|---|
| Reinforcing (visible) | The tracked metric itself (e.g., DAU, ticket count, commit count) | Nothing — it looks like pure success | Weekly OKR dashboard, all green |
| Balancing (invisible) | Nothing directly — it's a side effect | The unmeasured goal the metric was a proxy for (trust, quality, resolution) | Support tickets, churn cohorts, qualitative feedback — weeks or months later |
The trap is structural: the reinforcing loop reports in real time; the balancing loop reports late. Leadership sees the green dashboard long before they see the damage, which is exactly why Goodhart's law survives contact with smart, well-intentioned teams quarter after quarter.
Case Study: How DAU-Chasing Notifications Poison Trust
Set DAU as an unqualified OKR target and the fastest lever any team finds is notification frequency — because it's cheap, immediate, and directly correlated with opens. The mechanism is textbook Goodhart: the metric goes up while the goal it stood in for, durable engagement, goes down.
Walk the loop step by step:
- Product sets a target: "Grow
DAUby 15% this quarter." - Growth team ships more push notifications, badge counts, and re-engagement emails.
- Short-term opens spike.
DAUclimbs. The OKR check-in turns green. - Users experience the notifications as noise, not value — because many of them weren't triggered by anything the user actually did or wanted.
- Some users mute notifications. Others uninstall. A subset simply stop trusting the app to respect their attention, which shows up nowhere on this quarter's dashboard.
- Weeks later, retention curves for the "spiked" cohort bend downward faster than baseline.
DAUgrowth stalls or reverses — but by then it's attributed to seasonality, a competitor, or "market conditions," not the notification strategy that caused it.
That gap between cause (step 2) and visible consequence (step 6) is a delay — one of the most dangerous elements in any feedback system, because delays hide the balancing loop until it's expensive to reverse. If this pattern sounds familiar, the mechanics of exactly this lag are covered in how delays in feedback loops quietly wreck retention and churn.
The uncomfortable part: nobody on the growth team did anything against their incentives. They hit the DAU target exactly as instructed. The system did precisely what it was built to do — it just wasn't built to protect trust, because trust wasn't the metric.
A target measures what's cheap to move, not what's valuable to protect. If the cheap lever and the valuable goal aren't the same thing, the cheap lever wins — every time, without exception.
Where Goodhart's Law Hides in Common OKRs
Most Goodhart failures are predictable in advance, because the gaming path is almost always the shortest path between the current state and the number. Below is a pattern you can run against your own OKR set before the quarter starts, not after the retro.
| OKR metric | Cheapest gaming path | What actually erodes | Paired guardrail metric |
|---|---|---|---|
DAU / MAU | Notification volume, auto-play, dark-pattern re-entry loops | User trust, notification opt-out rate, brand sentiment | Uninstall rate, notification opt-out rate, session initiated without a push |
NPS | Survey timing (ask right after a win), suppressing detractors from the sample | Honest signal on real satisfaction | Response rate, verbatim sentiment analysis, CSAT at point of friction |
| Support tickets closed | Premature closure, deflecting to self-serve without resolving | Actual problem resolution | Reopen rate, CSAT on closed tickets |
| Feature shipped count | Shipping trivial variants, splitting one feature into many "launches" | Product coherence, engineering debt | Adoption rate per shipped feature, post-launch usage decay |
| Sales-qualified leads | Loosening qualification criteria | Downstream conversion quality | SQL-to-close rate, sales cycle length |
| Code commits / velocity | Small, low-value commits; padding story points | Code quality, architectural integrity | Bug rate per release, code review rejection rate |
Two patterns repeat across every row:
- The gaming path is always cheaper than the real work. That's not an accident — it's why it gets chosen. If real value creation were the cheapest path, you wouldn't need to guard against gaming at all.
- The guardrail metric is almost always a delayed or qualitative signal. That's exactly why it gets deprioritized in a system built to reward what's fast to report.
Closing the Loop: Paired Metrics and Guardrails
The fix for Goodhart's law isn't abandoning targets — it's never shipping a target without its paired guardrail metric, so the balancing loop becomes visible on the same dashboard, in the same review, at the same cadence as the reinforcing loop.
A guardrail metric is a second number that would move if the first number were being gamed rather than genuinely earned. It doesn't need to be perfect; it needs to be directionally sensitive to the thing you'd sacrifice to hit the primary target. Three practical rules:
- Pair every growth metric with a quality or trust metric it can't be gamed against simultaneously. If
DAUis the target, opt-out rate or "sessions with zero notification prompt" is the guardrail — you can't inflate one by degrading the other. - Give the guardrail metric a hard floor, not just a watch-list status. A guardrail nobody can breach isn't a guardrail — it's decoration. If uninstall rate crosses X%, the
DAUOKR is automatically marked at-risk regardless of the primary number. - Source the guardrail from a different data path than the target. If both numbers come from the same event stream, a single dashboard bug or definitional tweak can move both together and hide the tradeoff.
Finding the right guardrail usually means going back to the qualitative goal the number was proxying for in the first place. If the target is DAU, ask what job the user actually hired the product to do — the complete guide to Jobs to Be Done is the right lens for separating "the app was opened" from "the user's problem got solved."
Mapping where along the customer journey and emotion curve the gaming tactic sits often reveals the guardrail before you've even named it. A notification hitting someone mid-frustration lands very differently than one hitting them mid-delight.
This is also, more broadly, a leverage-point problem. Adding a guardrail metric is a relatively low-leverage fix — it catches gaming after the fact. The higher-leverage move is redesigning the goal structure itself so the reinforcing loop and the real objective point the same direction; that kind of structural intervention is what finding leverage points in a product system is built to help you locate.
A simple pre-mortem for any new OKR
Before finalizing a target, run it through three questions:
- What is the cheapest possible way to move this number without creating real value?
- What would that cheap path cost, and who would pay it (users, engineers, support, brand)?
- What number would move first if that cost were being incurred?
That third answer is your guardrail metric. Write it into the OKR document alongside the target, not as an afterthought in the retro.
Modeling the Gaming Loop Before It Happens
Most teams only discover their Goodhart trap after the balancing loop has already done damage — the notification backlash, the ticket-reopen spike, the trust erosion nobody flagged until churn moved. The more useful moment to see the loop is before you commit to the target, while it's still just a proposed number on a slide.
This is the exact use case behind Prodinja's Systems Engineering tool: it walks you through modeling the causal-loop structure around a proposed target metric — the reinforcing loop that will chase the number, and the balancing loop it's likely to create. The goal is seeing the probable side effect before shipping the OKR, not three retros later.
It's designed as a structured way to ask "what will this number cheaply trade away?" before the trade happens — using the same causal-loop-diagram discipline Donella Meadows outlined in Thinking in Systems, applied directly to the metric your team is about to commit a quarter to.
Key Takeaways
- Goodhart's law is structural, not moral. A target is an intervention that changes behavior; treating it as a passive measurement is the root error.
- Every gamed OKR has two loops. A visible reinforcing loop chases the number; an invisible balancing loop sacrifices whatever wasn't measured.
- Delays hide the damage. The reinforcing loop reports instantly; the balancing loop reports late, which is why gaming survives quarter after quarter.
- The gaming path is always the cheapest path. If you can name the cheapest way to move a number without creating value, you've found where the balancing loop will strike.
- Pair every target with a guardrail metric sourced from a different data path, with a hard floor, tied to the qualitative goal the target was a proxy for.
- Fix the structure before the retro. Modeling the likely balancing loop while setting the OKR is higher-leverage than discovering it after the damage.
Frequently Asked Questions
What is Goodhart's law in simple terms?
Goodhart's law says that once you turn a measure into a target — attach incentives, reviews, or rewards to it — people optimize the measure itself rather than the underlying goal it was meant to represent, and the measure stops being trustworthy. It was originally observed in monetary policy by economist Charles Goodhart in 1975 and later popularized in its common phrasing by anthropologist Marilyn Strathern.
Why do OKRs get gamed so often?
OKRs get gamed because they're explicitly designed to attach visibility, review cadence, and often compensation to a specific number, which is exactly the condition Goodhart's law describes. The reinforcing loop toward the number is fast and visible; the balancing loop it creates against the real goal is slow and easy to miss until a review cycle after the damage is done.
How do you prevent metric fixation in product teams?
Prevent metric fixation by never setting a target metric without a paired guardrail metric that would move if the target were being gamed rather than earned. Source the guardrail from a different data path, give it a hard floor that flags the primary OKR as at-risk if breached, and revisit both numbers at the same cadence.
What's the difference between Goodhart's law and Campbell's law?
Goodhart's law states that a measure ceases to be reliable once it becomes a target; Campbell's law, from social scientist Donald T. Campbell, adds that the more a quantitative indicator is used for social or organizational decision-making, the more it becomes subject to corruption pressures and distorts the process it's meant to track. They describe the same phenomenon from slightly different angles — one focused on the measure's reliability, one on the corrupting pressure of high stakes.
What's a good guardrail metric for a DAU or engagement OKR?
A good guardrail metric for DAU is one sensitive to the cost of gaming it — typically notification opt-out rate, uninstall rate, or the share of sessions initiated without a push prompt. The right guardrail moves in the opposite direction whenever the primary metric is being inflated through low-value tactics rather than genuine value delivery.