The Cobra Effect: How Well-Designed Incentives Produce the Exact Behavior You Feared

A well-incentivized behavior and a gamed behavior look identical on the dashboard — both drive the number up. The difference is underneath: a genuinely good incentive builds a reinforcing loop toward the real outcome, while a badly designed one builds a reinforcing loop toward the cheapest fake of that outcome, which is often the exact harm the incentive was built to prevent.

Quick answer: Incentives don't just add behavior — they create a reinforcing loop around whatever you measure. Reward a proxy for the outcome you actually want, and rational users will produce the proxy directly, sometimes by manufacturing the very problem the incentive was meant to solve.

The Cobra Effect: Three Bounties That Made the Problem Worse

The cobra effect is any incentive that increases the exact behavior it was built to eliminate, and the pattern has been playing out in policy for over a century. It's always the same failure: a government or company rewards a measurable proxy for a problem instead of the problem itself, and people learn to manufacture the proxy far more cheaply than they could ever solve the underlying issue.

The eponymous story is set in colonial Delhi. Worried about venomous cobras in the city, the British administration offered a bounty for every dead cobra turned in. Residents responded exactly as incentivized — they began breeding cobras specifically to kill and cash in. When administrators noticed the bounty had created a cottage industry instead of solving anything, they cancelled it without paying out the existing stock. Breeders, now holding worthless snakes, released them. Delhi ended up with more wild cobras than before the bounty existed.

German economist Horst Siebert made the story famous as shorthand for backfiring policy in his 2001 book Der Kobra-Effekt, and it's since become the standard reference for any reward that produces the opposite of its intent.

The pattern isn't unique to Delhi, and it's better documented in French colonial Hanoi. Administrators paid a bounty per rat tail turned in, hoping to control a plague-linked rat population. Historian Michael Vann's research into the episode found hunters cutting off tails and releasing the rats to keep breeding stock alive, with some tails reportedly arriving from rats farmed outside city limits purely to supply the bounty. The rat population was, if anything, undiminished.

The same failure mode shows up in a cleaner, peer-reviewed setting, too. Economists Uri Gneezy and Aldo Rustichini studied ten Israeli daycare centers that introduced a fine for parents arriving more than ten minutes late to pick up their children. Late pickups didn't fall — they roughly doubled, and stayed elevated even after the centers scrapped the fine months later. The fine had reframed a moral obligation as a transaction: parents who once felt guilty for lateness now felt they'd simply paid for the extra hour.

Goodhart's Law names the mechanism

Every one of these programs failed the same way, and Goodhart's Law explains why: once a measure becomes the target, people optimize the measure instead of the thing it was supposed to represent. Economist Charles Goodhart originally made the point about monetary policy; anthropologist Marilyn Strathern's later restatement is the version most product teams actually quote.

"When a measure becomes a target, it ceases to be a good measure." — Marilyn Strathern, restating Goodhart's Law

A dead cobra, a rat tail, a login streak, and a referral link are all the same kind of object: a proxy standing in for an outcome the reward-giver actually wants but can't measure directly. The moment the proxy carries a payout, its correlation with the real outcome starts to break down — because now there's a market for the proxy alone.

Incentives Are Systems Interventions, Not Feature Toggles

An incentive isn't a lever you pull once — it's an intervention into a system that keeps running after you leave the room, and every agent inside that system routes around it in whatever direction serves them best. Treat a reward like a feature you shipped, and you'll miss the loop it just created.

This is the core claim of systems thinking applied to product: a product is a set of interconnected loops, not a list of independent features, and a change to one part of the loop changes behavior everywhere else in it. An incentive is a structural change to that system, not a UI element, and it deserves the same scrutiny you'd give a pricing change or a policy shift.

Every incentive that pays out per unit of proxy creates a reinforcing loop: more proxy produced leads to more reward claimed, which increases the incentive to produce the proxy again, with no natural ceiling until something external — a fraud team, a budget cap, a policy change — steps in. Reinforcing loops aren't inherently bad; a compounding referral engine is exactly what a healthy growth loop looks like. The danger is a reinforcing loop that compounds around the fake version of your outcome instead of the real one.

A few things are worth checking before you assume a loop will behave the way you drew it:

• Does the loop have a natural balancing force (a cost, a limit, a verification step), or does it only reinforce?
• Who benefits from the proxy alone, independent of the outcome you actually want?
• What stops the loop once it starts compounding in the wrong direction?

Donella Meadows ranked the places you can intervene in a system from weakest to strongest in Thinking in Systems: A Primer, and "rules" — which is what an incentive is — sit closer to the weak end of that hierarchy than most product teams assume. Changing the rules without changing the goal the system is organized around is exactly how you end up with a gamed proxy instead of a solved problem. For where an incentive actually ranks against deeper interventions like changing the goal itself, see finding leverage points in a product system.

Two Product Cases: Referral Bonuses and Streaks Gone Sideways

Referral bonuses and streak mechanics are the two most common homes for the cobra effect in software, because both reward a proxy — an account created, a day opened — that's far cheaper to fake than the underlying outcome of a genuinely acquired or genuinely engaged user.

Referral bonuses: paying for the account, not the user

PayPal's early referral program is the canonical case. The company paid new users a cash bonus — reportedly as much as $10 to $20 per referred signup — to bootstrap its two-sided marketplace, a program journalist Jimmy Soni documents in detail in The Founders: The Story of PayPal and the Entrepreneurs Who Shaped Silicon Valley. It worked spectacularly at driving signups. It also drew a wave of users creating multiple fake accounts and referring themselves, forcing the company to build fraud detection faster than it had planned to.

