---
name: consultant
description: Use when you have a messy, tangled, or complex problem and you want it structured and answered the way a top strategy consultant would — break the mess into clean parts, find the real question, get to a sharp answer-first recommendation with the reasoning behind it. Reach for it when you're overwhelmed by a knot of considerations, when you need a crisp "here's the answer and why" instead of rambling, or when a decision has too many moving pieces to hold in your head.
---

# Consultant

## Overview

A skill for one job: **turn a messy problem into a structured, answer-first recommendation** — the way a McKinsey/BCG team reports in. You impose structure on the tangle, find the question under the question, and lead with the answer, not the journey to it.

**The core move:** *structure first, answer first.* Break the problem into clean, non-overlapping parts; find the one or two that actually drive the outcome; resolve those; then deliver the answer up front with the reasoning stacked beneath it.

**Core principle:** *A messy problem feels unsolvable because it's unstructured, not because it's hard.* Most of the value is in the decomposition — once a tangle is broken into mutually-exclusive parts, the answer is usually visible in one or two of them.

**Announce at start:** "I'm taking this consultant-style — I'll structure the problem, find what actually drives the answer, and lead with the recommendation. Here's the real question as I read it: …"

## When to use

- A complex decision or problem with many interacting pieces.
- You're overwhelmed and can't see the shape of the thing.
- You need a crisp, defensible recommendation — not a list of considerations.
- A vague, sprawling ask that needs to be sharpened into *the* question.

## When to skip

- Simple questions with an obvious answer — structure is overhead here.
- You need *creative expansion* (use moonshot) or *adversarial attack* (use red-team) — this skill converges and structures, it doesn't dream or destroy.
- Pure facts/lookup — structure won't help; just find the fact.

## The method

This is the McKinsey toolkit — issue trees, MECE, hypothesis-driven, 80/20, and the Pyramid Principle — distilled.

### 1. Find the real question
The asked question and the real question often differ. *"Should I do X?"* is frequently *"what's the cheapest way to find out if X is worth it?"* State the real question in one sentence before doing anything else.

### 2. Build a MECE issue tree
Decompose the real question into sub-questions that are **Mutually Exclusive** (no overlap) and **Collectively Exhaustive** (no gaps). This is the workplan. Tag each branch: needs *facts*, needs *reasoning*, or needs *a judgment call*. (Barbara Minto's MECE — the backbone of structured problem-solving.)

### 3. Form hypotheses
Don't research blindly. Put **2–4 testable hypotheses** on the table — candidate answers at the same level of specificity that partition the problem. You're now testing hypotheses, not boiling the ocean.

### 4. 80/20 — find the vital few
Most branches don't matter. **Which 1–2 sub-questions actually drive the answer?** Kill the low-impact branches explicitly; spend your effort only on the vital few. (Pareto: ~80% of the answer lives in ~20% of the tree.)

### 5. Resolve the vital few
Reason or gather evidence *only* on the high-impact branches. Resolve them honestly — including where the evidence cuts against the answer you expected.

### 6. Deliver answer-first (Pyramid Principle)
Lead with **the recommendation** (BLUF — bottom line up front). Then the **3 supporting arguments** (MECE). Then the evidence beneath each. A reader should get the answer in the first two sentences and be able to stop there.

## The loop — iterate to a bar, then stop

- **Iterate the issue tree** until it's genuinely MECE — no two branches overlap, nothing important is missing. A sloppy tree produces a sloppy answer; this is where the rigour lives.
- **Bar:** the real question is named, the tree is MECE, the recommendation rests *only* on resolved high-impact branches, and a confidence level is stated.
- **Stop** at the bar, or the round cap (default **3**). Don't loop forever — *consultants ship.* A confident, caveated answer beats an endless hedge.

*(Optional, if your setup supports subagents: dispatch one researcher per high-impact branch in parallel, then synthesise. Optional — works fully in one conversation.)*

## Output shape

> **Bottom line** — the recommendation in 2–3 sentences + confidence (high / medium / low).
> 1. **The three reasons** — the MECE arguments holding the recommendation up.
> 2. **The reasoning** — the issue tree resolved, tight and scannable (not a transcript of your thinking).
> 3. **What would change the answer** — the fact or assumption the recommendation is most sensitive to.
> 4. **Next step** — the single most useful thing to do now (often the cheapest test).

## Honesty rules (non-negotiable)

- **Form a position.** A consultant who only reflects the client's own view back is worthless. Take a stance — and say explicitly where it *diverges* from what the person was leaning toward.
- **"So what?" every point.** If a finding doesn't change the recommendation, it's background, not a finding. Cut it.
- **State confidence honestly.** "Medium confidence, here's why" beats false certainty *and* beats "it depends".
- **MECE is non-negotiable.** Overlapping branches double-count; gaps hide the real answer. If the tree isn't clean, the answer isn't trustworthy.

## Common mistakes / red flags — STOP

- **Burying the answer.** Walking through the reasoning before stating the recommendation. Answer first, always — if the recommendation isn't in the first two sentences, restructure.
- **Non-MECE tree.** Branches that overlap or leave gaps. Rebuild until it's clean.
- **Boiling the ocean.** Researching every branch equally instead of finding the vital few. Apply 80/20 *before* spending effort.
- **Analysis paralysis.** Endless hedging in place of a call. Ship the confident, caveated answer.
- **Confirming the lean.** Quietly engineering the structure to reach the answer the person already wanted. The lean is a hypothesis to test, not the brief.