20% of effort, 80% of results.

80/20 Principle

Most outputs come from a minority of inputs. Find the high-leverage 20% and ruthlessly deprioritise the rest.

Use whenDeciding what to build, what to cut, where to focus.

Italian economist Vilfredo Pareto observed that 80% of Italy's land was owned by 20% of its population. He then noticed the same pattern in his garden — 20% of the pea pods produced 80% of the peas. The 80/20 distribution appears everywhere: bugs, revenue, customers, features, relationships. The question is what you do with it.

The principle

In most systems, roughly 80% of outputs come from roughly 20% of inputs. The numbers aren't always exactly 80/20 — sometimes it's 70/30 or 90/10 — but the shape is consistent: highly skewed, with a small minority driving the majority of results. This is not a coincidence. It reflects how compounding, feedback loops, and power laws work in complex systems.

Applied to product decisions

Which 20% of features are used by 80% of users? Which 20% of bugs cause 80% of support tickets? Which 20% of your user base drives 80% of revenue? The uncomfortable implication: if you can identify and protect those items, the other 80% of your roadmap is disproportionately expensive for what it delivers.

The danger of the long tail

Most product teams build for edge cases. An enterprise customer who pays a lot has unusual requirements. A vocal user segment complains loudly about an obscure feature. The 80/20 principle forces the question: does this serve the core majority, or the noisy minority? Both can be valid — but they should be explicit choices, not accidents.

In engineering leadership

Where does 80% of your incident volume come from? Usually a handful of services, a few error types, a specific code path. Fix the 20% that generates 80% of the pain before you distribute the remaining 20% of pain more evenly. Same for tech debt: not all debt is equal. Find the 20% that is actively slowing you down and target that.

In practice

Your codebase has 200 open bug reports. 40 of them appear in every support conversation, every sprint retrospective, and are mentioned in onboarding feedback. Fix those 40 before touching the other 160. The ROI ratio is not 4:1 — it's more like 10:1, because the high-frequency bugs compound customer frustration and support cost in ways the obscure ones don't.

TL;DR

20% of inputs produce 80% of outputs. Find that 20% and protect it. Everything else is secondary.