The AI MECE Problem Structure Coach skill for Claude

The problem this skill solves is a meeting-room problem you probably recognise. Something is wrong, everyone has a theory, and within ten minutes the room is discussing solutions while nobody has written the problem down. Data gets pulled without anyone knowing which question it is meant to answer. Two people investigate the same thing from a different angle. And the branch where the real answer sits is on nobody's whiteboard, because nobody noticed it. Against that, the skill sets a fixed order: structure first, only then solve.

It is written for anyone who occasionally faces a problem bigger than a task: entrepreneurs, managers, consultants, marketers, project leads. The typical triggers the skill itself names are strategic choices, falling revenue, customer retention, productivity questions, market research and organisational problems. In short: the moments when people jump straight to solutions. It belongs with the AI and automation service, where we actually set up this kind of working method for businesses.

There is one thing you should know beforehand, and the skill says so itself: it structures, it does not solve. At the end of a session you do not have an answer to your question. You have a tree, a set of hypotheses and a place to start. That sounds like less than an answer, but it is exactly what is missing the moment a problem feels too big. Structure makes the research efficient, it does not replace the research.

The question is a solution in disguise. How do we increase our advertising budget is not a problem question but a decision that has already been made. Anyone who starts like that only ends up checking whether the decision is right. What the skill requires is that the resolution question starts with why, how or which, that it can be answered through research, and that it contains no solution. Why is our monthly revenue falling meets that, and that difference decides everything that hangs beneath it.

The branches overlap. Split a problem into marketing, sales and customer satisfaction, and a cause can fall into all three at once. The result is duplicated work and an argument about who owns what. The M in MECE stands exactly for that: mutually exclusive, the parts rule each other out.

There is a gap in the breakdown. This is the most expensive mistake, because you do not notice it. If your falling revenue splits into fewer customers and lower order value, but nobody writes down departed customers as a separate branch, the whole team spends months investigating the wrong half. The C in collectively exhaustive covers that: together a hundred per cent.

The hypothesis cannot be wrong. Customers are unhappy is not a hypothesis, because there is no research imaginable that could knock that statement down. Each branch therefore needs a falsifiable statement: customers who came on board in the first quarter more often cite disappointing delivery times when they cancel. You can test that, and so you can also lose it.

Everything matters equally. Without prioritisation a tree stays a nice picture. That is why it marks which twenty per cent of the branches is expected to deliver eighty per cent of the answer, with the reason attached, and closes with one action. Not three, because whoever starts with three actions starts with none.

In diff form, with lines from the skill's own example: what goes out as the framing, and what comes back in its place.

Not only at the technical terms MECE, issue tree, problem tree, Minto, Pyramid Principle, SCQA and the McKinsey method, but just as much at how people really say it: where do I start, this problem is too big, I cannot see the wood for the trees, help me break this down, what is the core question, why is our revenue falling, why are customers leaving, and I do not know which data to pull. The frontmatter also states straight away when you should not use it: for pure fact questions with one answer, and for tasks under two hours, because structuring is then more expensive than just doing it.

After that comes a chapter on the theory the skill rests on, and only then the working method: four phases in a fixed order. Phase 1 is the problem definition via SCR, three lines: the situation in facts, the complication that disrupts the situation with since when and how noticeable, and the resolution question. That question becomes the root of the tree, and the instruction is explicit to put it forward for confirmation first, because if the root is wrong, everything beneath it is wasted effort.

Phase 2 is the decomposition. The root question splits into two to five sub-questions, and the skill must deliberately choose a structure from six options: algebraic, process-based, per stakeholder, per segment, following an existing model such as 7S, or internal versus external. Algebraic is preferred where possible, because it is the most watertight. It names which structure it chooses and why, splits at most three levels deep, and tests every split out loud against the two questions from FIG.02.

Phase 3 hangs four things on every branch: a falsifiable hypothesis, an impact estimate of high, medium or low with one sentence why, the evidence needed including where to get it, and an owner who works it out. If the data to estimate the impact is missing, it says [UNKNOWN]. A made-up figure is never filled in there.

Phase 4 closes it off: the MECE check once more, explicit and written out as a sentence rather than a tickbox, the 80/20 marking with a reason, and one concrete action for tomorrow of at most one working day, together with the question it answers and what you know afterwards. There is also a mandatory input checklist of six points, with the rule that the skill only asks about what is missing and asks at most two questions at a time.

It contains a fixed output format with the headings Problem definition, Issue tree, MECE check, 80/20 priority and Action for tomorrow. It contains a fully worked example, which you see in shortened form in FIG.01 and FIG.02. And the file closes with eight refusals, five limits of the framework and six sources. If you want to learn how to write a file like this yourself, writing a SKILL.md NL explains that structure step by step.

