The Consulting Craft

Module 04

The Consulting Craft

Structured problem-solving, MECE, issue trees, hypothesis-driven thinking, the 80/20, and synthesis. The part that separates a consultant from someone with opinions.

Anyone can have opinions about a business. A consultant has a method for turning a vague, messy problem into a structured set of answerable questions, and then answering the ones that matter most. Master this module and you'll think differently for the rest of your life — it's the genuine core skill of the trade.

Define the real problem first

Clients rarely hand you the real problem. "Our sales are down" is a symptom. "We need a new website" is a solution to an unstated problem. The first discipline is to keep asking until you have a sharp statement: what exactly is wrong, for whom, by how much, since when, and what does success look like? Time spent here is never wasted — solving the wrong problem brilliantly is the most expensive mistake in consulting.

MECE — the structuring principle

MECE stands for Mutually Exclusive, Collectively Exhaustive. When you break a problem into parts, the parts should not overlap (mutually exclusive) and together should cover everything (collectively exhaustive). "Profit = Revenue − Costs" is MECE. "Our customers are: young people, students, and women" is not — those overlap and miss people. MECE thinking stops you double-counting and missing whole chunks. It feels pedantic until it saves you from a humiliating gap in a client meeting.

Issue trees — break the big problem into small answerable ones

Take the problem and split it, MECE-style, into drivers; split each again, until you reach questions small enough to investigate. "Why is profit falling?" splits into "is revenue falling?" and "are costs rising?" Revenue splits into "fewer customers?" and "lower price per customer?" Fewer customers splits into "fewer new ones?" and "more leaving?" Within a few branches a hopeless question becomes a handful of checkable ones. Drawing the tree is the analysis.

Hypothesis-driven thinking — don't boil the ocean

You can't investigate everything, so form an early, explicit best guess — a hypothesis — about where the answer lies, then look for evidence that would confirm or kill it. "I suspect profit fell because churn rose after the price increase." Now you know exactly what data to pull. If the evidence kills it, great — you've eliminated a branch and form the next. This lets a small team crack a huge problem in weeks. The trap: hunting only for evidence that flatters your hypothesis. Actively try to disprove it.

The 80/20 rule in analysis

Roughly 80% of an effect usually comes from 20% of the causes. In practice this means: before diving deep, find the few things that matter most and start there. Which 3 customers drive most revenue? Which 2 cost lines dwarf the rest? Which one step in the process causes most of the delays? Chasing the trivial many while the vital few sit unexamined is how analysis burns weeks and produces little. Find the 20% that explains the 80%, and aim your effort there.

Synthesis beats analysis

Analysis is breaking a problem apart; synthesis is putting the pieces back together into a single clear "so what." Beginners stop at analysis and hand over a pile of findings; the client is left to figure out what it means. The valuable move is the sentence that says: given all this, here is what's going on and what you should do. Every chart, every finding, should ladder up to one governing conclusion. If you can't state the "so what" in a sentence, you haven't finished thinking.

The engagement lifecycle

A typical piece of work moves through phases: scope (agree the problem and 'done') → diagnose (structure, gather data, test hypotheses) → recommend (decide what should change) → communicate (get the client to believe and act) → sometimes implement / follow up. Beginners over-invest in diagnosis and under-invest in scope and communication. The thinking only matters if the client acts on it.

Key takeaway

Define the real problem → break it down MECE into an issue tree → form a hypothesis → use the 80/20 to investigate the vital few → synthesise into one clear 'so what.' That loop is the consultant's core engine. It works on a billion-dollar strategy question and on what to cook for dinner.

For Orelis & the app

This module is your product's spine. Generic AI advice feels hollow because it skips straight to recommendations without this structure. If your app visibly does the work — restates the real problem, builds a clean issue tree, states a hypothesis, asks for the specific data that would test it, then synthesises one clear conclusion — it will feel categorically different from a chatbot emitting five bullets. Consider making the issue tree a visible, interactive artifact the user watches the AI build. That transparency is the trust-builder.

Test yourself

Q1A client says 'profits are down 20% — we think we need layoffs.' What's wrong with the framing, and what are the first two levels of an issue tree?
Show a worked answer
'Lay people off' is a solution smuggled in as the problem. The real problem is 'profit fell 20%' — cause unknown. Tree: Profit down -> (A) Revenue fell or (B) Costs rose. Revenue -> fewer customers / lower price per customer / changed mix. Costs -> higher cost of goods / higher operating costs / one-offs. Only after locating the driver do you know whether cutting staff (an operating-cost lever) even addresses it — it might be a revenue/churn problem layoffs would worsen.
Q2Why state a hypothesis early instead of staying 'open-minded' and analysing everything?
Show a worked answer
Because everything is infinite and budgets are not. A hypothesis focuses effort: it tells you exactly which data confirms or kills it, so you investigate the highest-leverage question first instead of boiling the ocean. Hold it loosely — actively seek disconfirming evidence and drop it the moment the data says so. Open-mindedness lives in how readily you kill the hypothesis, not in refusing to form one.
Q3You've produced fifteen findings about a struggling product. The CEO asks 'so what should we do?' and you list all fifteen. What did you fail to do?
Show a worked answer
You analysed but didn't synthesise. Fifteen findings is a pile, not an answer. The job is to ladder them up to one governing conclusion and a recommendation — e.g., 'the product is fine but it's priced for the wrong segment; reposition it upmarket.' The findings become the support for that single 'so what,' not the deliverable themselves. If you can't state the conclusion in a sentence, the thinking isn't done.