ConrayGambit 5 Whys
Concept
Toyota's Sakichi Toyoda popularized the 5 Whys: take any apparent cause and ask "Why?" five times in succession. Each answer becomes the new statement; you drill until you hit a root cause that isn't itself a symptom of something deeper.
In the consulting toolkit, 5 Whys complements issue trees. Issue trees go wide (every plausible cause). 5 Whys goes deep on one branch — the one you suspect dominates. It's especially useful after a Pareto step has named the vital 20%, before committing to interventions.
Five is a heuristic, not a magic number. Sometimes you reach root cause at three; sometimes you have to push to seven. The discipline is asking "why" until the answer stops being a symptom and starts being something structural.
Required output format
A numbered list of five Why → Because pairs, followed by a one-sentence root-cause statement.
**Starting problem:** [The apparent issue you're drilling into.]
1. **Why?** [First-level reason]
2. **Why?** [Second-level — drilling into #1's answer]
3. **Why?** [Third-level — drilling into #2's answer]
4. **Why?** [Fourth-level — drilling into #3's answer]
5. **Why?** [Fifth-level — drilling into #4's answer]
**Root cause:** [One-sentence structural cause, addressable as a system change.]
Defaults & flex points
| Default | When to flex |
|---|---|
| 5 levels deep | Sometimes 3 is enough (the structural cause is shallow); sometimes 6–7 is needed (deep institutional cause). Push until the answer is no longer a symptom. |
| One thread | Drill a single chain — don't branch mid-way. If the answer to a "Why?" is multi-causal, pick the dominant cause and drill that one. Run a separate 5 Whys on the other if needed. |
| Each Why builds on the previous | Don't restart the chain or re-ask the same question. Each answer must logically follow from the one above. |
The root-cause test: the final answer should be something you can change as a system — a process, a policy, an incentive, a data-flow design. If the final answer is "people are bad" or "the world is hard," you haven't reached root cause. Push deeper.
Example — sales / win rate
Starting problem: Mid-market sales win rate dropped from 28% to 17% in two quarters.
- Why? Late-stage deals (post-evaluation) are stalling at procurement and rarely closing.
- Why? Procurement keeps pushing back on our standard MSA terms — primarily on data-residency and indemnity.
- Why? Our standard MSA hasn't been updated since pre-GDPR; the data-residency clause is too vague for current customer expectations, and the indemnity cap is below industry norm.
- Why? The MSA template lives in a Google Doc owned by a Sales Director who left the company; updates have been ad hoc, with no formal review cadence.
- Why? There is no process owner for commercial document management — no cadence, no version control, no responsible counsel, no SLA on updates.
Root cause: The company has no process owner for commercial document lifecycle management. The MSA degradation is a symptom; the structural cause is institutional ownership of contract templates.
Common mistakes
- Stopping at "people did X." "Why? Because Bob made a mistake" isn't root cause — it's a symptom. Why did Bob make the mistake? What in the system permitted it?
- Branching the chain. "Why? Because of A and B and C" — pick one and drill. Run separate 5 Whys for the others if needed.
- Restating the same level. Each Why should drill down, not sideways. "Why is X happening? Because X is a problem" is not progress.
- Reaching for "macro factors" too early. "Why? Because of the economy" or "Why? Because of regulation" can be true but rarely actionable. Push for the proximate cause first.
When to use this skill alone vs. as part of the full analysis
- Standalone: when the user has a specific issue branch they want to drill, and they know which one. Skip the issue tree if the relevant branch is already obvious.
- As part of full analysis: in the 7-framework master (
strategy-consultant-7), 5 Whys runs after Issue Trees and before Hypothesis-Driven — drilling the most-likely branch surfaces the testable hypothesis.
Acknowledgment & License
The 5 Whys is attributed to Sakichi Toyoda and the Toyota Production System; widely adopted in lean manufacturing and consulting practice. Visual contract adapted in the spirit of the Analyst Academy original — see 5 Consulting Frameworks to Solve Any Problem. MIT-licensed; see LICENSE.