MECE and the pyramid come from Barbara Minto. She developed the principle in the 1960s at McKinsey and worked it out in The Pyramid Principle. Two dates are both correct and belong to different editions: in 1973 she self-published it as a series of booklets, and in 1987 the wide-release edition appeared from Pearson, the one the rest of our skill pages refer to.

MECE stands for Mutually Exclusive, Collectively Exhaustive: parts that do not overlap and together cover a hundred per cent of the problem. The Pyramid Principle itself is about something else, namely how you communicate the answer: top down, with the governing thought up front and the supporting argument underneath. MECE sits beneath that, because it decides how you split the problem before you formulate an answer. Anyone mainly after the communication part is better off with the Pyramid Principle Writer skill, and for the story opening there is the SCQA communication coach NL.

Hypothesis-driven working comes from Ethan Rasiel. The McKinsey Way from 1999 describes the practice behind it: you do not start by collecting data but with a hypothesis, and the data you then gather has a purpose. The skill translates that into the requirement that every branch carries a falsifiable statement, along with the evidence needed and where to get it. In 2001 Rasiel also wrote The McKinsey Mind with Paul Friga, which appears as the second source in the file.

The logic tree and the 80/20 come from Conn and McLean. Bulletproof Problem Solving from 2018 works out the tree as a work plan: for every branch you know who picks it up, what evidence is needed and when you are done. That is also where the requirement comes from to mark which twenty per cent of the branches is expected to deliver eighty per cent of the answer. Anyone after exactly that prioritisation part can use the Pareto Analyst skill alongside this one.

The 5 Whys comes from Taiichi Ohno. Toyota Production System from 1978 appears in the source list as a supplementary technique for a single branch. That is a useful boundary: MECE orders the whole, the 5 Whys digs down within one branch towards the cause. The two do not clash, they work one after the other. The 5 Whys Analyst skill is the logical next step once you know which branch you want to dig into.

The warning against confirmation bias comes from Richards Heuer. Psychology of Intelligence Analysis from 1999 is about testing competing hypotheses instead of confirming one. That is the sharpest self-criticism in the whole file: hypothesis-driven working makes you faster and at the same time increases the chance that you find what you already thought. Actively looking for evidence that knocks down your own hypothesis is therefore a hard requirement in the file. Anyone who wants to train that reflex more broadly can turn to the First Principles Thinker skill, which strips assumptions down to what is really certain.

Even without installing the skill you can use these principles to tackle your own problem better: write down the question before you think up solutions, test your breakdown for overlap and gaps, and look for evidence that proves you wrong.

After that, using it is simple: describe your problem in plain language, including exactly what is happening, since when, and which figures you do and do not have. The rawer the description, the better, as long as it contains facts. Whatever is missing, it asks about itself, at most two things at a time. If the breakdown does not work well enough for your industry, open the SKILL.md and add your own decomposition structures: it is a text file, not a black box. The knowledge base has the wider explanation of working with AI.

There are also situations where you are better off leaving it, and the file itself is clear about that. For pure fact questions with one answer, a tree is pointless. For tasks under two hours, structuring is more expensive than just doing it. And for problems where the problem itself is not yet settled, or for creative and design questions, diverging works better than splitting up: you need to see more possibilities first, not fewer.

It also names five limits of the framework itself, and they are more honest than you would expect from an instruction file. MECE is an ideal, not a guarantee. In social and organisational problems, causes almost always overlap a little. The goal is a usable split, not a perfect one.

The tree is only as good as the root question. A neat structure under the wrong question is wasted precision with a reassuring appearance. Hypothesis-driven working increases the risk of confirmation bias, so actively look for evidence that knocks down your hypothesis. The model fits poorly with problems that have no clearly defined shape, as already mentioned above. And with strong feedback between branches a tree is a simplification: if the price is driving the churn and the churn in turn puts pressure on the price, you name that loop instead of cutting it away. In FIG.02 that warning appears literally at branch 3.

What the skill also does not do is tell you whether the problem you bring is the right one to work on right now. A perfectly structured analysis of a side issue stays an analysis of a side issue. Anyone who first wants to establish whether the problem is even urgent is better off starting with a risk view such as the Pre-Mortem Analyst skill NL, which lets a plan fail in advance to see where it breaks.

A good tree saves you weeks of investigating the wrong thing, but it does not deliver the research itself. If your problem sits in the corner of online visibility, the first branch is often quicker to test than you think: the free SEO scan shows in a few seconds where your site stands. And if you want to talk further about what AI can do for your business, from loose skills to full automation, we simply do that in a conversation.