{"id":"f8433f8f-6085-46fb-9983-bfadcc3c7b16","entityType":"agent","slug":"clawhub-deciqai-mece","name":"MECE (Mutually Exclusive, Collectively Exhaustive)","canonicalUrl":"https://www.xpersona.co/agent/clawhub-deciqai-mece","canonicalPath":"/agent/clawhub-deciqai-mece","generatedAt":"2026-10-11T20:57:53.577Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T15:52:51.630Z","emptyReason":null},"description":"Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-co... Skill: MECE (Mutually Exclusive, Collectively Exhaustive) Owner: deciqai Summary: Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-co... Tags: latest:1.0.5 Version history: v1.0.5 | 2026-07-16T18:06:02.579Z | user Description tail link + agents machine-readable metadata line (deciqai.com/s/mece.json) v1.0.4 | 202","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17a4mqcnk515kvaca5ze55d0x88pfpx:mece","sourceUrl":"https://clawhub.ai/deciqai/mece","homepage":"https://clawhub.ai/deciqai/skills/mece","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/deciqai/mece","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/deciqai/skills/mece","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-co..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T15:52:51.630Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T15:52:51.630Z","emptyReason":null},"stars":null,"forks":null,"downloads":1034,"packageName":null,"latestVersion":"1.0.5","tractionLabel":"1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T15:52:51.617Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T15:52:51.630Z","lastCrawledAt":"2026-10-11T15:52:51.617Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T15:52:51.617Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.5","createdAt":"2026-07-16T18:06:02.579Z","changelog":"Description tail link + agents machine-readable metadata line (deciqai.com/s/mece.json)","fileCount":6,"zipByteSize":13148},{"version":"1.0.4","createdAt":"2026-07-10T10:27:16.939Z","changelog":"Add 2024-2026 AI-era worked example + updated sources","fileCount":6,"zipByteSize":13003},{"version":"1.0.3","createdAt":"2026-07-08T11:09:21.477Z","changelog":"Footer now uses /c/ short link (fixes UTM truncation when SKILL.md is read in a terminal)","fileCount":5,"zipByteSize":8738},{"version":"1.0.2","createdAt":"2026-07-08T00:54:24.954Z","changelog":"Refreshed content + GitHub star link in footer","fileCount":5,"zipByteSize":8770},{"version":"1.0.1","createdAt":"2026-07-07T22:28:50.588Z","changelog":"Add catalog categories and topics","fileCount":5,"zipByteSize":8731},{"version":"1.0.0","createdAt":"2026-06-30T06:18:26.715Z","changelog":"Initial publish","fileCount":5,"zipByteSize":8721}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17a4mqcnk515kvaca5ze55d0x88pfpx:mece","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-mece/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-mece/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-mece/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-mece/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-mece/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-mece/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T20:57:53.573Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-mece/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-mece/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-mece/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-mece/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T15:52:51.630Z","emptyReason":null},"readme":"Skill: MECE (Mutually Exclusive, Collectively Exhaustive)\n\nOwner: deciqai\n\nSummary: Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-co...\n\nTags: latest:1.0.5\n\nVersion history:\n\nv1.0.5 | 2026-07-16T18:06:02.579Z | user\n\nDescription tail link + agents machine-readable metadata line (deciqai.com/s/mece.json)\n\nv1.0.4 | 2026-07-10T10:27:16.939Z | user\n\nAdd 2024-2026 AI-era worked example + updated sources\n\nv1.0.3 | 2026-07-08T11:09:21.477Z | user\n\nFooter now uses /c/ short link (fixes UTM truncation when SKILL.md is read in a terminal)\n\nv1.0.2 | 2026-07-08T00:54:24.954Z | user\n\nRefreshed content + GitHub star link in footer\n\nv1.0.1 | 2026-07-07T22:28:50.588Z | user\n\nAdd catalog categories and topics\n\nv1.0.0 | 2026-06-30T06:18:26.715Z | user\n\nInitial publish\n\nArchive index:\n\nArchive v1.0.5: 6 files, 13148 bytes\n\nFiles: examples/ai-stack-market-strategy-decomposition-2024-2026.md (7662b), examples/lou-gerstner-ibm-turnaround-decomposition-1993.md (4324b), references/sources.md (1638b), skill-card.md (2315b), SKILL.md (9494b), _meta.json (123b)\n\nFile v1.0.5:SKILL.md\n\n---\nname: mece\ndescription: \"Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-counting', a problem feels too big to think about cleanly, a list of options is messy or overlapping, an analysis keeps going in circles, or a presentation needs to survive hard scrutiny.\n Do NOT activate when: the problem is trivially small (lunch decisions), or the user is in purely creative/generative mode where premature structure would constrain exploration. More: deciqai.com/c/mece\"\n---\n\n# MECE (Mutually Exclusive, Collectively Exhaustive)\n\n## Overview\n\n**MECE** is a decomposition principle: break a problem, set of options, or population into sub-groups that are **Mutually Exclusive** (no overlap) and **Collectively Exhaustive** (no gaps) — every relevant item covered exactly once. Operationalized by **Barbara Minto** at McKinsey (1963–1973) in *The Pyramid Principle* (1973; 3rd ed. 2002). The test: sum the pieces back to the whole; if they don't sum cleanly, the decomposition is broken.\n\n**Compose:** use first-principles to reach root variables; pareto-principle to find load-bearing branches; critical-thinking to test whether categories are the *right* ones; occams-razor when multiple MECE structures fit — pick the simplest.\n\n## When to Use\n\n- Problem feels **too big to think about cleanly** — surface area is unclear\n- **List of options** is messy or overlapping — competing answers that aren't parallel\n- Analysis is **going in circles** — same issues reappear because they're not separated\n- **Presentation** must convince hard-to-convince listeners\n- Team converging on a hypothesis **without considering the full space** of alternatives\n- Structuring an **AI strategy / AI-stack / AI-adoption** discussion so the layers (chips / cloud / models / apps) or use cases have no overlaps and no gaps — cutting through AI hype to a complete, non-redundant map\n- Someone says: *\"MECE,\" \"decompose this,\" \"issue tree,\" \"structure this thinking\"*\n\n**When NOT to use:** trivially small problem; purely creative/generative mode; genuinely non-decomposable question (some ethical/aesthetic problems resist this); decomposition already known and well-trodden.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete case → run The Process directly.\n- **Coach mode:** user is unfamiliar or has no concrete case → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: MECE is **breaking a problem into pieces that don't overlap AND don't leave gaps** — every relevant thing is covered exactly once. The check: do the pieces sum back to the whole?\n2. Check fit against When to Use / When NOT to use. Trivial problem → redirect. Creative exploration → not yet.\n3. Elicit their specific problem to decompose. *\"My business has problems\"* is too vague; need a concrete question — *\"why is our gross margin declining?\"*, *\"what are the options for resolving this escalation?\"* > **[WAIT — do not advance until user responds]**\n4. Walk through Level 1 of the decomposition one step at a time, check ME and CE, then Level 2 if needed. > **[WAIT — do not advance until user responds]**\n5. Close by naming the load-bearing branch — they leave knowing where to focus, confident nothing important is missing. > **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **MECE Decomposition**: define the whole → propose top split → check ME AND CE → iterate → identify load-bearing branch.\n\n1. **State the whole precisely.** \"Our business\" is not the whole; \"*revenue this fiscal year by customer segment*\" is.\n2. **Propose a top-level split (2–7 categories).** Common dimensions: customer segment, geography, product line, time period, formula component (revenue = price × volume), life-cycle stage, cause type.\n3. **Test Mutual Exclusivity.** For each pair: is there any case that belongs to both? If yes, refine until no item can belong to more than one branch.\n4. **Test Collective Exhaustiveness.** What case is *not* covered? Add an explicit \"other\" or \"future\" branch if needed.\n4a. **Sum-to-whole test.** Do the branches add up to the whole? If not, identify what's missing or double-counted.\n5. **Recurse if needed.** Apply MECE to each branch. Stop when each leaf is actionable.\n6. **Identify the load-bearing branch.** Per pareto-principle, one or two branches carry disproportionate weight.\n7. **Document the structure.** The issue tree / Minto pyramid diagram is the standard shareable artifact.\n\n### Output: the MECE Decomposition\n\n```markdown\n# MECE Decomposition: \n## The whole: \n## Top-level split (Level 1): Branch A / Branch B / Branch C / (Other if needed)\n## ME test: A ∩ B = ? / A ∩ C = ? (refine until empty)\n## CE test: What is missing? / Sum = whole? (yes/no + what's added)\n## Sub-decomposition (Level 2, only if needed): A → A1 / A2 ...\n## Load-bearing branch: \n## Action implied: \n## Alternative decompositions considered: \n```\n\n*→ Method in Action: [Lou Gerstner's IBM Turnaround Decomposition (1993)](examples/lou-gerstner-ibm-turnaround-decomposition-1993.md)*\n*→ 2026 lens: [Structuring an AI-Stack Market Strategy MECE (2024–2026)](examples/ai-stack-market-strategy-decomposition-2024-2026.md)*\n\n## Decomposition Packs\n\nCanonical MECE dimensions by domain: **Profit/margin** — Revenue = Price × Volume; Cost = Fixed + Variable. **Customer segmentation** — industry / size / use case / buying mode. **Strategy options** — axis of competition; build/buy/partner; time horizon. **Failure-mode** (see inversion) — technical / human / process / environmental.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n\n## Applying It Well\n\n- **MECE is the test, not the brainstorm.** Propose first; then check ME AND CE. Most people skip the check.\n- **The dimension matters more than the depth.** Wrong Level 1 dimension makes Level 2 useless. Try 2–3 before committing.\n- **Sum back to the whole.** If branches don't sum, the decomposition is broken.\n- **\"Other\" is sometimes the right branch.** Forcing named categories creates fake exhaustiveness.\n- **Stop when the leaf is actionable.** Decomposing past action is paralysis.\n\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] **Claiming MECE without testing** | \"These are the three options\" is not MECE until tested. Run the overlap check AND the gap check. |\n| [D] **Overlapping categories** (\"Big customers / Important customers\") | These overlap. Refine — perhaps by quantitative threshold — until disjoint. |\n| [D] **Missing the residual** | Geography split into \"North America / Europe / Asia\" misses Latin America, Africa, Oceania. Add \"Other\" explicitly. |\n| [D] **Wrong dimension chosen** | Product-line decomposition was MECE but missed the customer-buying-mode dimension that mattered. Try alternatives. |\n| [D] **Decomposing trivial problems** | Lunch decisions don't need MECE. Reserve it for problems with large surface area. |\n| [D] **Going too deep** | Decomposing past actionable leaves produces complexity without insight. |\n| [D] **Fake \"Other\" branches** | An \"Other\" capturing > 30% of the whole means the dimension is wrong. Rethink the split. |\n| [D] **Not summing back to the whole** | The most reliable MECE test is arithmetic. Skipping it lets broken decompositions look fine. |\n| [D] **Treating MECE as the analysis** | MECE produces *the structure*; analysis happens *within* the structure. A MECE diagram with no investigation is wall art. |\n| [D] **Single decomposition without alternatives** | Most analytical disagreements are about *which* decomposition. Consider 2–3 dimensions before committing. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- \"These are MECE\" stated without overlap and gap tests\n- An \"Other\" category capturing > 30% of the whole\n- Categories that share obvious cases (e.g., \"Big customers\" and \"Important customers\")\n- The decomposition was inherited / copied without checking\n- The branches don't sum to the original whole\n- Only one decomposition dimension was considered\n- The decomposition goes 5+ levels deep without action at the leaves\n\n## Verification\n\n- [ ] Whole stated precisely and measurable; top-level dimension named and justified\n- [ ] ME explicitly checked between every pair; CE checked (missing-case test)\n- [ ] Branches sum back to the whole (arithmetic test)\n- [ ] Each leaf is *actionable*; at least one alternative dimension was considered\n- [ ] Load-bearing branch identified\n\n---\n\n*Part of **deciqAI Knowledge Skills** — 227 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/c/mece** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\n*Agents: latest version & machine-readable metadata → https://www.deciqai.com/s/mece.json*\n\nFile v1.0.5:_meta.json\n\n{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"mece\",\n \"version\": \"1.0.5\",\n \"publishedAt\": 1784225162579\n}\n\nFile v1.0.5:references/sources.md\n\n# Sources — mece\n\n> *Primary sources for the [mece](../SKILL.md) skill.*\n\n- **Minto, Barbara.** *The Pyramid Principle: Logic in Writing, Thinking and Problem Solving*. 1st ed. 1978; 3rd ed., Financial Times Prentice Hall (Pearson), 2002. **Primary source for MECE and pyramid-structured analysis**.\n- **Rasiel, Ethan M.** *The McKinsey Way: Using the Techniques of the World's Top Strategic Consultants to Help You and Your Business*. McGraw-Hill, 1999. **Documentation of McKinsey's internal use of MECE**.\n- **Gerstner, Louis V., Jr.** *Who Says Elephants Can't Dance? Inside IBM's Historic Turnaround*. HarperBusiness, 2002. **Primary source for the IBM 1993 turnaround decision case**.\n- **IBM Corporation,** Annual Reports and SEC 10-K filings, 1993–2002. **Primary-source empirical outcome data**: https://www.ibm.com/investor/\n- The popular phrase \"no overlap, no gap\" is the **operational summary** — accurate, but the rigor is in the *test* (sum back to the whole), not the slogan.\n- **Nvidia Corporation,** quarterly earnings releases and investor materials, FY2024–FY2025: https://investor.nvidia.com/ — **primary-source data on AI data-center GPU demand and the compute layer of the AI stack** (used in the 2024–2026 AI-strategy example).\n- **Microsoft, Amazon (AWS), and Alphabet (Google),** quarterly earnings and capital-expenditure guidance, 2024–2025 (each firm's investor-relations disclosures) — **primary-source documentation of hyperscaler AI-infrastructure build-out**; the chips / cloud / models / applications layering is the widely-used industry taxonomy for the AI value chain as of early 2026.\n\nFile v1.0.5:examples/ai-stack-market-strategy-decomposition-2024-2026.md\n\n# Method in Action: Structuring an AI-Stack Market Strategy MECE (2024–2026)\n\n> *Example for the [mece](../SKILL.md) skill.*\n\nA worked example for the AI-hype era. When a leadership team says *\"we need an AI strategy,\"* the conversation usually collapses into a jumble of overlapping buzzwords — foundation models, GPUs, copilots, agents, RAG — that double-count some things and silently omit others. MECE turns that jumble into a structure the strategy discussion can actually close over.\n\nThe observable backdrop (all public and widely reported before early 2026): the generative-AI wave that began with the November 2022 release of OpenAI's ChatGPT accelerated through 2024–2025. Nvidia's data-center GPUs became the scarce input for training frontier models; the major cloud providers (Microsoft Azure, Amazon AWS, Google Cloud) raised capital-expenditure guidance sharply to build AI infrastructure; a small set of labs (OpenAI, Anthropic, Google DeepMind, Meta, Mistral, and others) shipped competing frontier and open-weight models; and an application layer of copilots and \"agents\" proliferated on top. Alongside the build-out ran a persistent hype-vs-adoption debate — how much of the spending would convert into durable enterprise value.\n\nThe strategy question: *where in this stack should we play, and is our current plan covering the whole board or just the loudest layer?* Walk the **MECE Decomposition**.\n\n- **State the whole precisely (Step 1):** Not \"our AI strategy.\" The whole is *\"the full set of value-capture positions in the generative-AI market that our company could occupy or depend on, 2024–2026.\"* Measurable subject: every dollar of AI spend flows through some layer of the stack — we want a partition of those layers.\n\n- **Propose a top-level split (Step 2):** Segment by **layer of the AI stack** — the dimension that matches how value and margin actually flow:\n 1. **Compute / chips** — AI accelerators and the hardware supply chain (Nvidia GPUs, custom silicon like Google TPUs and AWS Trainium, memory, networking).\n 2. **Cloud / infrastructure** — the hosting, orchestration, and MLOps layer that rents that compute (hyperscaler AI platforms, GPU clouds, inference serving).\n 3. **Models / foundation models** — the trained frontier and open-weight models and the labs that produce them.\n 4. **Applications** — the software that end-users touch: copilots, vertical AI apps, and agentic products built on the models.\n\n- **Test Mutual Exclusivity (Step 3):** Check every pair. A GPU (layer 1) is a physical accelerator; a cloud region renting it out (layer 2) is a service contract; the model weights (layer 3) are trained artifacts; the app (layer 4) is the end-user product. A given *dollar of activity* sits in exactly one layer. The genuine trap is vertical integration — Google designs chips **and** runs a cloud **and** trains models **and** ships apps; Microsoft partners on models **and** sells cloud **and** ships Copilot. But MECE partitions the *activities*, not the *companies*. Assign each activity to one layer and the categories stay disjoint. ME holds ✓ (once you decompose by activity, not by firm).\n\n- **Test Collective Exhaustiveness (Step 4):** What is not covered? Two things the four layers omit: **(a) data** — proprietary training and grounding data, which is an input, not a layer; and **(b) tooling/middleware** — vector databases, orchestration frameworks, evaluation and safety tooling that sit *between* models and apps. Add an explicit fifth branch, **\"Data & middleware,\"** rather than pretending the four clean layers cover everything. With that residual added, the branches cover every position in the market. CE holds ✓.\n\n- **Sum-to-whole test (Step 4a):** Does end-to-end AI spend reconcile? A dollar an enterprise pays for an AI feature flows down: app vendor → model/API → cloud inference → chips, with data/middleware consumed along the way. Every dollar lands in one and only one layer at each hop; the layers sum to the whole value chain. No double-counting, no gap ✓.\n\n- **Recurse where it pays (Step 5):** Only the branch we intend to occupy needs sub-decomposition. For **Applications**, a useful Level-2 MECE split is by *buyer relationship*: horizontal copilots (embedded in existing suites) / vertical AI apps (industry-specific) / agentic workflow products (task-completing agents) / AI-native infrastructure-for-builders. Stop when each leaf maps to a concrete go-to-market motion.\n\n- **Identify the load-bearing branch (Step 6):** Per [pareto-principle](../pareto-principle/SKILL.md), the branches are not equal. Through 2024–2025 the **compute/chips** layer captured a strikingly disproportionate share of realized profit and market-value gains (Nvidia's rise being the vivid case), while the **applications** layer captured the most *strategic optionality* but faced the hardest question — whether AI features convert to durable revenue and defensible moats rather than commoditized wrappers over someone else's model. For most operating companies that neither fab chips nor train frontier models, the load-bearing branch is **Applications** (where they can differentiate) with a hard **dependency** on layers 1–3 (which set their cost floor and can be disrupted from beneath them).\n\n- **Action implied (Step 7):** The decomposition forces the real questions per layer instead of one fuzzy \"AI strategy\": *Which layer(s) do we occupy? Which do we depend on and therefore must de-risk (multi-model, multi-cloud) against price and supply shocks? Where is the margin actually being captured today vs. where will it migrate?* A plan that only names \"we'll build AI copilots\" is now visibly a **layer-4-only plan** with unexamined layer-1-through-3 dependencies — which is exactly the gap MECE was meant to expose.\n\n- **Alternatives considered (Step 7):** The stack-layer dimension is not the only MECE cut. You could instead partition by **enterprise use case** (customer support / code generation / knowledge search / marketing content / data analysis) — MECE on *demand* rather than *supply*, better for prioritizing where to deploy AI internally. Or by **build/buy/partner** for each capability. The stack-layer cut is best for a *market-positioning* question; the use-case cut is best for an *adoption/deployment* question. Naming which question you're answering picks the dimension — and, as in the IBM case, most \"AI strategy\" disagreements are really disagreements about *which decomposition* is on the table.\n\nThe lesson the framework names: in a hype cycle, the loudest layer (whichever one is minting headlines this quarter) crowds out the rest of the board. A MECE stack partition makes the whole board visible at once — so the strategy conversation is **complete** (no omitted layer or dependency) and **non-redundant** (no buzzword counted twice) — and it makes explicit that a single-layer plan is a bet *with dependencies*, not a whole strategy.\n\n*Sources: Barbara Minto, *The Pyramid Principle* (1st ed. 1978; 3rd ed., Financial Times Prentice Hall / Pearson, 2002) — MECE method. OpenAI, ChatGPT public launch, November 2022 (widely reported). Nvidia Corporation, quarterly earnings and investor materials, FY2024–FY2025, https://investor.nvidia.com/ — data-center GPU demand. Microsoft, Amazon, and Alphabet quarterly earnings and capital-expenditure guidance, 2024–2025 (each company's investor-relations disclosures) — AI infrastructure build-out. The stack-layer framing (chips / cloud / models / applications) is the widely-used industry taxonomy for the AI value chain as of early 2026.*\n\nFile v1.0.5:examples/lou-gerstner-ibm-turnaround-decomposition-1993.md\n\n# Method in Action: Lou Gerstner's IBM Turnaround Decomposition (1993)\n\n> *Example for the [mece](../SKILL.md) skill.*\n\nA worked example. Not management folklore — primary-source documented in Lou Gerstner's own account *Who Says Elephants Can't Dance?* (HarperBusiness, 2002).\n\nIn **April 1993**, **Louis V. Gerstner Jr.** took over as CEO of **IBM**, then in the worst crisis in its history. IBM had lost $16 billion over the prior three years, stock was at a 17-year low, and the board's then-consensus plan was to **break up the company** into autonomous business units — selling some, spinning others off. The breakup plan had been formally proposed by an internal task force, supported by external consultants (including parts of McKinsey), and was the public expectation when Gerstner arrived.\n\nGerstner, in his first 90 days, made what he later called \"the most important decision of my career\": he stopped to ask whether the breakup decomposition was *MECE*. The board's analysis had decomposed IBM by **product line** (mainframes, PCs, software, services, etc.), concluding that each line could function as a standalone business. Gerstner asked a different question, with a different decomposition:\n\n> \"Sometimes the most important consulting work is teaching people to ask different questions. The fundamental issue was not 'should we break the company up?' but 'what does the customer want?'. When I asked our biggest customers, none of them wanted to deal with five smaller IBMs. They wanted exactly the opposite — they wanted an *integrated solutions provider* who could handle the whole stack.\"\n> — Lou Gerstner, *Who Says Elephants Can't Dance?* (HarperBusiness, 2002), ch. 8.\n\nWalk the MECE Decomposition on the IBM 1993 decision:\n\n- **The whole (Step 1):** *\"How should IBM be structured to maximize long-term shareholder value, given the 1993 market position?\"*\n- **The board's decomposition (alternative considered):** By product line — Mainframes / PCs / Software / Services / Storage. **MECE on product**, but missing the question of how customers actually buy.\n- **Gerstner's proposed top-level split (Step 2):** **By how customers buy** — Customers who want point products (single hardware or software item) / Customers who want integrated multi-vendor solutions / Customers who want a single full-stack provider managed under one contract.\n- **ME test (Step 3):** Each customer at a given time buys in *one* of these three modes. Mutually exclusive ✓.\n- **CE test (Step 4):** Are there other modes? Customers who want pure consulting without products? Yes — add a fourth branch \"Pure advisory.\" Sum of the four branches covers all enterprise IT customers in 1993. Exhaustive ✓.\n- **Load-bearing branch (Step 6):** Mode 3 (single full-stack provider) was the segment that **only IBM could serve** — competitors (Microsoft, Sun, Oracle) were strong in single product categories but had no integrated full-stack offering. **This segment was growing and most profitable.**\n- **Action implied (Step 7):** *Do not break up.* Reorient IBM around integrated solutions for Mode 3 customers. Specifically: invest in the IBM Global Services business; consolidate the company's go-to-market under solution-oriented sales; price by full-stack solution rather than by component.\n- **Alternatives considered:** Product-line decomposition (board's plan) was MECE on a *different* dimension but missed the customer-buying-mode dimension that turned out to be load-bearing.\n\nThe result, documented in IBM's SEC filings and Gerstner's memoir: from 1993 to 2002, IBM's market capitalization grew from approximately $30 billion to over $180 billion, and Global Services (the integrated-solutions business unit Gerstner created) grew from ~$7B to ~$35B in annual revenue. **The framework's payoff was not \"stop the breakup\"; it was that the *original decomposition* was MECE on the wrong dimension** — and finding the right dimension changed which strategy looked correct.\n\nThe lesson the framework names: **a MECE decomposition is only as good as the dimension chosen**. Most strategic disagreements are not disagreements about facts within a shared decomposition; they are disagreements about *which decomposition to use*. Surfacing the alternative decomposition is what changes the conversation.\n\nFile v1.0.5:skill-card.md\n\n## Description:\n\nGuides an agent to decompose complex, overlapping, or circular problems into mutually exclusive and collectively exhaustive issue trees that can be checked for gaps, overlaps, and load-bearing branches.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[deciqai](https://clawhub.ai/user/deciqai)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nEmployees, external users, developers, and agents use this skill to structure strategy, planning, troubleshooting, and presentation problems into complete non-overlapping decompositions before analysis or action.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can over-structure conversations where the user wanted creative exploration or where the problem is too small to justify a MECE process.\n\nMitigation: Use the documented fit check before activating and narrow activation wording when automatic issue-tree framing is not desired.\n\nRisk: A decomposition can look rigorous while using the wrong top-level dimension, omitting cases, or double-counting branches.\n\nMitigation: Run the documented mutual exclusivity, collective exhaustiveness, sum-to-whole, and alternative-dimension checks before relying on the output.\n\n## Reference(s):\n\n- [Sources - mece](references/sources.md)\n- [Lou Gerstner's IBM Turnaround Decomposition (1993)](examples/lou-gerstner-ibm-turnaround-decomposition-1993.md)\n- [Structuring an AI-Stack Market Strategy MECE (2024-2026)](examples/ai-stack-market-strategy-decomposition-2024-2026.md)\n- [IBM Investor Relations](https://www.ibm.com/investor/)\n- [NVIDIA Investor Relations](https://investor.nvidia.com/)\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Guidance, Analysis]\n\n**Output Format:** [Markdown issue-tree decomposition with checks and recommended action]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May ask step-by-step coaching questions and wait for user input before continuing.]\n\n## Skill Version(s):\n\n1.0.5 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.0.4: 6 files, 13003 bytes\n\nFiles: examples/ai-stack-market-strategy-decomposition-2024-2026.md (7662b), examples/lou-gerstner-ibm-turnaround-decomposition-1993.md (4324b), references/sources.md (1638b), skill-card.md (2174b), SKILL.md (9375b), _meta.json (123b)\n\nFile v1.0.4:SKILL.md\n\n---\nname: mece\ndescription: \"Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-counting', a problem feels too big to think about cleanly, a list of options is messy or overlapping, an analysis keeps going in circles, or a presentation needs to survive hard scrutiny.\n Do NOT activate when: the problem is trivially small (lunch decisions), or the user is in purely creative/generative mode where premature structure would constrain exploration.\"\n---\n\n# MECE (Mutually Exclusive, Collectively Exhaustive)\n\n## Overview\n\n**MECE** is a decomposition principle: break a problem, set of options, or population into sub-groups that are **Mutually Exclusive** (no overlap) and **Collectively Exhaustive** (no gaps) — every relevant item covered exactly once. Operationalized by **Barbara Minto** at McKinsey (1963–1973) in *The Pyramid Principle* (1973; 3rd ed. 2002). The test: sum the pieces back to the whole; if they don't sum cleanly, the decomposition is broken.\n\n**Compose:** use first-principles to reach root variables; pareto-principle to find load-bearing branches; critical-thinking to test whether categories are the *right* ones; occams-razor when multiple MECE structures fit — pick the simplest.\n\n## When to Use\n\n- Problem feels **too big to think about cleanly** — surface area is unclear\n- **List of options** is messy or overlapping — competing answers that aren't parallel\n- Analysis is **going in circles** — same issues reappear because they're not separated\n- **Presentation** must convince hard-to-convince listeners\n- Team converging on a hypothesis **without considering the full space** of alternatives\n- Structuring an **AI strategy / AI-stack / AI-adoption** discussion so the layers (chips / cloud / models / apps) or use cases have no overlaps and no gaps — cutting through AI hype to a complete, non-redundant map\n- Someone says: *\"MECE,\" \"decompose this,\" \"issue tree,\" \"structure this thinking\"*\n\n**When NOT to use:** trivially small problem; purely creative/generative mode; genuinely non-decomposable question (some ethical/aesthetic problems resist this); decomposition already known and well-trodden.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete case → run The Process directly.\n- **Coach mode:** user is unfamiliar or has no concrete case → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: MECE is **breaking a problem into pieces that don't overlap AND don't leave gaps** — every relevant thing is covered exactly once. The check: do the pieces sum back to the whole?\n2. Check fit against When to Use / When NOT to use. Trivial problem → redirect. Creative exploration → not yet.\n3. Elicit their specific problem to decompose. *\"My business has problems\"* is too vague; need a concrete question — *\"why is our gross margin declining?\"*, *\"what are the options for resolving this escalation?\"* > **[WAIT — do not advance until user responds]**\n4. Walk through Level 1 of the decomposition one step at a time, check ME and CE, then Level 2 if needed. > **[WAIT — do not advance until user responds]**\n5. Close by naming the load-bearing branch — they leave knowing where to focus, confident nothing important is missing. > **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **MECE Decomposition**: define the whole → propose top split → check ME AND CE → iterate → identify load-bearing branch.\n\n1. **State the whole precisely.** \"Our business\" is not the whole; \"*revenue this fiscal year by customer segment*\" is.\n2. **Propose a top-level split (2–7 categories).** Common dimensions: customer segment, geography, product line, time period, formula component (revenue = price × volume), life-cycle stage, cause type.\n3. **Test Mutual Exclusivity.** For each pair: is there any case that belongs to both? If yes, refine until no item can belong to more than one branch.\n4. **Test Collective Exhaustiveness.** What case is *not* covered? Add an explicit \"other\" or \"future\" branch if needed.\n4a. **Sum-to-whole test.** Do the branches add up to the whole? If not, identify what's missing or double-counted.\n5. **Recurse if needed.** Apply MECE to each branch. Stop when each leaf is actionable.\n6. **Identify the load-bearing branch.** Per pareto-principle, one or two branches carry disproportionate weight.\n7. **Document the structure.** The issue tree / Minto pyramid diagram is the standard shareable artifact.\n\n### Output: the MECE Decomposition\n\n```markdown\n# MECE Decomposition: \n## The whole: \n## Top-level split (Level 1): Branch A / Branch B / Branch C / (Other if needed)\n## ME test: A ∩ B = ? / A ∩ C = ? (refine until empty)\n## CE test: What is missing? / Sum = whole? (yes/no + what's added)\n## Sub-decomposition (Level 2, only if needed): A → A1 / A2 ...\n## Load-bearing branch: \n## Action implied: \n## Alternative decompositions considered: \n```\n\n*→ Method in Action: [Lou Gerstner's IBM Turnaround Decomposition (1993)](examples/lou-gerstner-ibm-turnaround-decomposition-1993.md)*\n*→ 2026 lens: [Structuring an AI-Stack Market Strategy MECE (2024–2026)](examples/ai-stack-market-strategy-decomposition-2024-2026.md)*\n\n## Decomposition Packs\n\nCanonical MECE dimensions by domain: **Profit/margin** — Revenue = Price × Volume; Cost = Fixed + Variable. **Customer segmentation** — industry / size / use case / buying mode. **Strategy options** — axis of competition; build/buy/partner; time horizon. **Failure-mode** (see inversion) — technical / human / process / environmental.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n\n## Applying It Well\n\n- **MECE is the test, not the brainstorm.** Propose first; then check ME AND CE. Most people skip the check.\n- **The dimension matters more than the depth.** Wrong Level 1 dimension makes Level 2 useless. Try 2–3 before committing.\n- **Sum back to the whole.** If branches don't sum, the decomposition is broken.\n- **\"Other\" is sometimes the right branch.** Forcing named categories creates fake exhaustiveness.\n- **Stop when the leaf is actionable.** Decomposing past action is paralysis.\n\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] **Claiming MECE without testing** | \"These are the three options\" is not MECE until tested. Run the overlap check AND the gap check. |\n| [D] **Overlapping categories** (\"Big customers / Important customers\") | These overlap. Refine — perhaps by quantitative threshold — until disjoint. |\n| [D] **Missing the residual** | Geography split into \"North America / Europe / Asia\" misses Latin America, Africa, Oceania. Add \"Other\" explicitly. |\n| [D] **Wrong dimension chosen** | Product-line decomposition was MECE but missed the customer-buying-mode dimension that mattered. Try alternatives. |\n| [D] **Decomposing trivial problems** | Lunch decisions don't need MECE. Reserve it for problems with large surface area. |\n| [D] **Going too deep** | Decomposing past actionable leaves produces complexity without insight. |\n| [D] **Fake \"Other\" branches** | An \"Other\" capturing > 30% of the whole means the dimension is wrong. Rethink the split. |\n| [D] **Not summing back to the whole** | The most reliable MECE test is arithmetic. Skipping it lets broken decompositions look fine. |\n| [D] **Treating MECE as the analysis** | MECE produces *the structure*; analysis happens *within* the structure. A MECE diagram with no investigation is wall art. |\n| [D] **Single decomposition without alternatives** | Most analytical disagreements are about *which* decomposition. Consider 2–3 dimensions before committing. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- \"These are MECE\" stated without overlap and gap tests\n- An \"Other\" category capturing > 30% of the whole\n- Categories that share obvious cases (e.g., \"Big customers\" and \"Important customers\")\n- The decomposition was inherited / copied without checking\n- The branches don't sum to the original whole\n- Only one decomposition dimension was considered\n- The decomposition goes 5+ levels deep without action at the leaves\n\n## Verification\n\n- [ ] Whole stated precisely and measurable; top-level dimension named and justified\n- [ ] ME explicitly checked between every pair; CE checked (missing-case test)\n- [ ] Branches sum back to the whole (arithmetic test)\n- [ ] Each leaf is *actionable*; at least one alternative dimension was considered\n- [ ] Load-bearing branch identified\n\n---\n\n*Part of **deciqAI Knowledge Skills** — 223 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/c/mece** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\nFile v1.0.4:_meta.json\n\n{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"mece\",\n \"version\": \"1.0.4\",\n \"publishedAt\": 1783679236939\n}\n\nFile v1.0.4:references/sources.md\n\n# Sources — mece\n\n> *Primary sources for the [mece](../SKILL.md) skill.*\n\n- **Minto, Barbara.** *The Pyramid Principle: Logic in Writing, Thinking and Problem Solving*. 1st ed. 1978; 3rd ed., Financial Times Prentice Hall (Pearson), 2002. **Primary source for MECE and pyramid-structured analysis**.\n- **Rasiel, Ethan M.** *The McKinsey Way: Using the Techniques of the World's Top Strategic Consultants to Help You and Your Business*. McGraw-Hill, 1999. **Documentation of McKinsey's internal use of MECE**.\n- **Gerstner, Louis V., Jr.** *Who Says Elephants Can't Dance? Inside IBM's Historic Turnaround*. HarperBusiness, 2002. **Primary source for the IBM 1993 turnaround decision case**.\n- **IBM Corporation,** Annual Reports and SEC 10-K filings, 1993–2002. **Primary-source empirical outcome data**: https://www.ibm.com/investor/\n- The popular phrase \"no overlap, no gap\" is the **operational summary** — accurate, but the rigor is in the *test* (sum back to the whole), not the slogan.\n- **Nvidia Corporation,** quarterly earnings releases and investor materials, FY2024–FY2025: https://investor.nvidia.com/ — **primary-source data on AI data-center GPU demand and the compute layer of the AI stack** (used in the 2024–2026 AI-strategy example).\n- **Microsoft, Amazon (AWS), and Alphabet (Google),** quarterly earnings and capital-expenditure guidance, 2024–2025 (each firm's investor-relations disclosures) — **primary-source documentation of hyperscaler AI-infrastructure build-out**; the chips / cloud / models / applications layering is the widely-used industry taxonomy for the AI value chain as of early 2026.\n\nFile v1.0.4:examples/ai-stack-market-strategy-decomposition-2024-2026.md\n\n# Method in Action: Structuring an AI-Stack Market Strategy MECE (2024–2026)\n\n> *Example for the [mece](../SKILL.md) skill.*\n\nA worked example for the AI-hype era. When a leadership team says *\"we need an AI strategy,\"* the conversation usually collapses into a jumble of overlapping buzzwords — foundation models, GPUs, copilots, agents, RAG — that double-count some things and silently omit others. MECE turns that jumble into a structure the strategy discussion can actually close over.\n\nThe observable backdrop (all public and widely reported before early 2026): the generative-AI wave that began with the November 2022 release of OpenAI's ChatGPT accelerated through 2024–2025. Nvidia's data-center GPUs became the scarce input for training frontier models; the major cloud providers (Microsoft Azure, Amazon AWS, Google Cloud) raised capital-expenditure guidance sharply to build AI infrastructure; a small set of labs (OpenAI, Anthropic, Google DeepMind, Meta, Mistral, and others) shipped competing frontier and open-weight models; and an application layer of copilots and \"agents\" proliferated on top. Alongside the build-out ran a persistent hype-vs-adoption debate — how much of the spending would convert into durable enterprise value.\n\nThe strategy question: *where in this stack should we play, and is our current plan covering the whole board or just the loudest layer?* Walk the **MECE Decomposition**.\n\n- **State the whole precisely (Step 1):** Not \"our AI strategy.\" The whole is *\"the full set of value-capture positions in the generative-AI market that our company could occupy or depend on, 2024–2026.\"* Measurable subject: every dollar of AI spend flows through some layer of the stack — we want a partition of those layers.\n\n- **Propose a top-level split (Step 2):** Segment by **layer of the AI stack** — the dimension that matches how value and margin actually flow:\n 1. **Compute / chips** — AI accelerators and the hardware supply chain (Nvidia GPUs, custom silicon like Google TPUs and AWS Trainium, memory, networking).\n 2. **Cloud / infrastructure** — the hosting, orchestration, and MLOps layer that rents that compute (hyperscaler AI platforms, GPU clouds, inference serving).\n 3. **Models / foundation models** — the trained frontier and open-weight models and the labs that produce them.\n 4. **Applications** — the software that end-users touch: copilots, vertical AI apps, and agentic products built on the models.\n\n- **Test Mutual Exclusivity (Step 3):** Check every pair. A GPU (layer 1) is a physical accelerator; a cloud region renting it out (layer 2) is a service contract; the model weights (layer 3) are trained artifacts; the app (layer 4) is the end-user product. A given *dollar of activity* sits in exactly one layer. The genuine trap is vertical integration — Google designs chips **and** runs a cloud **and** trains models **and** ships apps; Microsoft partners on models **and** sells cloud **and** ships Copilot. But MECE partitions the *activities*, not the *companies*. Assign each activity to one layer and the categories stay disjoint. ME holds ✓ (once you decompose by activity, not by firm).\n\n- **Test Collective Exhaustiveness (Step 4):** What is not covered? Two things the four layers omit: **(a) data** — proprietary training and grounding data, which is an input, not a layer; and **(b) tooling/middleware** — vector databases, orchestration frameworks, evaluation and safety tooling that sit *between* models and apps. Add an explicit fifth branch, **\"Data & middleware,\"** rather than pretending the four clean layers cover everything. With that residual added, the branches cover every position in the market. CE holds ✓.\n\n- **Sum-to-whole test (Step 4a):** Does end-to-end AI spend reconcile? A dollar an enterprise pays for an AI feature flows down: app vendor → model/API → cloud inference → chips, with data/middleware consumed along the way. Every dollar lands in one and only one layer at each hop; the layers sum to the whole value chain. No double-counting, no gap ✓.\n\n- **Recurse where it pays (Step 5):** Only the branch we intend to occupy needs sub-decomposition. For **Applications**, a useful Level-2 MECE split is by *buyer relationship*: horizontal copilots (embedded in existing suites) / vertical AI apps (industry-specific) / agentic workflow products (task-completing agents) / AI-native infrastructure-for-builders. Stop when each leaf maps to a concrete go-to-market motion.\n\n- **Identify the load-bearing branch (Step 6):** Per [pareto-principle](../pareto-principle/SKILL.md), the branches are not equal. Through 2024–2025 the **compute/chips** layer captured a strikingly disproportionate share of realized profit and market-value gains (Nvidia's rise being the vivid case), while the **applications** layer captured the most *strategic optionality* but faced the hardest question — whether AI features convert to durable revenue and defensible moats rather than commoditized wrappers over someone else's model. For most operating companies that neither fab chips nor train frontier models, the load-bearing branch is **Applications** (where they can differentiate) with a hard **dependency** on layers 1–3 (which set their cost floor and can be disrupted from beneath them).\n\n- **Action implied (Step 7):** The decomposition forces the real questions per layer instead of one fuzzy \"AI strategy\": *Which layer(s) do we occupy? Which do we depend on and therefore must de-risk (multi-model, multi-cloud) against price and supply shocks? Where is the margin actually being captured today vs. where will it migrate?* A plan that only names \"we'll build AI copilots\" is now visibly a **layer-4-only plan** with unexamined layer-1-through-3 dependencies — which is exactly the gap MECE was meant to expose.\n\n- **Alternatives considered (Step 7):** The stack-layer dimension is not the only MECE cut. You could instead partition by **enterprise use case** (customer support / code generation / knowledge search / marketing content / data analysis) — MECE on *demand* rather than *supply*, better for prioritizing where to deploy AI internally. Or by **build/buy/partner** for each capability. The stack-layer cut is best for a *market-positioning* question; the use-case cut is best for an *adoption/deployment* question. Naming which question you're answering picks the dimension — and, as in the IBM case, most \"AI strategy\" disagreements are really disagreements about *which decomposition* is on the table.\n\nThe lesson the framework names: in a hype cycle, the loudest layer (whichever one is minting headlines this quarter) crowds out the rest of the board. A MECE stack partition makes the whole board visible at once — so the strategy conversation is **complete** (no omitted layer or dependency) and **non-redundant** (no buzzword counted twice) — and it makes explicit that a single-layer plan is a bet *with dependencies*, not a whole strategy.\n\n*Sources: Barbara Minto, *The Pyramid Principle* (1st ed. 1978; 3rd ed., Financial Times Prentice Hall / Pearson, 2002) — MECE method. OpenAI, ChatGPT public launch, November 2022 (widely reported). Nvidia Corporation, quarterly earnings and investor materials, FY2024–FY2025, https://investor.nvidia.com/ — data-center GPU demand. Microsoft, Amazon, and Alphabet quarterly earnings and capital-expenditure guidance, 2024–2025 (each company's investor-relations disclosures) — AI infrastructure build-out. The stack-layer framing (chips / cloud / models / applications) is the widely-used industry taxonomy for the AI value chain as of early 2026.*\n\nFile v1.0.4:examples/lou-gerstner-ibm-turnaround-decomposition-1993.md\n\n# Method in Action: Lou Gerstner's IBM Turnaround Decomposition (1993)\n\n> *Example for the [mece](../SKILL.md) skill.*\n\nA worked example. Not management folklore — primary-source documented in Lou Gerstner's own account *Who Says Elephants Can't Dance?* (HarperBusiness, 2002).\n\nIn **April 1993**, **Louis V. Gerstner Jr.** took over as CEO of **IBM**, then in the worst crisis in its history. IBM had lost $16 billion over the prior three years, stock was at a 17-year low, and the board's then-consensus plan was to **break up the company** into autonomous business units — selling some, spinning others off. The breakup plan had been formally proposed by an internal task force, supported by external consultants (including parts of McKinsey), and was the public expectation when Gerstner arrived.\n\nGerstner, in his first 90 days, made what he later called \"the most important decision of my career\": he stopped to ask whether the breakup decomposition was *MECE*. The board's analysis had decomposed IBM by **product line** (mainframes, PCs, software, services, etc.), concluding that each line could function as a standalone business. Gerstner asked a different question, with a different decomposition:\n\n> \"Sometimes the most important consulting work is teaching people to ask different questions. The fundamental issue was not 'should we break the company up?' but 'what does the customer want?'. When I asked our biggest customers, none of them wanted to deal with five smaller IBMs. They wanted exactly the opposite — they wanted an *integrated solutions provider* who could handle the whole stack.\"\n> — Lou Gerstner, *Who Says Elephants Can't Dance?* (HarperBusiness, 2002), ch. 8.\n\nWalk the MECE Decomposition on the IBM 1993 decision:\n\n- **The whole (Step 1):** *\"How should IBM be structured to maximize long-term shareholder value, given the 1993 market position?\"*\n- **The board's decomposition (alternative considered):** By product line — Mainframes / PCs / Software / Services / Storage. **MECE on product**, but missing the question of how customers actually buy.\n- **Gerstner's proposed top-level split (Step 2):** **By how customers buy** — Customers who want point products (single hardware or software item) / Customers who want integrated multi-vendor solutions / Customers who want a single full-stack provider managed under one contract.\n- **ME test (Step 3):** Each customer at a given time buys in *one* of these three modes. Mutually exclusive ✓.\n- **CE test (Step 4):** Are there other modes? Customers who want pure consulting without products? Yes — add a fourth branch \"Pure advisory.\" Sum of the four branches covers all enterprise IT customers in 1993. Exhaustive ✓.\n- **Load-bearing branch (Step 6):** Mode 3 (single full-stack provider) was the segment that **only IBM could serve** — competitors (Microsoft, Sun, Oracle) were strong in single product categories but had no integrated full-stack offering. **This segment was growing and most profitable.**\n- **Action implied (Step 7):** *Do not break up.* Reorient IBM around integrated solutions for Mode 3 customers. Specifically: invest in the IBM Global Services business; consolidate the company's go-to-market under solution-oriented sales; price by full-stack solution rather than by component.\n- **Alternatives considered:** Product-line decomposition (board's plan) was MECE on a *different* dimension but missed the customer-buying-mode dimension that turned out to be load-bearing.\n\nThe result, documented in IBM's SEC filings and Gerstner's memoir: from 1993 to 2002, IBM's market capitalization grew from approximately $30 billion to over $180 billion, and Global Services (the integrated-solutions business unit Gerstner created) grew from ~$7B to ~$35B in annual revenue. **The framework's payoff was not \"stop the breakup\"; it was that the *original decomposition* was MECE on the wrong dimension** — and finding the right dimension changed which strategy looked correct.\n\nThe lesson the framework names: **a MECE decomposition is only as good as the dimension chosen**. Most strategic disagreements are not disagreements about facts within a shared decomposition; they are disagreements about *which decomposition to use*. Surfacing the alternative decomposition is what changes the conversation.\n\nFile v1.0.4:skill-card.md\n\n## Description:
\nMECE helps agents decompose complex problems into mutually exclusive, collectively exhaustive structures and check for gaps, overlaps, and load-bearing branches.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[deciqai](https://clawhub.ai/user/deciqai)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nEmployees, external users, and developers use this skill to structure complex business, strategy, or analytical questions into issue trees that can be tested for overlap, coverage, and actionability.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Generated decompositions can appear authoritative even when categories overlap, omit cases, or include unsupported factual or strategic claims.
\nMitigation: Review the mutual-exclusivity and collective-exhaustiveness checks, validate factual claims against source material, and treat recommendations as inputs to human decision-making.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/deciqai/skills/mece)
\n- [Primary sources for MECE](references/sources.md)
\n- [Lou Gerstner IBM turnaround example](examples/lou-gerstner-ibm-turnaround-decomposition-1993.md)
\n- [AI-stack market strategy example](examples/ai-stack-market-strategy-decomposition-2024-2026.md)
\n- [IBM investor materials](https://www.ibm.com/investor/)
\n- [NVIDIA investor materials](https://investor.nvidia.com/)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, guidance]
\n**Output Format:** [Markdown issue-tree guidance with structured checks]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [May pause for user input in coaching mode before advancing decomposition steps.]
\n\n## Skill Version(s):
\n1.0.4 (source: server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.3: 5 files, 8738 bytes\n\nFiles: examples/lou-gerstner-ibm-turnaround-decomposition-1993.md (4324b), references/sources.md (971b), skill-card.md (2353b), SKILL.md (9017b), _meta.json (123b)\n\nFile v1.0.3:SKILL.md\n\n---\nname: mece\ndescription: \"Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-counting', a problem feels too big to think about cleanly, a list of options is messy or overlapping, an analysis keeps going in circles, or a presentation needs to survive hard scrutiny.\n Do NOT activate when: the problem is trivially small (lunch decisions), or the user is in purely creative/generative mode where premature structure would constrain exploration.\"\n---\n\n# MECE (Mutually Exclusive, Collectively Exhaustive)\n\n## Overview\n\n**MECE** is a decomposition principle: break a problem, set of options, or population into sub-groups that are **Mutually Exclusive** (no overlap) and **Collectively Exhaustive** (no gaps) — every relevant item covered exactly once. Operationalized by **Barbara Minto** at McKinsey (1963–1973) in *The Pyramid Principle* (1973; 3rd ed. 2002). The test: sum the pieces back to the whole; if they don't sum cleanly, the decomposition is broken.\n\n**Compose:** use first-principles to reach root variables; pareto-principle to find load-bearing branches; critical-thinking to test whether categories are the *right* ones; occams-razor when multiple MECE structures fit — pick the simplest.\n\n## When to Use\n\n- Problem feels **too big to think about cleanly** — surface area is unclear\n- **List of options** is messy or overlapping — competing answers that aren't parallel\n- Analysis is **going in circles** — same issues reappear because they're not separated\n- **Presentation** must convince hard-to-convince listeners\n- Team converging on a hypothesis **without considering the full space** of alternatives\n- Someone says: *\"MECE,\" \"decompose this,\" \"issue tree,\" \"structure this thinking\"*\n\n**When NOT to use:** trivially small problem; purely creative/generative mode; genuinely non-decomposable question (some ethical/aesthetic problems resist this); decomposition already known and well-trodden.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete case → run The Process directly.\n- **Coach mode:** user is unfamiliar or has no concrete case → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: MECE is **breaking a problem into pieces that don't overlap AND don't leave gaps** — every relevant thing is covered exactly once. The check: do the pieces sum back to the whole?\n2. Check fit against When to Use / When NOT to use. Trivial problem → redirect. Creative exploration → not yet.\n3. Elicit their specific problem to decompose. *\"My business has problems\"* is too vague; need a concrete question — *\"why is our gross margin declining?\"*, *\"what are the options for resolving this escalation?\"* > **[WAIT — do not advance until user responds]**\n4. Walk through Level 1 of the decomposition one step at a time, check ME and CE, then Level 2 if needed. > **[WAIT — do not advance until user responds]**\n5. Close by naming the load-bearing branch — they leave knowing where to focus, confident nothing important is missing. > **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **MECE Decomposition**: define the whole → propose top split → check ME AND CE → iterate → identify load-bearing branch.\n\n1. **State the whole precisely.** \"Our business\" is not the whole; \"*revenue this fiscal year by customer segment*\" is.\n2. **Propose a top-level split (2–7 categories).** Common dimensions: customer segment, geography, product line, time period, formula component (revenue = price × volume), life-cycle stage, cause type.\n3. **Test Mutual Exclusivity.** For each pair: is there any case that belongs to both? If yes, refine until no item can belong to more than one branch.\n4. **Test Collective Exhaustiveness.** What case is *not* covered? Add an explicit \"other\" or \"future\" branch if needed.\n4a. **Sum-to-whole test.** Do the branches add up to the whole? If not, identify what's missing or double-counted.\n5. **Recurse if needed.** Apply MECE to each branch. Stop when each leaf is actionable.\n6. **Identify the load-bearing branch.** Per pareto-principle, one or two branches carry disproportionate weight.\n7. **Document the structure.** The issue tree / Minto pyramid diagram is the standard shareable artifact.\n\n### Output: the MECE Decomposition\n\n```markdown\n# MECE Decomposition: \n## The whole: \n## Top-level split (Level 1): Branch A / Branch B / Branch C / (Other if needed)\n## ME test: A ∩ B = ? / A ∩ C = ? (refine until empty)\n## CE test: What is missing? / Sum = whole? (yes/no + what's added)\n## Sub-decomposition (Level 2, only if needed): A → A1 / A2 ...\n## Load-bearing branch: \n## Action implied: \n## Alternative decompositions considered: \n```\n\n*→ Method in Action: [Lou Gerstner's IBM Turnaround Decomposition (1993)](examples/lou-gerstner-ibm-turnaround-decomposition-1993.md)*\n\n## Decomposition Packs\n\nCanonical MECE dimensions by domain: **Profit/margin** — Revenue = Price × Volume; Cost = Fixed + Variable. **Customer segmentation** — industry / size / use case / buying mode. **Strategy options** — axis of competition; build/buy/partner; time horizon. **Failure-mode** (see inversion) — technical / human / process / environmental.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n\n## Applying It Well\n\n- **MECE is the test, not the brainstorm.** Propose first; then check ME AND CE. Most people skip the check.\n- **The dimension matters more than the depth.** Wrong Level 1 dimension makes Level 2 useless. Try 2–3 before committing.\n- **Sum back to the whole.** If branches don't sum, the decomposition is broken.\n- **\"Other\" is sometimes the right branch.** Forcing named categories creates fake exhaustiveness.\n- **Stop when the leaf is actionable.** Decomposing past action is paralysis.\n\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] **Claiming MECE without testing** | \"These are the three options\" is not MECE until tested. Run the overlap check AND the gap check. |\n| [D] **Overlapping categories** (\"Big customers / Important customers\") | These overlap. Refine — perhaps by quantitative threshold — until disjoint. |\n| [D] **Missing the residual** | Geography split into \"North America / Europe / Asia\" misses Latin America, Africa, Oceania. Add \"Other\" explicitly. |\n| [D] **Wrong dimension chosen** | Product-line decomposition was MECE but missed the customer-buying-mode dimension that mattered. Try alternatives. |\n| [D] **Decomposing trivial problems** | Lunch decisions don't need MECE. Reserve it for problems with large surface area. |\n| [D] **Going too deep** | Decomposing past actionable leaves produces complexity without insight. |\n| [D] **Fake \"Other\" branches** | An \"Other\" capturing > 30% of the whole means the dimension is wrong. Rethink the split. |\n| [D] **Not summing back to the whole** | The most reliable MECE test is arithmetic. Skipping it lets broken decompositions look fine. |\n| [D] **Treating MECE as the analysis** | MECE produces *the structure*; analysis happens *within* the structure. A MECE diagram with no investigation is wall art. |\n| [D] **Single decomposition without alternatives** | Most analytical disagreements are about *which* decomposition. Consider 2–3 dimensions before committing. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- \"These are MECE\" stated without overlap and gap tests\n- An \"Other\" category capturing > 30% of the whole\n- Categories that share obvious cases (e.g., \"Big customers\" and \"Important customers\")\n- The decomposition was inherited / copied without checking\n- The branches don't sum to the original whole\n- Only one decomposition dimension was considered\n- The decomposition goes 5+ levels deep without action at the leaves\n\n## Verification\n\n- [ ] Whole stated precisely and measurable; top-level dimension named and justified\n- [ ] ME explicitly checked between every pair; CE checked (missing-case test)\n- [ ] Branches sum back to the whole (arithmetic test)\n- [ ] Each leaf is *actionable*; at least one alternative dimension was considered\n- [ ] Load-bearing branch identified\n\n---\n\n*Part of **deciqAI Knowledge Skills** — 164 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/c/mece** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\nFile v1.0.3:_meta.json\n\n{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"mece\",\n \"version\": \"1.0.3\",\n \"publishedAt\": 1783508961477\n}\n\nFile v1.0.3:references/sources.md\n\n# Sources — mece\n\n> *Primary sources for the [mece](../SKILL.md) skill.*\n\n- **Minto, Barbara.** *The Pyramid Principle: Logic in Writing, Thinking and Problem Solving*. Pearson Prentice Hall, 1973; 3rd ed. 2002. **Primary source for MECE and pyramid-structured analysis**.\n- **Rasiel, Ethan M.** *The McKinsey Way: Using the Techniques of the World's Top Strategic Consultants to Help You and Your Business*. McGraw-Hill, 1999. **Documentation of McKinsey's internal use of MECE**.\n- **Gerstner, Louis V., Jr.** *Who Says Elephants Can't Dance? Inside IBM's Historic Turnaround*. HarperBusiness, 2002. **Primary source for the IBM 1993 turnaround decision case**.\n- **IBM Corporation,** Annual Reports and SEC 10-K filings, 1993–2002. **Primary-source empirical outcome data**: https://www.ibm.com/investor/\n- The popular phrase \"no overlap, no gap\" is the **operational summary** — accurate, but the rigor is in the *test* (sum back to the whole), not the slogan.\n\nFile v1.0.3:examples/lou-gerstner-ibm-turnaround-decomposition-1993.md\n\n# Method in Action: Lou Gerstner's IBM Turnaround Decomposition (1993)\n\n> *Example for the [mece](../SKILL.md) skill.*\n\nA worked example. Not management folklore — primary-source documented in Lou Gerstner's own account *Who Says Elephants Can't Dance?* (HarperBusiness, 2002).\n\nIn **April 1993**, **Louis V. Gerstner Jr.** took over as CEO of **IBM**, then in the worst crisis in its history. IBM had lost $16 billion over the prior three years, stock was at a 17-year low, and the board's then-consensus plan was to **break up the company** into autonomous business units — selling some, spinning others off. The breakup plan had been formally proposed by an internal task force, supported by external consultants (including parts of McKinsey), and was the public expectation when Gerstner arrived.\n\nGerstner, in his first 90 days, made what he later called \"the most important decision of my career\": he stopped to ask whether the breakup decomposition was *MECE*. The board's analysis had decomposed IBM by **product line** (mainframes, PCs, software, services, etc.), concluding that each line could function as a standalone business. Gerstner asked a different question, with a different decomposition:\n\n> \"Sometimes the most important consulting work is teaching people to ask different questions. The fundamental issue was not 'should we break the company up?' but 'what does the customer want?'. When I asked our biggest customers, none of them wanted to deal with five smaller IBMs. They wanted exactly the opposite — they wanted an *integrated solutions provider* who could handle the whole stack.\"\n> — Lou Gerstner, *Who Says Elephants Can't Dance?* (HarperBusiness, 2002), ch. 8.\n\nWalk the MECE Decomposition on the IBM 1993 decision:\n\n- **The whole (Step 1):** *\"How should IBM be structured to maximize long-term shareholder value, given the 1993 market position?\"*\n- **The board's decomposition (alternative considered):** By product line — Mainframes / PCs / Software / Services / Storage. **MECE on product**, but missing the question of how customers actually buy.\n- **Gerstner's proposed top-level split (Step 2):** **By how customers buy** — Customers who want point products (single hardware or software item) / Customers who want integrated multi-vendor solutions / Customers who want a single full-stack provider managed under one contract.\n- **ME test (Step 3):** Each customer at a given time buys in *one* of these three modes. Mutually exclusive ✓.\n- **CE test (Step 4):** Are there other modes? Customers who want pure consulting without products? Yes — add a fourth branch \"Pure advisory.\" Sum of the four branches covers all enterprise IT customers in 1993. Exhaustive ✓.\n- **Load-bearing branch (Step 6):** Mode 3 (single full-stack provider) was the segment that **only IBM could serve** — competitors (Microsoft, Sun, Oracle) were strong in single product categories but had no integrated full-stack offering. **This segment was growing and most profitable.**\n- **Action implied (Step 7):** *Do not break up.* Reorient IBM around integrated solutions for Mode 3 customers. Specifically: invest in the IBM Global Services business; consolidate the company's go-to-market under solution-oriented sales; price by full-stack solution rather than by component.\n- **Alternatives considered:** Product-line decomposition (board's plan) was MECE on a *different* dimension but missed the customer-buying-mode dimension that turned out to be load-bearing.\n\nThe result, documented in IBM's SEC filings and Gerstner's memoir: from 1993 to 2002, IBM's market capitalization grew from approximately $30 billion to over $180 billion, and Global Services (the integrated-solutions business unit Gerstner created) grew from ~$7B to ~$35B in annual revenue. **The framework's payoff was not \"stop the breakup\"; it was that the *original decomposition* was MECE on the wrong dimension** — and finding the right dimension changed which strategy looked correct.\n\nThe lesson the framework names: **a MECE decomposition is only as good as the dimension chosen**. Most strategic disagreements are not disagreements about facts within a shared decomposition; they are disagreements about *which decomposition to use*. Surfacing the alternative decomposition is what changes the conversation.\n\nFile v1.0.3:skill-card.md\n\n## Description:
\nMECE helps agents structure complex problems into non-overlapping, collectively exhaustive decompositions, test for gaps and overlaps, and identify the branch most worth acting on.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[deciqai](https://clawhub.ai/user/deciqai)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nEmployees, external users, and developers use this skill to decompose messy strategic, operational, or analytical questions into clear issue trees. It is suited for problems where overlapping options, missing cases, or circular discussion make structured reasoning valuable.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill may steer broad or creative conversations into structured analysis when that is not what the user wants.
\nMitigation: Check fit before applying MECE and skip it for trivial decisions, early creative exploration, or when the user asks not to use the framework.
\nRisk: A decomposition can appear complete while still containing overlapping branches or missing cases.
\nMitigation: Review the generated structure with explicit mutual exclusivity, collective exhaustiveness, and sum-to-whole checks before relying on the result.
\n\n\n## Reference(s):
\n- [Sources - mece](references/sources.md)
\n- [Lou Gerstner's IBM Turnaround Decomposition (1993)](examples/lou-gerstner-ibm-turnaround-decomposition-1993.md)
\n- [IBM Investor Relations](https://www.ibm.com/investor/)
\n- [ClawHub Skill Page](https://clawhub.ai/deciqai/skills/mece)
\n\n\n## Skill Output:
\n**Output Type(s):** [Text, Markdown, Guidance]
\n**Output Format:** [Markdown issue-tree decomposition with named tests, branch summaries, and recommended next action.]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [May pause for user input in coach mode before continuing the decomposition.]
\n\n## Skill Version(s):
\n1.0.3 (source: server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.2: 5 files, 8770 bytes\n\nFiles: examples/lou-gerstner-ibm-turnaround-decomposition-1993.md (4324b), references/sources.md (971b), skill-card.md (2288b), SKILL.md (9111b), _meta.json (123b)\n\nFile v1.0.2:SKILL.md\n\n---\nname: mece\ndescription: \"Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-counting', a problem feels too big to think about cleanly, a list of options is messy or overlapping, an analysis keeps going in circles, or a presentation needs to survive hard scrutiny.\n Do NOT activate when: the problem is trivially small (lunch decisions), or the user is in purely creative/generative mode where premature structure would constrain exploration.\"\n---\n\n# MECE (Mutually Exclusive, Collectively Exhaustive)\n\n## Overview\n\n**MECE** is a decomposition principle: break a problem, set of options, or population into sub-groups that are **Mutually Exclusive** (no overlap) and **Collectively Exhaustive** (no gaps) — every relevant item covered exactly once. Operationalized by **Barbara Minto** at McKinsey (1963–1973) in *The Pyramid Principle* (1973; 3rd ed. 2002). The test: sum the pieces back to the whole; if they don't sum cleanly, the decomposition is broken.\n\n**Compose:** use first-principles to reach root variables; pareto-principle to find load-bearing branches; critical-thinking to test whether categories are the *right* ones; occams-razor when multiple MECE structures fit — pick the simplest.\n\n## When to Use\n\n- Problem feels **too big to think about cleanly** — surface area is unclear\n- **List of options** is messy or overlapping — competing answers that aren't parallel\n- Analysis is **going in circles** — same issues reappear because they're not separated\n- **Presentation** must convince hard-to-convince listeners\n- Team converging on a hypothesis **without considering the full space** of alternatives\n- Someone says: *\"MECE,\" \"decompose this,\" \"issue tree,\" \"structure this thinking\"*\n\n**When NOT to use:** trivially small problem; purely creative/generative mode; genuinely non-decomposable question (some ethical/aesthetic problems resist this); decomposition already known and well-trodden.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete case → run The Process directly.\n- **Coach mode:** user is unfamiliar or has no concrete case → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: MECE is **breaking a problem into pieces that don't overlap AND don't leave gaps** — every relevant thing is covered exactly once. The check: do the pieces sum back to the whole?\n2. Check fit against When to Use / When NOT to use. Trivial problem → redirect. Creative exploration → not yet.\n3. Elicit their specific problem to decompose. *\"My business has problems\"* is too vague; need a concrete question — *\"why is our gross margin declining?\"*, *\"what are the options for resolving this escalation?\"* > **[WAIT — do not advance until user responds]**\n4. Walk through Level 1 of the decomposition one step at a time, check ME and CE, then Level 2 if needed. > **[WAIT — do not advance until user responds]**\n5. Close by naming the load-bearing branch — they leave knowing where to focus, confident nothing important is missing. > **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **MECE Decomposition**: define the whole → propose top split → check ME AND CE → iterate → identify load-bearing branch.\n\n1. **State the whole precisely.** \"Our business\" is not the whole; \"*revenue this fiscal year by customer segment*\" is.\n2. **Propose a top-level split (2–7 categories).** Common dimensions: customer segment, geography, product line, time period, formula component (revenue = price × volume), life-cycle stage, cause type.\n3. **Test Mutual Exclusivity.** For each pair: is there any case that belongs to both? If yes, refine until no item can belong to more than one branch.\n4. **Test Collective Exhaustiveness.** What case is *not* covered? Add an explicit \"other\" or \"future\" branch if needed.\n4a. **Sum-to-whole test.** Do the branches add up to the whole? If not, identify what's missing or double-counted.\n5. **Recurse if needed.** Apply MECE to each branch. Stop when each leaf is actionable.\n6. **Identify the load-bearing branch.** Per pareto-principle, one or two branches carry disproportionate weight.\n7. **Document the structure.** The issue tree / Minto pyramid diagram is the standard shareable artifact.\n\n### Output: the MECE Decomposition\n\n```markdown\n# MECE Decomposition: \n## The whole: \n## Top-level split (Level 1): Branch A / Branch B / Branch C / (Other if needed)\n## ME test: A ∩ B = ? / A ∩ C = ? (refine until empty)\n## CE test: What is missing? / Sum = whole? (yes/no + what's added)\n## Sub-decomposition (Level 2, only if needed): A → A1 / A2 ...\n## Load-bearing branch: \n## Action implied: \n## Alternative decompositions considered: \n```\n\n*→ Method in Action: [Lou Gerstner's IBM Turnaround Decomposition (1993)](examples/lou-gerstner-ibm-turnaround-decomposition-1993.md)*\n\n## Decomposition Packs\n\nCanonical MECE dimensions by domain: **Profit/margin** — Revenue = Price × Volume; Cost = Fixed + Variable. **Customer segmentation** — industry / size / use case / buying mode. **Strategy options** — axis of competition; build/buy/partner; time horizon. **Failure-mode** (see inversion) — technical / human / process / environmental.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n\n## Applying It Well\n\n- **MECE is the test, not the brainstorm.** Propose first; then check ME AND CE. Most people skip the check.\n- **The dimension matters more than the depth.** Wrong Level 1 dimension makes Level 2 useless. Try 2–3 before committing.\n- **Sum back to the whole.** If branches don't sum, the decomposition is broken.\n- **\"Other\" is sometimes the right branch.** Forcing named categories creates fake exhaustiveness.\n- **Stop when the leaf is actionable.** Decomposing past action is paralysis.\n\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] **Claiming MECE without testing** | \"These are the three options\" is not MECE until tested. Run the overlap check AND the gap check. |\n| [D] **Overlapping categories** (\"Big customers / Important customers\") | These overlap. Refine — perhaps by quantitative threshold — until disjoint. |\n| [D] **Missing the residual** | Geography split into \"North America / Europe / Asia\" misses Latin America, Africa, Oceania. Add \"Other\" explicitly. |\n| [D] **Wrong dimension chosen** | Product-line decomposition was MECE but missed the customer-buying-mode dimension that mattered. Try alternatives. |\n| [D] **Decomposing trivial problems** | Lunch decisions don't need MECE. Reserve it for problems with large surface area. |\n| [D] **Going too deep** | Decomposing past actionable leaves produces complexity without insight. |\n| [D] **Fake \"Other\" branches** | An \"Other\" capturing > 30% of the whole means the dimension is wrong. Rethink the split. |\n| [D] **Not summing back to the whole** | The most reliable MECE test is arithmetic. Skipping it lets broken decompositions look fine. |\n| [D] **Treating MECE as the analysis** | MECE produces *the structure*; analysis happens *within* the structure. A MECE diagram with no investigation is wall art. |\n| [D] **Single decomposition without alternatives** | Most analytical disagreements are about *which* decomposition. Consider 2–3 dimensions before committing. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- \"These are MECE\" stated without overlap and gap tests\n- An \"Other\" category capturing > 30% of the whole\n- Categories that share obvious cases (e.g., \"Big customers\" and \"Important customers\")\n- The decomposition was inherited / copied without checking\n- The branches don't sum to the original whole\n- Only one decomposition dimension was considered\n- The decomposition goes 5+ levels deep without action at the leaves\n\n## Verification\n\n- [ ] Whole stated precisely and measurable; top-level dimension named and justified\n- [ ] ME explicitly checked between every pair; CE checked (missing-case test)\n- [ ] Branches sum back to the whole (arithmetic test)\n- [ ] Each leaf is *actionable*; at least one alternative dimension was considered\n- [ ] Load-bearing branch identified\n\n---\n\n*Part of **deciqAI Knowledge Skills** — 163 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/skills/mece?utm_source=clawhub&utm_medium=marketplace&utm_campaign=knowledge-skills&utm_content=mece** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\nFile v1.0.2:_meta.json\n\n{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"mece\",\n \"version\": \"1.0.2\",\n \"publishedAt\": 1783472064954\n}\n\nFile v1.0.2:references/sources.md\n\n# Sources — mece\n\n> *Primary sources for the [mece](../SKILL.md) skill.*\n\n- **Minto, Barbara.** *The Pyramid Principle: Logic in Writing, Thinking and Problem Solving*. Pearson Prentice Hall, 1973; 3rd ed. 2002. **Primary source for MECE and pyramid-structured analysis**.\n- **Rasiel, Ethan M.** *The McKinsey Way: Using the Techniques of the World's Top Strategic Consultants to Help You and Your Business*. McGraw-Hill, 1999. **Documentation of McKinsey's internal use of MECE**.\n- **Gerstner, Louis V., Jr.** *Who Says Elephants Can't Dance? Inside IBM's Historic Turnaround*. HarperBusiness, 2002. **Primary source for the IBM 1993 turnaround decision case**.\n- **IBM Corporation,** Annual Reports and SEC 10-K filings, 1993–2002. **Primary-source empirical outcome data**: https://www.ibm.com/investor/\n- The popular phrase \"no overlap, no gap\" is the **operational summary** — accurate, but the rigor is in the *test* (sum back to the whole), not the slogan.\n\nFile v1.0.2:examples/lou-gerstner-ibm-turnaround-decomposition-1993.md\n\n# Method in Action: Lou Gerstner's IBM Turnaround Decomposition (1993)\n\n> *Example for the [mece](../SKILL.md) skill.*\n\nA worked example. Not management folklore — primary-source documented in Lou Gerstner's own account *Who Says Elephants Can't Dance?* (HarperBusiness, 2002).\n\nIn **April 1993**, **Louis V. Gerstner Jr.** took over as CEO of **IBM**, then in the worst crisis in its history. IBM had lost $16 billion over the prior three years, stock was at a 17-year low, and the board's then-consensus plan was to **break up the company** into autonomous business units — selling some, spinning others off. The breakup plan had been formally proposed by an internal task force, supported by external consultants (including parts of McKinsey), and was the public expectation when Gerstner arrived.\n\nGerstner, in his first 90 days, made what he later called \"the most important decision of my career\": he stopped to ask whether the breakup decomposition was *MECE*. The board's analysis had decomposed IBM by **product line** (mainframes, PCs, software, services, etc.), concluding that each line could function as a standalone business. Gerstner asked a different question, with a different decomposition:\n\n> \"Sometimes the most important consulting work is teaching people to ask different questions. The fundamental issue was not 'should we break the company up?' but 'what does the customer want?'. When I asked our biggest customers, none of them wanted to deal with five smaller IBMs. They wanted exactly the opposite — they wanted an *integrated solutions provider* who could handle the whole stack.\"\n> — Lou Gerstner, *Who Says Elephants Can't Dance?* (HarperBusiness, 2002), ch. 8.\n\nWalk the MECE Decomposition on the IBM 1993 decision:\n\n- **The whole (Step 1):** *\"How should IBM be structured to maximize long-term shareholder value, given the 1993 market position?\"*\n- **The board's decomposition (alternative considered):** By product line — Mainframes / PCs / Software / Services / Storage. **MECE on product**, but missing the question of how customers actually buy.\n- **Gerstner's proposed top-level split (Step 2):** **By how customers buy** — Customers who want point products (single hardware or software item) / Customers who want integrated multi-vendor solutions / Customers who want a single full-stack provider managed under one contract.\n- **ME test (Step 3):** Each customer at a given time buys in *one* of these three modes. Mutually exclusive ✓.\n- **CE test (Step 4):** Are there other modes? Customers who want pure consulting without products? Yes — add a fourth branch \"Pure advisory.\" Sum of the four branches covers all enterprise IT customers in 1993. Exhaustive ✓.\n- **Load-bearing branch (Step 6):** Mode 3 (single full-stack provider) was the segment that **only IBM could serve** — competitors (Microsoft, Sun, Oracle) were strong in single product categories but had no integrated full-stack offering. **This segment was growing and most profitable.**\n- **Action implied (Step 7):** *Do not break up.* Reorient IBM around integrated solutions for Mode 3 customers. Specifically: invest in the IBM Global Services business; consolidate the company's go-to-market under solution-oriented sales; price by full-stack solution rather than by component.\n- **Alternatives considered:** Product-line decomposition (board's plan) was MECE on a *different* dimension but missed the customer-buying-mode dimension that turned out to be load-bearing.\n\nThe result, documented in IBM's SEC filings and Gerstner's memoir: from 1993 to 2002, IBM's market capitalization grew from approximately $30 billion to over $180 billion, and Global Services (the integrated-solutions business unit Gerstner created) grew from ~$7B to ~$35B in annual revenue. **The framework's payoff was not \"stop the breakup\"; it was that the *original decomposition* was MECE on the wrong dimension** — and finding the right dimension changed which strategy looked correct.\n\nThe lesson the framework names: **a MECE decomposition is only as good as the dimension chosen**. Most strategic disagreements are not disagreements about facts within a shared decomposition; they are disagreements about *which decomposition to use*. Surfacing the alternative decomposition is what changes the conversation.\n\nFile v1.0.2:skill-card.md\n\n## Description:
\nGuides an agent to decompose messy or high-stakes problems into mutually exclusive, collectively exhaustive branches, test for overlap and gaps, and identify the load-bearing branch.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[deciqai](https://clawhub.ai/user/deciqai)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nEmployees, external users, and agents use this skill to structure broad business, strategy, operational, or analytical questions into non-overlapping, complete issue trees. It is most useful when a problem is too large to reason about cleanly, options overlap, or a presentation needs a defensible structure.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill may encourage formal decomposition when brainstorming, creative exploration, or simple decisions do not need that structure.
\nMitigation: Use the skill's fit checks and redirect when the task is trivial, creative, or not meaningfully decomposable.
\nRisk: A plausible issue tree can still hide overlapping branches, missing cases, or the wrong top-level dimension.
\nMitigation: Review the mutual exclusivity, collective exhaustiveness, sum-to-whole, and alternative-dimension checks before relying on the output.
\n\n\n## Reference(s):
\n- [Sources - mece](references/sources.md)
\n- [Lou Gerstner's IBM Turnaround Decomposition (1993)](examples/lou-gerstner-ibm-turnaround-decomposition-1993.md)
\n- [IBM Investor Relations](https://www.ibm.com/investor/)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, guidance]
\n**Output Format:** [Markdown decomposition template with structured analysis sections]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [May ask step-by-step clarification questions before producing the final decomposition.]
\n\n## Skill Version(s):
\n1.0.2 (source: evidence.release.version)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.1: 5 files, 8731 bytes\n\nFiles: examples/lou-gerstner-ibm-turnaround-decomposition-1993.md (4324b), references/sources.md (971b), skill-card.md (2350b), SKILL.md (9057b), _meta.json (123b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: mece\ndescription: \"Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-counting', a problem feels too big to think about cleanly, a list of options is messy or overlapping, an analysis keeps going in circles, or a presentation needs to survive hard scrutiny.\n Do NOT activate when: the problem is trivially small (lunch decisions), or the user is in purely creative/generative mode where premature structure would constrain exploration.\"\n---\n\n# MECE (Mutually Exclusive, Collectively Exhaustive)\n\n## Overview\n\n**MECE** is a decomposition principle: break a problem, set of options, or population into sub-groups that are **Mutually Exclusive** (no overlap) and **Collectively Exhaustive** (no gaps) — every relevant item covered exactly once. Operationalized by **Barbara Minto** at McKinsey (1963–1973) in *The Pyramid Principle* (1973; 3rd ed. 2002). The test: sum the pieces back to the whole; if they don't sum cleanly, the decomposition is broken.\n\n**Compose:** use [first-principles](../first-principles/SKILL.md) to reach root variables; [pareto-principle](../pareto-principle/SKILL.md) to find load-bearing branches; [critical-thinking](../critical-thinking/SKILL.md) to test whether categories are the *right* ones; [occams-razor](../occams-razor/SKILL.md) when multiple MECE structures fit — pick the simplest.\n\n## When to Use\n\n- Problem feels **too big to think about cleanly** — surface area is unclear\n- **List of options** is messy or overlapping — competing answers that aren't parallel\n- Analysis is **going in circles** — same issues reappear because they're not separated\n- **Presentation** must convince hard-to-convince listeners\n- Team converging on a hypothesis **without considering the full space** of alternatives\n- Someone says: *\"MECE,\" \"decompose this,\" \"issue tree,\" \"structure this thinking\"*\n\n**When NOT to use:** trivially small problem; purely creative/generative mode; genuinely non-decomposable question (some ethical/aesthetic problems resist this); decomposition already known and well-trodden.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete case → run The Process directly.\n- **Coach mode:** user is unfamiliar or has no concrete case → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: MECE is **breaking a problem into pieces that don't overlap AND don't leave gaps** — every relevant thing is covered exactly once. The check: do the pieces sum back to the whole?\n2. Check fit against When to Use / When NOT to use. Trivial problem → redirect. Creative exploration → not yet.\n3. Elicit their specific problem to decompose. *\"My business has problems\"* is too vague; need a concrete question — *\"why is our gross margin declining?\"*, *\"what are the options for resolving this escalation?\"* > **[WAIT — do not advance until user responds]**\n4. Walk through Level 1 of the decomposition one step at a time, check ME and CE, then Level 2 if needed. > **[WAIT — do not advance until user responds]**\n5. Close by naming the load-bearing branch — they leave knowing where to focus, confident nothing important is missing. > **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **MECE Decomposition**: define the whole → propose top split → check ME AND CE → iterate → identify load-bearing branch.\n\n1. **State the whole precisely.** \"Our business\" is not the whole; \"*revenue this fiscal year by customer segment*\" is.\n2. **Propose a top-level split (2–7 categories).** Common dimensions: customer segment, geography, product line, time period, formula component (revenue = price × volume), life-cycle stage, cause type.\n3. **Test Mutual Exclusivity.** For each pair: is there any case that belongs to both? If yes, refine until no item can belong to more than one branch.\n4. **Test Collective Exhaustiveness.** What case is *not* covered? Add an explicit \"other\" or \"future\" branch if needed.\n4a. **Sum-to-whole test.** Do the branches add up to the whole? If not, identify what's missing or double-counted.\n5. **Recurse if needed.** Apply MECE to each branch. Stop when each leaf is actionable.\n6. **Identify the load-bearing branch.** Per [pareto-principle](../pareto-principle/SKILL.md), one or two branches carry disproportionate weight.\n7. **Document the structure.** The issue tree / Minto pyramid diagram is the standard shareable artifact.\n\n### Output: the MECE Decomposition\n\n```markdown\n# MECE Decomposition: \n## The whole: \n## Top-level split (Level 1): Branch A / Branch B / Branch C / (Other if needed)\n## ME test: A ∩ B = ? / A ∩ C = ? (refine until empty)\n## CE test: What is missing? / Sum = whole? (yes/no + what's added)\n## Sub-decomposition (Level 2, only if needed): A → A1 / A2 ...\n## Load-bearing branch: \n## Action implied: \n## Alternative decompositions considered: \n```\n\n*→ Method in Action: [Lou Gerstner's IBM Turnaround Decomposition (1993)](examples/lou-gerstner-ibm-turnaround-decomposition-1993.md)*\n\n## Decomposition Packs\n\nCanonical MECE dimensions by domain: **Profit/margin** — Revenue = Price × Volume; Cost = Fixed + Variable. **Customer segmentation** — industry / size / use case / buying mode. **Strategy options** — axis of competition; build/buy/partner; time horizon. **Failure-mode** (see [inversion](../inversion/SKILL.md)) — technical / human / process / environmental.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n\n## Applying It Well\n\n- **MECE is the test, not the brainstorm.** Propose first; then check ME AND CE. Most people skip the check.\n- **The dimension matters more than the depth.** Wrong Level 1 dimension makes Level 2 useless. Try 2–3 before committing.\n- **Sum back to the whole.** If branches don't sum, the decomposition is broken.\n- **\"Other\" is sometimes the right branch.** Forcing named categories creates fake exhaustiveness.\n- **Stop when the leaf is actionable.** Decomposing past action is paralysis.\n\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] **Claiming MECE without testing** | \"These are the three options\" is not MECE until tested. Run the overlap check AND the gap check. |\n| [D] **Overlapping categories** (\"Big customers / Important customers\") | These overlap. Refine — perhaps by quantitative threshold — until disjoint. |\n| [D] **Missing the residual** | Geography split into \"North America / Europe / Asia\" misses Latin America, Africa, Oceania. Add \"Other\" explicitly. |\n| [D] **Wrong dimension chosen** | Product-line decomposition was MECE but missed the customer-buying-mode dimension that mattered. Try alternatives. |\n| [D] **Decomposing trivial problems** | Lunch decisions don't need MECE. Reserve it for problems with large surface area. |\n| [D] **Going too deep** | Decomposing past actionable leaves produces complexity without insight. |\n| [D] **Fake \"Other\" branches** | An \"Other\" capturing > 30% of the whole means the dimension is wrong. Rethink the split. |\n| [D] **Not summing back to the whole** | The most reliable MECE test is arithmetic. Skipping it lets broken decompositions look fine. |\n| [D] **Treating MECE as the analysis** | MECE produces *the structure*; analysis happens *within* the structure. A MECE diagram with no investigation is wall art. |\n| [D] **Single decomposition without alternatives** | Most analytical disagreements are about *which* decomposition. Consider 2–3 dimensions before committing. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- \"These are MECE\" stated without overlap and gap tests\n- An \"Other\" category capturing > 30% of the whole\n- Categories that share obvious cases (e.g., \"Big customers\" and \"Important customers\")\n- The decomposition was inherited / copied without checking\n- The branches don't sum to the original whole\n- Only one decomposition dimension was considered\n- The decomposition goes 5+ levels deep without action at the leaves\n\n## Verification\n\n- [ ] Whole stated precisely and measurable; top-level dimension named and justified\n- [ ] ME explicitly checked between every pair; CE checked (missing-case test)\n- [ ] Branches sum back to the whole (arithmetic test)\n- [ ] Each leaf is *actionable*; at least one alternative dimension was considered\n- [ ] Load-bearing branch identified\n\n---\n\n*Part of **deciqAI Knowledge Skills** — open-source thinking skills that make rigor executable for AI agents. Built by deciqAI · https://deciqai.com · Contributions welcome — see the template at the repo root.*\n\nFile v1.0.1:_meta.json\n\n{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"mece\",\n \"version\": \"1.0.1\",\n \"publishedAt\": 1783463330588\n}\n\nFile v1.0.1:references/sources.md\n\n# Sources — mece\n\n> *Primary sources for the [mece](../SKILL.md) skill.*\n\n- **Minto, Barbara.** *The Pyramid Principle: Logic in Writing, Thinking and Problem Solving*. Pearson Prentice Hall, 1973; 3rd ed. 2002. **Primary source for MECE and pyramid-structured analysis**.\n- **Rasiel, Ethan M.** *The McKinsey Way: Using the Techniques of the World's Top Strategic Consultants to Help You and Your Business*. McGraw-Hill, 1999. **Documentation of McKinsey's internal use of MECE**.\n- **Gerstner, Louis V., Jr.** *Who Says Elephants Can't Dance? Inside IBM's Historic Turnaround*. HarperBusiness, 2002. **Primary source for the IBM 1993 turnaround decision case**.\n- **IBM Corporation,** Annual Reports and SEC 10-K filings, 1993–2002. **Primary-source empirical outcome data**: https://www.ibm.com/investor/\n- The popular phrase \"no overlap, no gap\" is the **operational summary** — accurate, but the rigor is in the *test* (sum back to the whole), not the slogan.\n\nFile v1.0.1:examples/lou-gerstner-ibm-turnaround-decomposition-1993.md\n\n# Method in Action: Lou Gerstner's IBM Turnaround Decomposition (1993)\n\n> *Example for the [mece](../SKILL.md) skill.*\n\nA worked example. Not management folklore — primary-source documented in Lou Gerstner's own account *Who Says Elephants Can't Dance?* (HarperBusiness, 2002).\n\nIn **April 1993**, **Louis V. Gerstner Jr.** took over as CEO of **IBM**, then in the worst crisis in its history. IBM had lost $16 billion over the prior three years, stock was at a 17-year low, and the board's then-consensus plan was to **break up the company** into autonomous business units — selling some, spinning others off. The breakup plan had been formally proposed by an internal task force, supported by external consultants (including parts of McKinsey), and was the public expectation when Gerstner arrived.\n\nGerstner, in his first 90 days, made what he later called \"the most important decision of my career\": he stopped to ask whether the breakup decomposition was *MECE*. The board's analysis had decomposed IBM by **product line** (mainframes, PCs, software, services, etc.), concluding that each line could function as a standalone business. Gerstner asked a different question, with a different decomposition:\n\n> \"Sometimes the most important consulting work is teaching people to ask different questions. The fundamental issue was not 'should we break the company up?' but 'what does the customer want?'. When I asked our biggest customers, none of them wanted to deal with five smaller IBMs. They wanted exactly the opposite — they wanted an *integrated solutions provider* who could handle the whole stack.\"\n> — Lou Gerstner, *Who Says Elephants Can't Dance?* (HarperBusiness, 2002), ch. 8.\n\nWalk the MECE Decomposition on the IBM 1993 decision:\n\n- **The whole (Step 1):** *\"How should IBM be structured to maximize long-term shareholder value, given the 1993 market position?\"*\n- **The board's decomposition (alternative considered):** By product line — Mainframes / PCs / Software / Services / Storage. **MECE on product**, but missing the question of how customers actually buy.\n- **Gerstner's proposed top-level split (Step 2):** **By how customers buy** — Customers who want point products (single hardware or software item) / Customers who want integrated multi-vendor solutions / Customers who want a single full-stack provider managed under one contract.\n- **ME test (Step 3):** Each customer at a given time buys in *one* of these three modes. Mutually exclusive ✓.\n- **CE test (Step 4):** Are there other modes? Customers who want pure consulting without products? Yes — add a fourth branch \"Pure advisory.\" Sum of the four branches covers all enterprise IT customers in 1993. Exhaustive ✓.\n- **Load-bearing branch (Step 6):** Mode 3 (single full-stack provider) was the segment that **only IBM could serve** — competitors (Microsoft, Sun, Oracle) were strong in single product categories but had no integrated full-stack offering. **This segment was growing and most profitable.**\n- **Action implied (Step 7):** *Do not break up.* Reorient IBM around integrated solutions for Mode 3 customers. Specifically: invest in the IBM Global Services business; consolidate the company's go-to-market under solution-oriented sales; price by full-stack solution rather than by component.\n- **Alternatives considered:** Product-line decomposition (board's plan) was MECE on a *different* dimension but missed the customer-buying-mode dimension that turned out to be load-bearing.\n\nThe result, documented in IBM's SEC filings and Gerstner's memoir: from 1993 to 2002, IBM's market capitalization grew from approximately $30 billion to over $180 billion, and Global Services (the integrated-solutions business unit Gerstner created) grew from ~$7B to ~$35B in annual revenue. **The framework's payoff was not \"stop the breakup\"; it was that the *original decomposition* was MECE on the wrong dimension** — and finding the right dimension changed which strategy looked correct.\n\nThe lesson the framework names: **a MECE decomposition is only as good as the dimension chosen**. Most strategic disagreements are not disagreements about facts within a shared decomposition; they are disagreements about *which decomposition to use*. Surfacing the alternative decomposition is what changes the conversation.\n\nFile v1.0.1:skill-card.md\n\n## Description:
\nGuides an agent to decompose complex problems into mutually exclusive and collectively exhaustive issue trees, test for overlap and gaps, and identify load-bearing branches.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[deciqai](https://clawhub.ai/user/deciqai)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nEmployees, external users, and developers use this skill when a problem is too large, overlapping, or circular to reason about cleanly. It helps structure the full option space, check that categories do not overlap or leave gaps, and turn the resulting issue tree into a focused next action.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill may activate more often than users expect in general strategy or planning conversations.
\nMitigation: Disable the skill or narrow its activation when users prefer less structured or less framework-driven responses.
\nRisk: MECE structure can prematurely constrain trivial, creative, aesthetic, or genuinely non-decomposable questions.
\nMitigation: Apply the documented fit check first and redirect when the task is too small, exploratory, or poorly suited to decomposition.
\n\n\n## Reference(s):
\n- [Sources - mece](references/sources.md)
\n- [Lou Gerstner's IBM Turnaround Decomposition (1993)](examples/lou-gerstner-ibm-turnaround-decomposition-1993.md)
\n- [IBM Investor Relations](https://www.ibm.com/investor/)
\n\n\n## Skill Output:
\n**Output Type(s):** [Text, Markdown, Guidance]
\n**Output Format:** [Markdown issue-tree decomposition with checks and action recommendations]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Produces a bounded whole, top-level split, mutual-exclusivity test, collective-exhaustiveness test, optional sub-decomposition, load-bearing branch, action implied, and alternative decompositions considered.]
\n\n## Skill Version(s):
\n1.0.1 (source: server release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.0: 5 files, 8721 bytes\n\nFiles: examples/lou-gerstner-ibm-turnaround-decomposition-1993.md (4324b), references/sources.md (971b), skill-card.md (2444b), SKILL.md (9057b), _meta.json (123b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: mece\ndescription: \"Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-counting', a problem feels too big to think about cleanly, a list of options is messy or overlapping, an analysis keeps going in circles, or a presentation needs to survive hard scrutiny.\n Do NOT activate when: the problem is trivially small (lunch decisions), or the user is in purely creative/generative mode where premature structure would constrain exploration.\"\n---\n\n# MECE (Mutually Exclusive, Collectively Exhaustive)\n\n## Overview\n\n**MECE** is a decomposition principle: break a problem, set of options, or population into sub-groups that are **Mutually Exclusive** (no overlap) and **Collectively Exhaustive** (no gaps) — every relevant item covered exactly once. Operationalized by **Barbara Minto** at McKinsey (1963–1973) in *The Pyramid Principle* (1973; 3rd ed. 2002). The test: sum the pieces back to the whole; if they don't sum cleanly, the decomposition is broken.\n\n**Compose:** use [first-principles](../first-principles/SKILL.md) to reach root variables; [pareto-principle](../pareto-principle/SKILL.md) to find load-bearing branches; [critical-thinking](../critical-thinking/SKILL.md) to test whether categories are the *right* ones; [occams-razor](../occams-razor/SKILL.md) when multiple MECE structures fit — pick the simplest.\n\n## When to Use\n\n- Problem feels **too big to think about cleanly** — surface area is unclear\n- **List of options** is messy or overlapping — competing answers that aren't parallel\n- Analysis is **going in circles** — same issues reappear because they're not separated\n- **Presentation** must convince hard-to-convince listeners\n- Team converging on a hypothesis **without considering the full space** of alternatives\n- Someone says: *\"MECE,\" \"decompose this,\" \"issue tree,\" \"structure this thinking\"*\n\n**When NOT to use:** trivially small problem; purely creative/generative mode; genuinely non-decomposable question (some ethical/aesthetic problems resist this); decomposition already known and well-trodden.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete case → run The Process directly.\n- **Coach mode:** user is unfamiliar or has no concrete case → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: MECE is **breaking a problem into pieces that don't overlap AND don't leave gaps** — every relevant thing is covered exactly once. The check: do the pieces sum back to the whole?\n2. Check fit against When to Use / When NOT to use. Trivial problem → redirect. Creative exploration → not yet.\n3. Elicit their specific problem to decompose. *\"My business has problems\"* is too vague; need a concrete question — *\"why is our gross margin declining?\"*, *\"what are the options for resolving this escalation?\"* > **[WAIT — do not advance until user responds]**\n4. Walk through Level 1 of the decomposition one step at a time, check ME and CE, then Level 2 if needed. > **[WAIT — do not advance until user responds]**\n5. Close by naming the load-bearing branch — they leave knowing where to focus, confident nothing important is missing. > **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **MECE Decomposition**: define the whole → propose top split → check ME AND CE → iterate → identify load-bearing branch.\n\n1. **State the whole precisely.** \"Our business\" is not the whole; \"*revenue this fiscal year by customer segment*\" is.\n2. **Propose a top-level split (2–7 categories).** Common dimensions: customer segment, geography, product line, time period, formula component (revenue = price × volume), life-cycle stage, cause type.\n3. **Test Mutual Exclusivity.** For each pair: is there any case that belongs to both? If yes, refine until no item can belong to more than one branch.\n4. **Test Collective Exhaustiveness.** What case is *not* covered? Add an explicit \"other\" or \"future\" branch if needed.\n4a. **Sum-to-whole test.** Do the branches add up to the whole? If not, identify what's missing or double-counted.\n5. **Recurse if needed.** Apply MECE to each branch. Stop when each leaf is actionable.\n6. **Identify the load-bearing branch.** Per [pareto-principle](../pareto-principle/SKILL.md), one or two branches carry disproportionate weight.\n7. **Document the structure.** The issue tree / Minto pyramid diagram is the standard shareable artifact.\n\n### Output: the MECE Decomposition\n\n```markdown\n# MECE Decomposition: \n## The whole: \n## Top-level split (Level 1): Branch A / Branch B / Branch C / (Other if needed)\n## ME test: A ∩ B = ? / A ∩ C = ? (refine until empty)\n## CE test: What is missing? / Sum = whole? (yes/no + what's added)\n## Sub-decomposition (Level 2, only if needed): A → A1 / A2 ...\n## Load-bearing branch: \n## Action implied: \n## Alternative decompositions considered: \n```\n\n*→ Method in Action: [Lou Gerstner's IBM Turnaround Decomposition (1993)](examples/lou-gerstner-ibm-turnaround-decomposition-1993.md)*\n\n## Decomposition Packs\n\nCanonical MECE dimensions by domain: **Profit/margin** — Revenue = Price × Volume; Cost = Fixed + Variable. **Customer segmentation** — industry / size / use case / buying mode. **Strategy options** — axis of competition; build/buy/partner; time horizon. **Failure-mode** (see [inversion](../inversion/SKILL.md)) — technical / human / process / environmental.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n\n## Applying It Well\n\n- **MECE is the test, not the brainstorm.** Propose first; then check ME AND CE. Most people skip the check.\n- **The dimension matters more than the depth.** Wrong Level 1 dimension makes Level 2 useless. Try 2–3 before committing.\n- **Sum back to the whole.** If branches don't sum, the decomposition is broken.\n- **\"Other\" is sometimes the right branch.** Forcing named categories creates fake exhaustiveness.\n- **Stop when the leaf is actionable.** Decomposing past action is paralysis.\n\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] **Claiming MECE without testing** | \"These are the three options\" is not MECE until tested. Run the overlap check AND the gap check. |\n| [D] **Overlapping categories** (\"Big customers / Important customers\") | These overlap. Refine — perhaps by quantitative threshold — until disjoint. |\n| [D] **Missing the residual** | Geography split into \"North America / Europe / Asia\" misses Latin America, Africa, Oceania. Add \"Other\" explicitly. |\n| [D] **Wrong dimension chosen** | Product-line decomposition was MECE but missed the customer-buying-mode dimension that mattered. Try alternatives. |\n| [D] **Decomposing trivial problems** | Lunch decisions don't need MECE. Reserve it for problems with large surface area. |\n| [D] **Going too deep** | Decomposing past actionable leaves produces complexity without insight. |\n| [D] **Fake \"Other\" branches** | An \"Other\" capturing > 30% of the whole means the dimension is wrong. Rethink the split. |\n| [D] **Not summing back to the whole** | The most reliable MECE test is arithmetic. Skipping it lets broken decompositions look fine. |\n| [D] **Treating MECE as the analysis** | MECE produces *the structure*; analysis happens *within* the structure. A MECE diagram with no investigation is wall art. |\n| [D] **Single decomposition without alternatives** | Most analytical disagreements are about *which* decomposition. Consider 2–3 dimensions before committing. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- \"These are MECE\" stated without overlap and gap tests\n- An \"Other\" category capturing > 30% of the whole\n- Categories that share obvious cases (e.g., \"Big customers\" and \"Important customers\")\n- The decomposition was inherited / copied without checking\n- The branches don't sum to the original whole\n- Only one decomposition dimension was considered\n- The decomposition goes 5+ levels deep without action at the leaves\n\n## Verification\n\n- [ ] Whole stated precisely and measurable; top-level dimension named and justified\n- [ ] ME explicitly checked between every pair; CE checked (missing-case test)\n- [ ] Branches sum back to the whole (arithmetic test)\n- [ ] Each leaf is *actionable*; at least one alternative dimension was considered\n- [ ] Load-bearing branch identified\n\n---\n\n*Part of **deciqAI Knowledge Skills** — open-source thinking skills that make rigor executable for AI agents. Built by deciqAI · https://deciqai.com · Contributions welcome — see the template at the repo root.*\n\nFile v1.0.0:_meta.json\n\n{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"mece\",\n \"version\": \"1.0.0\",\n \"publishedAt\": 1782800306715\n}\n\nFile v1.0.0:references/sources.md\n\n# Sources — mece\n\n> *Primary sources for the [mece](../SKILL.md) skill.*\n\n- **Minto, Barbara.** *The Pyramid Principle: Logic in Writing, Thinking and Problem Solving*. Pearson Prentice Hall, 1973; 3rd ed. 2002. **Primary source for MECE and pyramid-structured analysis**.\n- **Rasiel, Ethan M.** *The McKinsey Way: Using the Techniques of the World's Top Strategic Consultants to Help You and Your Business*. McGraw-Hill, 1999. **Documentation of McKinsey's internal use of MECE**.\n- **Gerstner, Louis V., Jr.** *Who Says Elephants Can't Dance? Inside IBM's Historic Turnaround*. HarperBusiness, 2002. **Primary source for the IBM 1993 turnaround decision case**.\n- **IBM Corporation,** Annual Reports and SEC 10-K filings, 1993–2002. **Primary-source empirical outcome data**: https://www.ibm.com/investor/\n- The popular phrase \"no overlap, no gap\" is the **operational summary** — accurate, but the rigor is in the *test* (sum back to the whole), not the slogan.\n\nFile v1.0.0:examples/lou-gerstner-ibm-turnaround-decomposition-1993.md\n\n# Method in Action: Lou Gerstner's IBM Turnaround Decomposition (1993)\n\n> *Example for the [mece](../SKILL.md) skill.*\n\nA worked example. Not management folklore — primary-source documented in Lou Gerstner's own account *Who Says Elephants Can't Dance?* (HarperBusiness, 2002).\n\nIn **April 1993**, **Louis V. Gerstner Jr.** took over as CEO of **IBM**, then in the worst crisis in its history. IBM had lost $16 billion over the prior three years, stock was at a 17-year low, and the board's then-consensus plan was to **break up the company** into autonomous business units — selling some, spinning others off. The breakup plan had been formally proposed by an internal task force, supported by external consultants (including parts of McKinsey), and was the public expectation when Gerstner arrived.\n\nGerstner, in his first 90 days, made what he later called \"the most important decision of my career\": he stopped to ask whether the breakup decomposition was *MECE*. The board's analysis had decomposed IBM by **product line** (mainframes, PCs, software, services, etc.), concluding that each line could function as a standalone business. Gerstner asked a different question, with a different decomposition:\n\n> \"Sometimes the most important consulting work is teaching people to ask different questions. The fundamental issue was not 'should we break the company up?' but 'what does the customer want?'. When I asked our biggest customers, none of them wanted to deal with five smaller IBMs. They wanted exactly the opposite — they wanted an *integrated solutions provider* who could handle the whole stack.\"\n> — Lou Gerstner, *Who Says Elephants Can't Dance?* (HarperBusiness, 2002), ch. 8.\n\nWalk the MECE Decomposition on the IBM 1993 decision:\n\n- **The whole (Step 1):** *\"How should IBM be structured to maximize long-term shareholder value, given the 1993 market position?\"*\n- **The board's decomposition (alternative considered):** By product line — Mainframes / PCs / Software / Services / Storage. **MECE on product**, but missing the question of how customers actually buy.\n- **Gerstner's proposed top-level split (Step 2):** **By how customers buy** — Customers who want point products (single hardware or software item) / Customers who want integrated multi-vendor solutions / Customers who want a single full-stack provider managed under one contract.\n- **ME test (Step 3):** Each customer at a given time buys in *one* of these three modes. Mutually exclusive ✓.\n- **CE test (Step 4):** Are there other modes? Customers who want pure consulting without products? Yes — add a fourth branch \"Pure advisory.\" Sum of the four branches covers all enterprise IT customers in 1993. Exhaustive ✓.\n- **Load-bearing branch (Step 6):** Mode 3 (single full-stack provider) was the segment that **only IBM could serve** — competitors (Microsoft, Sun, Oracle) were strong in single product categories but had no integrated full-stack offering. **This segment was growing and most profitable.**\n- **Action implied (Step 7):** *Do not break up.* Reorient IBM around integrated solutions for Mode 3 customers. Specifically: invest in the IBM Global Services business; consolidate the company's go-to-market under solution-oriented sales; price by full-stack solution rather than by component.\n- **Alternatives considered:** Product-line decomposition (board's plan) was MECE on a *different* dimension but missed the customer-buying-mode dimension that turned out to be load-bearing.\n\nThe result, documented in IBM's SEC filings and Gerstner's memoir: from 1993 to 2002, IBM's market capitalization grew from approximately $30 billion to over $180 billion, and Global Services (the integrated-solutions business unit Gerstner created) grew from ~$7B to ~$35B in annual revenue. **The framework's payoff was not \"stop the breakup\"; it was that the *original decomposition* was MECE on the wrong dimension** — and finding the right dimension changed which strategy looked correct.\n\nThe lesson the framework names: **a MECE decomposition is only as good as the dimension chosen**. Most strategic disagreements are not disagreements about facts within a shared decomposition; they are disagreements about *which decomposition to use*. Surfacing the alternative decomposition is what changes the conversation.\n\nFile v1.0.0:skill-card.md\n\n## Description:
\nGuides an agent to decompose broad or overlapping problems into mutually exclusive, collectively exhaustive issue trees, test for gaps and overlap, and identify the load-bearing branch.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[deciqai](https://clawhub.ai/user/deciqai)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nExternal users and developers use this skill to structure complex business, strategy, or analytical questions into a MECE decomposition. It helps turn broad or messy problem spaces into testable branches, identify missing or overlapping categories, and produce a concise issue-tree-style markdown artifact.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill may activate for broad problem-solving or presentation-prep requests when the user prefers less structured brainstorming.
\nMitigation: Invoke it explicitly for structured decomposition, or ask the agent to stay exploratory when early structure would constrain ideation.
\nRisk: A decomposition can look rigorous while still using overlapping categories, missing residual cases, or choosing the wrong top-level dimension.
\nMitigation: Review the overlap check, gap check, sum-to-whole test, and alternative decompositions before relying on the output.
\n\n\n## Reference(s):
\n- [Sources - mece](references/sources.md)
\n- [Lou Gerstner's IBM Turnaround Decomposition (1993)](examples/lou-gerstner-ibm-turnaround-decomposition-1993.md)
\n- [IBM Investor Relations](https://www.ibm.com/investor/)
\n- [ClawHub listing](https://clawhub.ai/deciqai/skills/mece)
\n\n\n## Skill Output:
\n**Output Type(s):** [Guidance, Analysis, Markdown]
\n**Output Format:** [Markdown]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Produces a structured MECE decomposition with the whole problem, top-level split, ME and CE tests, optional sub-decomposition, load-bearing branch, implied action, and alternatives considered.]
\n\n## Skill Version(s):
\n1.0.0 (source: server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
","readmeExcerpt":"Skill: MECE (Mutually Exclusive, Collectively Exhaustive) Owner: deciqai Summary: Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-co... Tags: latest:1.0.5 Version history: v1.0.5 | 2026-07-16T18:06:02.579Z | user Description tail link + agents machine-readable metadata line (deciqai.com/s/mece.json) v1.0.4 | 202","codeSnippets":[],"executableExamples":[{"language":"markdown","snippet":"# MECE Decomposition: \n## The whole: \n## Top-level split (Level 1): Branch A / Branch B / Branch C / (Other if needed)\n## ME test: A ∩ B = ? / A ∩ C = ? (refine until empty)\n## CE test: What is missing? / Sum = whole? (yes/no + what's added)\n## Sub-decomposition (Level 2, only if needed): A → A1 / A2 ...\n## Load-bearing branch: \n## Action implied: \n## Alternative decompositions considered: "},{"language":"markdown","snippet":"# MECE Decomposition: \n## The whole: \n## Top-level split (Level 1): Branch A / Branch B / Branch C / (Other if needed)\n## ME test: A ∩ B = ? / A ∩ C = ? (refine until empty)\n## CE test: What is missing? / Sum = whole? (yes/no + what's added)\n## Sub-decomposition (Level 2, only if needed): A → A1 / A2 ...\n## Load-bearing branch: \n## Action implied: \n## Alternative decompositions considered: "},{"language":"markdown","snippet":"# MECE Decomposition: \n## The whole: \n## Top-level split (Level 1): Branch A / Branch B / Branch C / (Other if needed)\n## ME test: A ∩ B = ? / A ∩ C = ? (refine until empty)\n## CE test: What is missing? / Sum = whole? (yes/no + what's added)\n## Sub-decomposition (Level 2, only if needed): A → A1 / A2 ...\n## Load-bearing branch: \n## Action implied: \n## Alternative decompositions considered: "},{"language":"markdown","snippet":"# MECE Decomposition: \n## The whole: \n## Top-level split (Level 1): Branch A / Branch B / Branch C / (Other if needed)\n## ME test: A ∩ B = ? / A ∩ C = ? (refine until empty)\n## CE test: What is missing? / Sum = whole? (yes/no + what's added)\n## Sub-decomposition (Level 2, only if needed): A → A1 / A2 ...\n## Load-bearing branch: \n## Action implied: \n## Alternative decompositions considered: "},{"language":"markdown","snippet":"# MECE Decomposition: \n## The whole: \n## Top-level split (Level 1): Branch A / Branch B / Branch C / (Other if needed)\n## ME test: A ∩ B = ? / A ∩ C = ? (refine until empty)\n## CE test: What is missing? / Sum = whole? (yes/no + what's added)\n## Sub-decomposition (Level 2, only if needed): A → A1 / A2 ...\n## Load-bearing branch: \n## Action implied: \n## Alternative decompositions considered: "},{"language":"markdown","snippet":"# MECE Decomposition: \n## The whole: \n## Top-level split (Level 1): Branch A / Branch B / Branch C / (Other if needed)\n## ME test: A ∩ B = ? / A ∩ C = ? (refine until empty)\n## CE test: What is missing? / Sum = whole? (yes/no + what's added)\n## Sub-decomposition (Level 2, only if needed): A → A1 / A2 ...\n## Load-bearing branch: \n## Action implied: \n## Alternative decompositions considered: "}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: mece\ndescription: \"Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-counting', a problem feels too big to think about cleanly, a list of options is messy or overlapping, an analysis keeps going in circles, or a presentation needs to survive hard scrutiny.\n Do NOT activate when: the problem is trivially small (lunch decisions), or the user is in purely creative/generative mode where premature structure would constrain exploration. More: deciqai.com/c/mece\"\n---\n\n# MECE (Mutually Exclusive, Collectively Exhaustive)\n\n## Overview\n\n**MECE** is a decomposition principle: break a problem, set of options, or population into sub-groups that are **Mutually Exclusive** (no overlap) and **Collectively Exhaustive** (no gaps) — every relevant item covered exactly once. Operationalized by **Barbara Minto** at McKinsey (1963–1973) in *The Pyramid Principle* (1973; 3rd ed. 2002). The test: sum the pieces back to the whole; if they don't sum cleanly, the decomposition is broken.\n\n**Compose:** use first-principles to reach root variables; pareto-principle to find load-bearing branches; critical-thinking to test whether categories are the *right* ones; occams-razor when multiple MECE structures fit — pick the simplest.\n\n## When to Use\n\n- Problem feels **too big to think about cleanly** — surface area is unclear\n- **List of options** is messy or overlapping — competing answers that aren't parallel\n- Analysis is **going in circles** — same issues reappear because they're not separated\n- **Presentation** must convince hard-to-convince listeners\n- Team converging on a hypothesis **without considering the full space** of alternatives\n- Structuring an **AI strategy / AI-stack / AI-adoption** discussion so the layers (chips / cloud / models / apps) or use cases have no overlaps and no gaps — cutting through AI hype to a complete, non-redundant map\n- Someone says: *\"MECE,\" \"decompose this,\" \"issue tree,\" \"structure this thinking\"*\n\n**When NOT to use:** trivially small problem; purely creative/generative mode; genuinely non-decomposable question (some ethical/aesthetic problems resist this); decomposition already known and well-trodden.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete case → run The Process directly.\n- **Coach mode:** user is unfamiliar or has no concrete case → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: MECE is **breaking a problem into pieces that don't overlap AND don't leave gaps** — every relevant thing is covered exactly once. The check: do the pieces sum back to the whole?\n2. Check fit against When to Use / When NOT to use. Trivial problem → redirect. Creative exploration → not yet.\n3. Elicit their specific problem to decompose. *\"My business has problems\"* is too vague; need a concrete"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"mece\",\n \"version\": \"1.0.5\",\n \"publishedAt\": 1784225162579\n}"},{"path":"references/sources.md","content":"# Sources — mece\n\n> *Primary sources for the [mece](../SKILL.md) skill.*\n\n- **Minto, Barbara.** *The Pyramid Principle: Logic in Writing, Thinking and Problem Solving*. 1st ed. 1978; 3rd ed., Financial Times Prentice Hall (Pearson), 2002. **Primary source for MECE and pyramid-structured analysis**.\n- **Rasiel, Ethan M.** *The McKinsey Way: Using the Techniques of the World's Top Strategic Consultants to Help You and Your Business*. McGraw-Hill, 1999. **Documentation of McKinsey's internal use of MECE**.\n- **Gerstner, Louis V., Jr.** *Who Says Elephants Can't Dance? Inside IBM's Historic Turnaround*. HarperBusiness, 2002. **Primary source for the IBM 1993 turnaround decision case**.\n- **IBM Corporation,** Annual Reports and SEC 10-K filings, 1993–2002. **Primary-source empirical outcome data**: https://www.ibm.com/investor/\n- The popular phrase \"no overlap, no gap\" is the **operational summary** — accurate, but the rigor is in the *test* (sum back to the whole), not the slogan.\n- **Nvidia Corporation,** quarterly earnings releases and investor materials, FY2024–FY2025: https://investor.nvidia.com/ — **primary-source data on AI data-center GPU demand and the compute layer of the AI stack** (used in the 2024–2026 AI-strategy example).\n- **Microsoft, Amazon (AWS), and Alphabet (Google),** quarterly earnings and capital-expenditure guidance, 2024–2025 (each firm's investor-relations disclosures) — **primary-source documentation of hyperscaler AI-infrastructure build-out**; the chips / cloud / models / applications layering is the widely-used industry taxonomy for the AI value chain as of early 2026."},{"path":"examples/ai-stack-market-strategy-decomposition-2024-2026.md","content":"# Method in Action: Structuring an AI-Stack Market Strategy MECE (2024–2026)\n\n> *Example for the [mece](../SKILL.md) skill.*\n\nA worked example for the AI-hype era. When a leadership team says *\"we need an AI strategy,\"* the conversation usually collapses into a jumble of overlapping buzzwords — foundation models, GPUs, copilots, agents, RAG — that double-count some things and silently omit others. MECE turns that jumble into a structure the strategy discussion can actually close over.\n\nThe observable backdrop (all public and widely reported before early 2026): the generative-AI wave that began with the November 2022 release of OpenAI's ChatGPT accelerated through 2024–2025. Nvidia's data-center GPUs became the scarce input for training frontier models; the major cloud providers (Microsoft Azure, Amazon AWS, Google Cloud) raised capital-expenditure guidance sharply to build AI infrastructure; a small set of labs (OpenAI, Anthropic, Google DeepMind, Meta, Mistral, and others) shipped competing frontier and open-weight models; and an application layer of copilots and \"agents\" proliferated on top. Alongside the build-out ran a persistent hype-vs-adoption debate — how much of the spending would convert into durable enterprise value.\n\nThe strategy question: *where in this stack should we play, and is our current plan covering the whole board or just the loudest layer?* Walk the **MECE Decomposition**.\n\n- **State the whole precisely (Step 1):** Not \"our AI strategy.\" The whole is *\"the full set of value-capture positions in the generative-AI market that our company could occupy or depend on, 2024–2026.\"* Measurable subject: every dollar of AI spend flows through some layer of the stack — we want a partition of those layers.\n\n- **Propose a top-level split (Step 2):** Segment by **layer of the AI stack** — the dimension that matches how value and margin actually flow:\n 1. **Compute / chips** — AI accelerators and the hardware supply chain (Nvidia GPUs, custom silicon like Google TPUs and AWS Trainium, memory, networking).\n 2. **Cloud / infrastructure** — the hosting, orchestration, and MLOps layer that rents that compute (hyperscaler AI platforms, GPU clouds, inference serving).\n 3. **Models / foundation models** — the trained frontier and open-weight models and the labs that produce them.\n 4. **Applications** — the software that end-users touch: copilots, vertical AI apps, and agentic products built on the models.\n\n- **Test Mutual Exclusivity (Step 3):** Check every pair. A GPU (layer 1) is a physical accelerator; a cloud region renting it out (layer 2) is a service contract; the model weights (layer 3) are trained artifacts; the app (layer 4) is the end-user product. A given *dollar of activity* sits in exactly one layer. The genuine trap is vertical integration — Google designs chips **and** runs a cloud **and** trains models **and** ships apps; Microsoft partners on models **and** sells cloud **and** ships Copilot. But MECE partitions the *activit"},{"path":"examples/lou-gerstner-ibm-turnaround-decomposition-1993.md","content":"# Method in Action: Lou Gerstner's IBM Turnaround Decomposition (1993)\n\n> *Example for the [mece](../SKILL.md) skill.*\n\nA worked example. Not management folklore — primary-source documented in Lou Gerstner's own account *Who Says Elephants Can't Dance?* (HarperBusiness, 2002).\n\nIn **April 1993**, **Louis V. Gerstner Jr.** took over as CEO of **IBM**, then in the worst crisis in its history. IBM had lost $16 billion over the prior three years, stock was at a 17-year low, and the board's then-consensus plan was to **break up the company** into autonomous business units — selling some, spinning others off. The breakup plan had been formally proposed by an internal task force, supported by external consultants (including parts of McKinsey), and was the public expectation when Gerstner arrived.\n\nGerstner, in his first 90 days, made what he later called \"the most important decision of my career\": he stopped to ask whether the breakup decomposition was *MECE*. The board's analysis had decomposed IBM by **product line** (mainframes, PCs, software, services, etc.), concluding that each line could function as a standalone business. Gerstner asked a different question, with a different decomposition:\n\n> \"Sometimes the most important consulting work is teaching people to ask different questions. The fundamental issue was not 'should we break the company up?' but 'what does the customer want?'. When I asked our biggest customers, none of them wanted to deal with five smaller IBMs. They wanted exactly the opposite — they wanted an *integrated solutions provider* who could handle the whole stack.\"\n> — Lou Gerstner, *Who Says Elephants Can't Dance?* (HarperBusiness, 2002), ch. 8.\n\nWalk the MECE Decomposition on the IBM 1993 decision:\n\n- **The whole (Step 1):** *\"How should IBM be structured to maximize long-term shareholder value, given the 1993 market position?\"*\n- **The board's decomposition (alternative considered):** By product line — Mainframes / PCs / Software / Services / Storage. **MECE on product**, but missing the question of how customers actually buy.\n- **Gerstner's proposed top-level split (Step 2):** **By how customers buy** — Customers who want point products (single hardware or software item) / Customers who want integrated multi-vendor solutions / Customers who want a single full-stack provider managed under one contract.\n- **ME test (Step 3):** Each customer at a given time buys in *one* of these three modes. Mutually exclusive ✓.\n- **CE test (Step 4):** Are there other modes? Customers who want pure consulting without products? Yes — add a fourth branch \"Pure advisory.\" Sum of the four branches covers all enterprise IT customers in 1993. Exhaustive ✓.\n- **Load-bearing branch (Step 6):** Mode 3 (single full-stack provider) was the segment that **only IBM could serve** — competitors (Microsoft, Sun, Oracle) were strong in single product categories but had no integrated full-stack offering. **This segment was growing and most profitable.**\n- **Ac"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-co... Skill: MECE (Mutually Exclusive, Collectively Exhaustive) Owner: deciqai Summary: Activate when: user says 'decompose this', 'structure this thinking', 'MECE', 'issue tree', 'Minto Pyramid', 'how do we cover all the cases without double-co... Tags: latest:1.0.5 Version history: v1.0.5 | 2026-07-16T18:06:02.579Z | user Description tail link + agents machine-readable metadata line (deciqai.com/s/mece.json) v1.0.4 | 202","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":2018,"uniquenessScore":47,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T15:52:51.630Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T15:52:51.630Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T20:57:53.577Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}