--- name: pareto-principle description: "Activate when: user says 'Pareto,' '80/20,' 'vital few,' 'long tail,' 'where is the leverage'; a team is treating many items as equally important; a backlog has no triage; growth efforts are spread thin across too many initiatives. Do NOT activate when: fewer than ~6 items total (no distribution to analyze); safety-critical or regulatory contexts where every item must be addressed regardless of frequency." --- # The Pareto Principle (80/20) ## Overview In most real systems, a small fraction of inputs produces the majority of outputs. The pattern — heavy-tailed distribution where the **vital few** dominate the **trivial many** — is empirically robust across operations, software, and revenue. Pareto (1896) documented the distribution; Juran (1951) coined "vital few and trivial many." Key hazard: different outputs have different vital fews, and asserting "80/20" without measuring is folk reasoning. **Compose:** [first-principles](../first-principles/SKILL.md) to identify what outcome you are driving; [aarrr-pirate-metrics](../aarrr-pirate-metrics/SKILL.md) to instrument which inputs produce which outputs; [probabilistic-thinking](../probabilistic-thinking/SKILL.md) to test the split is real and not a small-sample artifact. ## When to Use Use: team treating many items as equally important; resources spread thin; prioritization needed; you suspect a heavy-tailed distribution that hasn't been measured; deciding where to concentrate AI capex / AI adoption effort when most pilots stall and a few use cases capture the value (which AI bets to fund vs. cut against AI-native competition). **When NOT:** only a few items total; safety-critical or long-tail-strategic items where the residual matters; the split is trivially obvious; using it to abandon a strategically valuable long tail. ## Coaching Novices (Adaptive Front Door) - **Engine mode:** user has data and wants vital few identified — run The Process directly. - **Coach mode:** vague situation or signals unfamiliarity — guide step by step. In Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop. 1. One-line what-it-is: in most systems, ~20% of inputs produce ~80% of outputs — Pareto identifies those inputs so effort goes where it matters, not spread equally. 2. Check fit against When to Use / When NOT to use. Tiny dataset or safety-critical → redirect. 3. Elicit the *one* metric they want to grow (revenue, crashes-eliminated, support tickets). The 80/20 of customer count is not the 80/20 of revenue. > **[WAIT — do not advance until user responds]** 4. Run The Process one step at a time with their input: define output → collect distribution → rank → identify elbow → check ratio → decide on trivial many. > **[WAIT — do not advance until user responds]** 5. Close by naming the vital few they uncovered AND their explicit decision about the trivial many (cut / maintain / invest-strategic). > **[WAIT — do not advance until user responds]** ## The Process Run the **Pareto Analysis**: define output, measure distribution, identify vital few, decide on trivial many. 1. **Define the output precisely.** Not "the business" but e.g. *revenue this fiscal year* or *crashes per month*. The 80/20 of output A is not the 80/20 of output B. 2. **Enumerate the inputs.** All items that produce the output (customers, bugs, features, suppliers). 3. **Measure each input's contribution.** This step is most often skipped. Without it, "the Pareto says…" is fiction. 4. **Rank inputs by contribution, descending.** Sort. Plot cumulative output vs. cumulative input fraction. 5. **Identify the elbow — the actual ratio.** Measure it; don't assume 80/20. The elbow is where the curve flattens. 6. **Decide on the vital few:** concentrate effort proportionally. 7. **Decide on the trivial many — explicitly:** Cut / Maintain at minimal effort / Invest strategically (reason: ...). 8. **Re-measure periodically.** The vital few change; re-run quarterly or after material changes. ### Output: the Pareto Analysis ``` # Pareto Analysis: ## Output (precisely): ## Inputs enumerated: ## Distribution: | Rank | Input | Contribution | Cumulative % | ## Actual ratio: ## Vital few: ## Trivial many: ☐ Cut ☐ Maintain ☐ Invest strategically (reason: …) ## Re-measurement schedule: ``` *→ Method in Action: [Microsoft's Office Bug-Fix Pareto (2002)](examples/microsoft-office-bug-fix-pareto-2002.md)* *→ 2026 lens: [The 80/20 of Realized AI Value (2024–2026)](examples/ai-value-concentration-2024-2026.md)* ## Pareto Distribution Packs - **Software defects:** ratio often 80/2 or steeper; vital few are memory issues and concurrency bugs. - **B2B SaaS revenue:** typically 80/20; beware cutting long-tail SMB (your next-decade pipeline). - **Content engagement:** extremely heavy-tailed — top 1% of content can drive 50%+ of engagement. - **Fraud / cybersecurity:** calculus inverts — the rare malicious event dominates risk; standard Pareto is dangerous here. ## Applying It Well - **Measure, don't assume.** "80/20" is a hypothesis. The actual ratio matters: 80/20 vs. 95/5 vs. 60/40 all imply different moves. - **Different outputs have different vital fews.** Pareto is per-output, not per-system. - **The trivial many decision is the strategic decision.** Cut / maintain / invest-for-strategic-reasons — decide explicitly. - **Re-measure.** The vital few rotates; re-run quarterly or after material changes. - **Beware safety-critical applications.** Don't apply Pareto where the rare event is catastrophic. *→ Primary sources: [references/sources.md](references/sources.md)* ## Common Rationalizations **[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.** | Fake move | Reality | |---|---| | [D] Asserting "80/20" without measuring | The principle is a hypothesis until tested. Measure the actual distribution before acting on it. | | [D] Applying 80/20 across different outputs as if they're the same | The 20% driving revenue ≠ the 20% driving support load. Pareto is *per output*. | | [D] Cutting the trivial many automatically | Sometimes the long-tail customers, features, or markets are strategically essential. The "cut" decision needs to be deliberate, not default. | | [D] Pareto in safety-critical contexts without caveat | Rare-event-catastrophic domains (security, fraud, aerospace) invert the calculus. Standard 80/20 can be actively dangerous. | | [D] Confusing ratio with elbow | The "elbow" of the curve is where you cut — not always at 80/20. Look at the actual curve. | | [D] Applying once, treating as eternal | The vital few rotates. Today's vital few becomes tomorrow's trivial many as the system changes. | | [D] Using Pareto as rhetoric, not data | "By the 80/20 rule, we should…" without measurement is folk reasoning. Run the analysis. | | [D] Mistaking Pareto for "ignore the rest" | The trivial many is not ignored; it is *deliberately deprioritized* with a documented decision. | | [D] Pareto-of-Pareto mistakes | Applying 80/20 recursively sometimes makes sense, sometimes is meaningless. Test the second-level distribution first. | | [D] Skipping measurement because "it's obviously 80/20" | The actual ratio carries information. 80/20 vs 80/2 imply very different resource allocations. | | *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* | ## Red Flags - "80/20" asserted with no measurement; curve never plotted - Vital few and trivial many decisions are implicit, not documented - Same 80/20 split applied across multiple unrelated outputs - Trivial many cut without strategic review; safety-critical context using standard Pareto framing - Analysis treated as permanent; no re-measurement scheduled ## Verification - [ ] Output named precisely with measurable units; inputs enumerated systematically - [ ] Each input's contribution measured (not estimated); cumulative distribution plotted - [ ] Actual ratio reported — not assumed to be 80/20 - [ ] Vital few: effort concentration plan named - [ ] Trivial many: cut / maintain / invest-strategic decision documented with reason - [ ] Re-measurement schedule set --- *Part of **deciqAI Knowledge Skills** — 225 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. **See it run → https://www.deciqai.com/s/pareto-principle** · Built by deciqAI · github.com/deciqAI · Contributions welcome.*