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.
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.
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.