Problem-Solving Frameworks: Define, Decompose, Hypothesize, Test
Most people solve the wrong problem fast instead of the right problem slowly. This chapter gives you one repeatable process — Define, Decompose, Hypothesize, Prioritize, Test, Iterate — that you can run on anything from "my sales dropped" to "I can't focus." You will end with a worked example you can copy line for line. The payoff: clearer thinking, sharper writing, and the ability to turn a vague worry into concrete next steps.
The biggest trap: jumping to a solution
When you hear a problem, your brain rushes to fix it. That feels productive. It usually isn't. You end up answering a question nobody asked.
- Problem-finding
- Figuring out what the real problem actually is. The slow, valuable part.
- Problem-solving
- Building the fix once you know the real problem. Easier and faster.
Einstein is often quoted (loosely) as saying that if he had an hour to save the world, he'd spend 55 minutes defining the problem and 5 minutes solving it. Whether or not he said it, the lesson holds: most failures come from solving a poorly defined problem.
Step 1 — Define the real problem
Before anything else, write the problem as one clear sentence. Then stress-test it.
- Restate it in plain words. "What problem are we actually solving?" Say it out loud.
- Ask "why" a few times. Each "why" digs one layer deeper (this is the "5 Whys" technique from Toyota). "Sales dropped." Why? "Fewer orders." Why? "Repeat customers stopped buying." That last sentence is a much better problem.
- Name the gap. A problem is the gap between what is and what you want. State both: "Repeat orders fell from 100 to 60 per month; I want them back at 100."
- Check it's a problem, not a solution. If your sentence contains an answer ("build an app"), strip it out.
Step 2 — Decompose into parts (issue trees and MECE)
A big problem is overwhelming because working memory — the small mental "desk" where you hold ideas — can only juggle a handful of things at once. Decomposing means breaking one big problem into smaller, separate pieces your mind can handle one at a time.
Consultants draw an issue tree: the problem at the top, branching into its parts.
- MECE
- "Mutually Exclusive, Collectively Exhaustive." Fancy words for: the branches don't overlap, and together they cover everything. No double-counting, no gaps.
Repeat orders fell (100 -> 60)
|
+-- Fewer customers come back
| +-- They were unhappy
| +-- We stopped reminding them
|
+-- Returning customers buy less
+-- Prices rose
+-- Fewer items they want
"Fewer customers" and "they buy less" don't overlap, and together they explain the whole drop. That is MECE. Now you can attack one branch at a time instead of staring at a wall.
Step 3 — Generate hypotheses
A hypothesis is a smart guess you can check — a possible answer stated as a sentence, not a vague feeling. Instead of investigating everything, you guess the likely cause and test that first. This is the consultant's "hypothesis-driven" approach: start with a best guess, then look for evidence to confirm or kill it.
- Write hypotheses as full sentences: "Repeat orders fell because we stopped sending the monthly reminder email."
- Aim for 3–5, one per promising branch of your tree.
- Make each one falsifiable — it must be possible to prove it wrong. "Customers are sad" isn't testable. "Customers who didn't reorder gave low ratings" is.
Step 4 — Prioritize: impact vs. effort
You can't test everything. Rank your hypotheses by two questions: If true, how much does it matter (impact)? and How cheap is it to check (effort)? Do the high-impact, low-effort ones first.
| Effort \ Impact | High impact | Low impact |
|---|---|---|
| Low effort | Do first (quick wins) | Do if spare time |
| High effort | Plan carefully | Skip |
Step 5 — Test cheaply
Test the smallest, fastest way to get a real signal. You're not committing to a fix yet — you're checking whether a hypothesis is true. Look at existing data, ask five customers, run a tiny one-week trial. Cheap tests let you be wrong quickly and at low cost.
Step 6 — Iterate
Read the result. If the hypothesis held, design the real fix. If it didn't, cross it off and test the next one. Loop back as needed. Each pass narrows the truth. This mirrors the scientific method: guess, test, learn, repeat.
Define -> Decompose -> Hypothesize -> Prioritize ^ | | v +------- Iterate <----- Test cheaply ---+
Full worked example
- Define: "Why are sales down?" → repeat orders fell from 100 to 60/month over three months. Real problem: "Repeat orders dropped 40%; goal is back to 100."
- Decompose: Either fewer customers return, or returning ones spend less. The data shows the customer count dropped — the spend-per-order is flat. So the problem lives in the "fewer return" branch.
- Hypothesize: (1) "We quietly stopped the reorder reminder email in March." (2) "A new competitor undercut our price." (3) "Quality complaints rose."
- Prioritize: H1 is high-impact and free to check (look at the email log) → first. H3 is cheap too (read support tickets). H2 needs research → later.
- Test cheaply: The email log shows reminders stopped exactly in March — the same month sales fell. Support tickets show no rise in complaints (H3 killed).
- Iterate / fix: She restarts reminder emails for one week to 50 lapsed customers as a tiny trial. 12 reorder. The fix is real, not a guess — and she never wasted money on ads.
How this sharpens your other skills
This process also makes you a clearer thinker and writer. An issue tree is a ready-made outline — your branches become your paragraphs, so your writing stops rambling. Stating hypotheses as full sentences forces the fuzzy idea in your head into words, which is exactly the "I can't express it" gap. And reading with a problem in mind turns passive reading into idea-hunting: every fact becomes a possible answer to "which hypothesis does this support or kill?"
Practice
- De-solution drill. Find three sentences you've said this week that secretly contain a solution ("we need X"). Rewrite each as a pure problem statement (a gap, no fix).
- 5 Whys. Take one complaint you have and ask "why?" five times, writing each answer. Underline the deepest one — that's your real problem.
- MECE check. Draw an issue tree for any decision (e.g. "should I switch jobs?"). Test the branches: do any overlap? Is anything missing? Fix until clean.
- Cheapest test. For your top hypothesis from drill 2 or 3, list three ways to test it and pick the fastest one that could prove you wrong.