MECE Hypothesis Tree Generator

A MECE hypothesis tree generator takes a consulting problem statement and the data or context you already have, then drafts a mutually exclusive, collectively exhaustive set of hypotheses that explain the problem and point to where analysis should go next. The output is a structured tree: a governing question at the top, primary branches that do not overlap, and nested sub-hypotheses that cover the space without leaving obvious gaps.

Engagement managers use this early in the analyze stage, when the team has a client-approved problem framing but has not yet locked the issue tree that will drive the workplan. The model accelerates the first pass from prose to structure. It does not replace the engagement team's judgment about what is true, what is client-safe, or what belongs in a steering-committee pack.

The practical value is speed with discipline. Building a clean MECE tree by hand is slow when the problem spans multiple functions, geographies, or P&L levers. A drafted tree gives the team something concrete to critique, merge, and re-label instead of starting from a blank whiteboard. Related structuring patterns, such as ./problem-decomposition.md and ./issue-tree-prioritization.md, sit downstream of this draft once the branches are stable.

The minimum viable input is a clear problem statement: who faces the issue, what outcome is off-target, over what period, and against what baseline or aspiration. Vague prompts like "improve performance" or "fix the go-to-market" are not enough. The generator should return empty output when the problem statement is missing, or when it is too thin to support mutually exclusive branches without inventing facts the team never provided.

Useful supporting inputs improve branch quality without changing ownership:

• Scope boundaries: in-scope business units, regions, products, customer segments, and time horizons
• Known constraints: regulatory limits, capacity, brand rules, or non-negotiable client decisions
• Available evidence: excerpts from kickoff notes, prior decks, financial extracts, interview themes, or operational metrics already in the workroom
• Decision criteria: what "good" looks like for the engagement (margin, growth, cash, risk, service levels)
• Disconfirmed ideas: hypotheses the client or partner has already ruled out, so the tree does not reopen closed doors

The model should treat supporting data as grounding, not as a license to overfit. If a metric is incomplete or a note is anecdotal, the corresponding leaf should stay tentative and labeled as a hypothesis to test, not as a conclusion. When critical fields are blank, prefer fewer, cleaner branches over a dense tree built on guesswork.

A usable draft follows the logic consulting teams already use in issue trees, not a generic mind map. Start with one governing question that restates the problem in decision form (for example, which drivers explain the margin gap, or which interventions are most likely to restore growth within the mandate). From that root, primary branches should be MECE at the level that matters for the workplan: typically driver families, not a flat list of tactics.

Good primary branches answer "what could be true?" in exclusive categories. Classic patterns include volume versus price versus mix; demand versus conversion versus retention; cost of goods versus operating expense versus working capital; or process failure versus policy failure versus data quality. The right cut depends on the problem. The model should choose a cut that matches the available data language and the decision the client needs to make.

Under each primary branch, sub-hypotheses should be specific enough to imply analysis: what to measure, who to interview, which comparison to run. Leaves that cannot be tested should be flagged as framing assumptions rather than presented as equal peers. Cross-links between branches are fine as notes ("this cost issue may be a consequence of volume decline"), but the tree itself should stay exclusive so workstreams do not double-count the same explanation.

Collective exhaustiveness is a design goal, not an absolute claim about reality. The draft should cover the major plausible explanations given the inputs, and it should surface residual "other / unknown" space when the data cannot close the set. That residual branch is often the most honest part of an early tree: it tells the team where discovery work is still required.

The model drafts. The engagement team owns. Partners and engagement managers remain accountable for the issue tree that appears in client materials, for the workstream map derived from it, and for any recommendation that rests on which hypotheses survive testing.

Human review should focus on four checks before the draft becomes team doctrine:

1. MECE integrity: Do primary branches overlap? Are material explanations missing? Would a skeptic say two leaves are the same idea in different words?
2. Client framing: Does the wording match how the client describes the business, or does it introduce jargon that will derail the next workshop?
3. Evidence fit: Which leaves are supported by inputs already in hand, and which are speculative and need data requests?
4. Workplan implications: Can each high-priority leaf turn into an owner, a method, and a timeline without inventing analysis the mandate never funded?

Expect iteration. The first draft is a structuring aid for an internal working session. The second pass, after partner and workstream-lead edits, is what may be shared with the client. Client-facing trees often collapse technical leaves into fewer, plainer branches; that compression is a human editorial job, not something to automate away.

Do not treat model confidence language as proof. A fluent tree can still be wrong, biased toward the most common consulting cuts, or over-indexed on whatever document chunk was longest. The team's falsification plan (what would disprove each branch) is what turns a neat diagram into analysis.

Empty output is the correct response when the problem statement is absent, or when it lacks the minimum specificity to build exclusive branches without fabricating scope. Thin inputs include single-sentence goals with no baseline, problems that mix multiple unrelated decisions, or statements that ask for recommendations before any hypothesis framing ("tell us what to do about digital"). In those cases, returning nothing is safer than producing a polished but invented structure.

Other failure modes deserve explicit handling rather than silent "helpfulness":

• False MECE: branches that look exclusive but share the same root cause under different labels
• Tactic trees: lists of initiatives presented as hypotheses, which short-circuit diagnosis
• Scope creep: branches outside the mandate because a related industry pattern appeared in training-like knowledge
• Evidence laundering: turning soft interview color into hard claims in leaf titles
• Premature ranking: ordering hypotheses by narrative appeal instead of by testability and impact on the decision

When output is produced, it should make uncertainty visible: mark untested leaves, note missing data, and avoid implying that exhaustiveness has been proven. If the team later discovers a material missing branch, revise the tree and re-cut workstreams; do not bolt the new idea onto a leaf that already means something else.

Use the generator after problem definition is stable enough for a kickoff memo, and before detailed workstream staffing. Feed the approved problem statement plus the best available notes and extracts. Generate a draft tree, then run a short internal critique with the partner and analytical leads: merge overlaps, rename branches into client language, drop out-of-scope leaves, and assign each surviving branch a test plan.

Once the tree is accepted internally, translate it into the workplan: which analyses, which data requests, which interviews, and which decision meetings unlock which branches. Keep the generator available for refresh cycles when new evidence kills a primary branch or opens a residual "other" path. Each refresh should start from the updated problem statement and evidence pack, not from endless free-text chat that drifts away from the mandate.

Success looks operational, not theatrical. The engagement manager gets to a defensible MECE structure faster, the team argues about content instead of blank-page framing, and client-facing issue trees still carry human authorship. The model remains a drafting assistant for analysis structure. Ownership of hypotheses, evidence, and recommendations stays with the engagement team.