The proxy PayPal rewarded — a new account created via a referral link — was never actually the outcome PayPal wanted, which was a new customer who'd transact on the platform. Anyone who can generate an email address can generate the proxy. The gap between the two is exactly where the gaming happened.

Streaks: paying for the login, not the learning

Duolingo's and Snapchat's streak mechanics reward showing up, not doing anything meaningful once you're there. Snapchat's "Snapstreaks" were widely reported in youth-culture journalism as a source of anxiety severe enough that teens would hand a friend their phone's passcode, or send a blank photo, purely to keep a streak alive that had stopped representing any real communication.

Duolingo has built streak freezes and repair mechanics precisely because it recognizes the proxy is fragile — but the underlying dynamic is the one Goodhart named: once "consecutive days opened" becomes the target, the fastest way to hit it is to open the app and do the bare minimum, not to actually practice the language.

The job the user actually hired the product to do — as Jobs to Be Done framing would put it — was never "maintain a number." It was something closer to "help me feel like I'm making progress" or "help me actually stay in touch with a friend." The streak is a proxy for that job, and once it carries its own reward — identity, social pressure, a badge — it can be satisfied without the job ever getting done.

The damage from a gamed streak rarely shows up immediately, which is what makes it dangerous. A user grinding out a hollow streak still counts in this week's DAU. The quality erosion — frustration, disengagement, eventual churn — surfaces weeks later, after the delay between a feedback loop and the retention metric it's supposed to predict has run its course, by which point the team has often shipped three more streak features on top of the first one.

Spotting a Gaming Loop Before You Ship the Reward

A gaming loop is easy to spot in advance if you're willing to ask one question honestly: can someone produce the proxy without producing the outcome, at a cost lower than the reward? If the answer is yes, you've already found the exploit — you just haven't shipped it yet.

A few properties make a proxy especially exploitable:

• Separability — can the proxy be produced in isolation from the outcome (a login without any learning, a dead snake without a smaller wild population)?
• Verification cost — is checking the real outcome expensive relative to just paying out on the proxy? If verification is expensive, the proxy quietly becomes the de facto goal.
• Reward fungibility — is the reward cash, credit, or status valuable enough to be worth gaming, and transferable enough to resell or share?
• Population diversity — do you have users for whom gaming is structurally easier than the honest path (bots, sockpuppets, professional deal-seekers, multiple devices)?
• Feedback delay — how long between the gaming behavior and its visible consequence? The longer the delay, the more of the gamed behavior accumulates before anyone notices.

Mapping the incentive onto a broader view of the experience also helps make gaming visible before it ships. Plotting the reward moment against a customer journey map — the proxy event, the emotional high point the incentive is meant to reinforce, and the actual moment of value delivery — puts all three on the same timeline. If the reward moment and the true value moment aren't the same moment, you've built exactly the gap where gaming lives.

Testing the Incentive Loop Before It Goes Live

Testing for the cobra effect means simulating the adversarial user before you have one: model the loop you intend to create, then model the cheapest loop a rational, effort-averse person would build to collect the reward without doing the work. If the second loop is cheaper than the first, redesign the reward — not the fraud team.

A workable pre-launch process looks like this:

1. Draw the causal loop. Map reward → behavior → proxy metric → payout, and mark every place a user could enter that loop without ever passing through the real outcome.
2. Write the adversarial persona. Name the specific user who's only in it for the reward, and write out, step by step, the cheapest sequence of actions that gets them the payout.
3. Price the exploit. Estimate the bad actor's cost per unit of reward gained (an email address, a burner number, a few minutes tapping through a lesson) against the payout. If the exploit's cost is lower than the reward at realistic volume, you have a live cobra effect, not a hypothetical one.
4. Instrument the fake outcome, not just the target one. Track referred-user retention alongside referral volume; track streak-cohort session depth alongside streak length — from day one, not after a fraud spike triggers an audit.
5. Set a kill-switch metric ahead of time — for example, "if referred-user D7 retention falls more than a defined threshold below organic D7 retention, we pause payouts" — so the decision to intervene isn't made emotionally after the exploit is already public.

This is close to what Prodinja's Systems Engineering tool is designed to help with: before you ship a reward, it walks you through modeling the intended incentive loop as a causal diagram, then adding the workaround loop a gaming user would plausibly build around it, to see where the two intersect. It won't predict fraud with certainty — nothing will — but it gives you a structured way to ask "what's the cheapest way to fake this?" at design time, instead of after launch, which is when most teams first think to ask it.

Key Takeaways

• The cobra effect is any incentive that increases the exact behavior it was meant to eliminate, because it rewards a proxy instead of the outcome.
• Goodhart's Law explains the mechanism: once a measure becomes a target, people optimize the measure, not the reality it once represented.
• Incentives are systems interventions, not feature toggles — they create reinforcing loops that compound with or without your attention.
• Referral bonuses and streaks are the two most common cobra-effect traps in software, because their proxies (an account, a login) are far cheaper to fake than the real outcome (a retained user, a genuine habit).
• A gaming loop is predictable in advance: ask whether the proxy can be produced, cheaper than the reward, without ever producing the outcome.
• Test the incentive like an adversary would, before launch — model the workaround loop, price the exploit, and set a kill-switch metric ahead of time.