A platform tragedy of the commons happens when every team improves its own metric by drawing on a shared, finite resource — notification slots, home-screen space, API rate limits — until the combined draw exceeds what the resource can sustain and the whole platform's performance, engagement, or reliability collapses for everyone, including the teams that were winning.
Quick answer: When each team maximizes its own reinforcing loop against a shared, finite resource — without a balancing loop tied to total consumption — the resource degrades for everyone, including the teams that "won" the local optimization.
What a Platform Commons Actually Is (And Why PMs Miss It)
A platform commons is any shared resource that scales with total usage across teams rather than with any single team's usage — user attention, screen space, or system capacity — so no one owns it, everyone draws on it, and the cost of overuse is invisible to whoever is causing it until the aggregate crosses a threshold. This is shared resource degradation in its purest product form.
Garrett Hardin gave this pattern its name in a 1968 Science essay describing herders who each add one more animal to a shared pasture because the gain is private and the cost — a degraded pasture — is split among everyone. Every herder does the individually rational thing. The pasture still dies.
"Ruin is the destination toward which all men rush, each pursuing his own best interest in a society that believes in the freedom of the commons." — Garrett Hardin, The Tragedy of the Commons, 1968
Swap "pasture" for "user's notification tray," "home screen," or "API gateway" and the mechanics transfer almost without translation. Inside a platform, the commons usually shows up as one of three things:
- Attention, rationed as notification volume or in-app messaging slots.
- Space, rationed as home-screen real estate, nav-bar slots, or "featured" placements.
- Capacity, rationed as
APIrate limits (often literally calledAPI quotas), database connections, or shared compute.
PMs miss it because dashboards are scoped to teams, not to resources. The notifications team's dashboard shows send volume and CTR for their campaign. Nothing on it shows total notification load per user across all eleven teams sending pushes. Each team's chart goes up and to the right. The shared resource's chart — the one that matters — doesn't exist anywhere, for anyone, until support tickets or churn dashboards force it into being.
This is a systems-thinking problem, not a prioritization problem. If you haven't mapped how reinforcing and balancing loops interact in your product, our systems thinking complete guide is the right starting point before the rest of this gets actionable.
The Loop Structure: Why Rational Local Decisions Add Up to a Global Collapse
Each team runs a reinforcing loop: send more notifications, claim more home-screen space, call the API more often, and the team's own metric — activation, adoption, reliability of its own feature — goes up. Left alone, a reinforcing loop grows without limit. A platform only stays healthy if a separate balancing loop caps total draw before the shared resource is exhausted, and in most orgs that balancing loop simply doesn't exist.
Take notifications. Team A ships a push for a new feature. Open rates look decent, so Team A sends more. More sends, measured in isolation, keep producing more clicks — a clean reinforcing loop, R1. Team B, C, and D are running the identical loop for their own features, each with its own dashboard, each blind to the other three.
Our guide on reinforcing vs. balancing loops in growth walks through why this structure is stable and self-amplifying right up until it isn't. The missing piece is a balancing loop, B1: as total notifications per user rise, something should push back — a shrinking send budget, a rising approval bar, a hard cap — before the user's tolerance is exhausted.
Without B1, the reinforcing loops keep compounding until the user mutes the channel, disables push entirely, or uninstalls. At that point every team's number drops to zero simultaneously, including the teams that were "winning" a month earlier. Two things make this worse in practice:
- The damage arrives late. A user doesn't churn the day they get their fifteenth push; they churn three weeks later, and the team that sent push twelve gets none of the blame. Our piece on delays in feedback loops and retention/churn covers why delayed feedback is what lets reinforcing loops run so far past the point of sanity.
- The incentive is legitimate. Each team isn't behaving badly — it's doing its job. A team optimizing activation for its own feature is executing a real job to be done, in the sense our
JTBDcomplete guide describes: the user is hiring a channel to get a specific job done, one send at a time, with no visibility into the other nine jobs competing for the same channel.
Three Commons Every Platform PM Should Recognize
The specific resource varies, but the shape repeats: a reinforcing loop, a finite pool, and a collapse that hits everyone at once. Three show up on almost every platform team's roadmap sooner or later.
| Shared resource | Each team's reinforcing loop | What's actually finite | Collapse symptom | Real-world echo |
|---|---|---|---|---|
| Notification volume | "Send more pushes/emails to lift my feature's adoption metric" | User attention and trust in the channel | Opt-out and mute rates spike; platform-wide push CTR falls even as send volume rises | Consumer apps have repeatedly found that raising send volume past a threshold lowers aggregate engagement, not just per-message engagement |
| Home-screen real estate | "Add my widget/banner/entry point to the first screen users see" | The number of things a user will actually look at above the fold | Task completion time rises for the platform's core job, not just the newer features crowding in | Enterprise home screens (CRMs, project tools) are a routine casualty of this — see how the customer journey fragments when every team fights for the first moment of a session |
API rate limits / shared compute | "Call the API more aggressively to hit my own team's SLA or latency target" | The gateway's total request throughput, or a shared quota granted by a vendor | Throttling and 429 errors hit every caller, including the highest-value one, once total load crosses the ceiling | Reddit's 2023 API pricing and rate-limit overhaul, and Twitter/X's 2023 rate-limit changes, both forced a step-change in who could call the API at what volume — a blunt, after-the-fact version of the balancing loop that should have existed all along |
Notice the pattern in the last column: in every real case, the fix that eventually arrived was a governance mechanism imposed from outside — a policy change, a pricing change, a hard quota. That's the balancing loop showing up late, expensive, and unpopular instead of early, cheap, and designed.
The Missing Balancing Loop: What Governance Actually Requires
A shared resource doesn't need every team to want less; it needs a mechanism that makes total consumption visible, bounded, and enforceable before it's exhausted. Elinor Ostrom spent much of her career studying exactly this — real commons (fisheries, irrigation systems, forests) that didn't collapse — and won the Nobel Memorial Prize in Economic Sciences in 2009 for describing the conditions under which shared resources survive.
Her book Governing the Commons (1990) identifies design principles common to commons that endure. They translate to a product platform with almost no distortion:
| Ostrom design principle | Platform translation | Concrete mechanism |
|---|---|---|
| Clearly defined boundaries | Everyone can see what the shared resource is and who draws on it | A single cross-team dashboard: total notification sends, home-screen slot occupancy, or API calls per minute, broken out by team |
| Rules matched to local conditions | Caps reflect actual usage patterns, not one arbitrary blanket number | Per-team budgets sized to historical share of the resource, revisited quarterly |
| Collective-choice arrangements | Teams affected by the rules get a say in setting them | A standing platform review forum where teams request budget changes against the shared total |
| Monitoring | Someone accountable is actually watching total draw, in real time | Instrumentation on the aggregate metric — not per-team totals — with alerting as it approaches the ceiling |
| Graduated sanctions | Overuse has an escalating, predictable cost | Rate-limit tiers, throttling with backoff, or a chargeback model tied to a team's share of the total |
| Low-cost conflict resolution | Disputes over the shared budget get resolved fast and cheaply | A lightweight escalation path when one team's ask would push total usage past the agreed ceiling |
None of this requires a single team to act against its own interest. It requires the organization to own a metric that no team currently owns — total load — and to attach consequences to it. That's the balancing loop.
Finding the Leverage Point: Feedback Tied to Total Load, Not Team Output
The highest-leverage fix isn't asking each team to send fewer notifications or claim less home-screen space; it's changing the system's structure so total consumption becomes a first-class, monitored, consequential metric. Donella Meadows ranked exactly this kind of intervention — adding or strengthening a feedback loop, and changing who has authority over a shared metric — well above tweaking any single team's parameters in her well-known hierarchy of "places to intervene in a system."
If you're mapping this on your own product, our guide to finding leverage points in a product system is a useful companion — it covers where structural fixes like this rank versus the more common (and weaker) move of just asking teams to behave better. In roughly increasing order of power:
- Make the total visible. The lowest-leverage move, but the one almost nobody has done: a single dashboard showing total notification volume per user, total home-screen slots claimed, or total
APIcalls per minute — not per-team, the aggregate. You can't govern what isn't measured in one place. - Tie a rule to the total. Per-team budgets that shrink automatically as the aggregate approaches its ceiling — a shared thermostat, not a fixed allocation each team defends forever.
- Move ownership of the metric. The most powerful and least comfortable move: give a platform team, not any single feature team, explicit authority to say no when a request would breach the shared budget, with escalation paths that don't route around them.
Most orgs stop at step one and wonder why nothing changes. Visibility without an enforcement mechanism is a report, not a governing loop.
Making the Commons Legible: A Practical Playbook
The reason this archetype survives so long inside real companies isn't that nobody sees it — it's that no single artifact shows all the reinforcing loops draining the same stock at once. Each team's roadmap deck shows its own loop in isolation and looks perfectly sane. The collapse only becomes obvious in a causal-loop diagram that puts every team's arrows on the same shared variable.
To put a governing loop in place, with or without a systems-mapping tool, the sequence still holds:
- Name the resource explicitly. Write down, in one sentence, what's actually finite: "attention," "above-the-fold space," "requests per second." If two teams disagree on what the resource even is, you don't have alignment yet.
- Instrument the aggregate, not the parts. Build the one dashboard that sums every team's draw into a single number, refreshed at least daily.
- Set a ceiling before you need one. Decide the total budget — total pushes per user per week, total home-screen slots, total requests per second — while there's no crisis forcing an emergency number.
- Allocate shares, and revisit them. Split the ceiling across teams by a defensible rule (historical usage, strategic priority, revenue contribution), and put a recurring review on the calendar.
- Attach a real cost to overuse. Throttling,
chargeback, or a mandatory review gate — something with teeth, not a Slack reminder. - Give the whole thing an owner. A platform PM or a designated council, not a rotating volunteer, holds the pen on the total and can say no.
Skipping step six is the single most common failure. A dashboard with no owner is trivia; a dashboard with an owner who can enforce a ceiling is a balancing loop.
Key Takeaways
- A platform commons — notification volume, home-screen space,
APIcapacity — degrades when every team's local reinforcing loop draws on it without a governing balancing loop tied to the total. - Locally rational team behavior (send more, claim more, call more) is globally destructive precisely because each team optimizes its own metric while nobody owns the aggregate.
- The fix isn't asking teams to want less; it's Elinor Ostrom's insight applied to product orgs — visible boundaries, matched rules, monitoring, and graduated sanctions on the shared resource.
- The highest-leverage intervention, per Donella Meadows' hierarchy of system interventions, is changing who owns and enforces the total metric — not tweaking any single team's targets.
- Feedback on overuse almost always arrives late (churn shows up weeks after notification fatigue sets in), which is exactly why the balancing loop has to be designed in advance, not reacted into existence.
- Mapping every team's reinforcing loop against the same shared stock in a single causal-loop diagram turns an otherwise invisible collapse into something every stakeholder can argue about in one meeting.
Frequently Asked Questions
What is the tragedy of the commons in product management?
It's when every team rationally maximizes its own use of a shared, finite resource — notification slots, home-screen space, API capacity — and the combined effect degrades or collapses that resource for the whole platform. The term comes from Garrett Hardin's 1968 essay; in product orgs it shows up as reinforcing loops with no governing balancing loop.
How do you set API rate limits without breaking internal teams?
Start by making total throughput visible as one aggregate number, then allocate per-team or per-integration API quota shares against that ceiling using a defensible rule like historical usage or business priority. Pair the allocation with graduated enforcement — soft throttling before hard rejection — so teams get a warning, not a cliff, when they approach their share.
What's the difference between a reinforcing loop and a balancing loop?
A reinforcing loop amplifies a change in the same direction — more sends produce more engagement, which encourages more sends — and grows without limit if nothing checks it. A balancing loop pushes back toward a target — a budget, a ceiling, a quota — and is what keeps a reinforcing loop from running a shared resource to zero. Our reinforcing vs. balancing loops guide covers both in more depth.
How do you know if your platform is heading toward a commons collapse?
Watch for a gap between team-level metrics and the resource's aggregate health: every team's dashboard trending up while support tickets, opt-out rates, or 429 errors trend up too. If no single dashboard shows the total draw on the shared resource across teams, you're already flying blind on the metric that matters most.
Can chargeback or cost-back models fix a shared-resource problem?
They can, but only as one piece of governance — Ostrom's research suggests graduated sanctions work alongside clear boundaries, monitoring, and a forum for resolving disputes, not as a stand-alone fix. A chargeback model with no visibility into total usage or no venue to renegotiate shares just shifts the fight from engineering tickets to finance tickets.