/ Library/ Not Enough Meaning/ Zero-Sum Bias
Connect Bias № 142 · Last updated 6 June 2026

Zero-Sum Bias.

"Their win feels like our loss — even when the pie could grow."

01Overview

Zero-sum bias frames trade-offs as purely competitive — user privacy vs product growth, design vs engineering speed, one persona vs another — when collaborative or positive-sum solutions exist. The bias narrows option space to fights.

Teams kill privacy-preserving features fearing revenue loss that need not occur. Users assume personalisation always harms them. Cross-functional roadmaps become turf wars. Zero-sum bias forecloses synthesis — better defaults, transparent data use, performance that helps both sides.

02Detailed explanation

Zero-sum framing in product debates:

  • Privacy enhancements treated as conversion enemies without testing balanced UX.
  • Accessibility seen as visual identity loss, not audience expansion.
  • Developer experience vs user experience framed as pick one.
  • Two personas pitted — power vs novice — without adaptive UI.

Loss aversion intensifies zero-sum feeling — losses loom larger than shared gains. Scarcity effect adds false limited-pie belief.

03Why it exists

Competitive narratives are simple and mobilising — win-lose stories spread faster than win-win nuance.

Resource-constrained quarters make positive-sum feel naive — bias becomes culture.

The short version

Where are you assuming their gain must be your loss — without testing a both-and option?

04Effects on users

Users resist features they believe trade against them — data for "free" service — when transparent models could align incentives.

Zero-sum tribalism in communities — users vs company — poisons feedback channels designers need.

05Effects on designers & teams

Teams perform zero-sum prioritisation:

  • Privacy vs growth slides. No third column for trust-led growth.
  • Design-dev tradeoff theatre. Velocity vs quality binary.
  • Persona wars in roadmap. Winner take all.
  • Competitive zero-sum strategy. Competitor win assumed your loss only.

06Practical takeaways

  • Search positive-sum frames. Privacy as feature; a11y as market.
  • Test both-and prototypes. Before accepting tradeoff.
  • Measure trust-led metrics. Retention from transparency wins.
  • Adaptive UI for divergent personas. Reduce forced zero-sum.
  • Facilitate cross-functional synthesis. Shared KPIs beyond turf.
  • Communicate mutual benefit honestly. When it exists; admit real tradeoffs when not.

07Design examples

Privacy

Growth vs consent

Team kills granular consent UI fearing 30% data loss. Competitor ships transparent controls; trust rises, data quality improves. Zero-sum assumption cost advantage.

Accessibility

Brand vs a11y

Contrast fix "ruins brand." Fix ships; no brand harm; usable base expands. Zero-sum bias delayed inclusion two quarters.

Roadmap

Power vs novice

Debate pits expert mode against simplification. Adaptive defaults serve both — zero-sum framing nearly forced bad either/or.

Org

Design or speed

Sprint planning treats design polish as velocity enemy. Design system investment later accelerates both — false zero-sum in planning ritual.

08Ethical risks

Zero-sum framing justifies harming users to "save" business — when trust and quality could compound both.

Persona wars erase users who need both accessibility and power — intersectional needs invisible in false tradeoffs.

Self-test: Which debate on your team is framed as win-lose — and what both-and design have you not tried?

10Suggested reading