The Five Whys for Requirements Discovery
The request arrived as a one-liner from the claims operations director: the weekly claims-aging report needs to run faster. The business analyst did what the training said. She asked why, five times, and wrote down the chain:
Why faster? Because adjusters wait for it before prioritising their queue.
Why do they wait? Because it takes most of Monday to come out.
Why does it take most of Monday? Because it's slow to run.
Why is it slow? Because it queries the whole claims history.
Why the whole history? Because nobody added a date filter.
Root cause: a missing date filter. The fix took a developer an afternoon. The report's run time dropped from about four minutes to under thirty seconds. Adjusters still got it on Monday afternoon.
This example is a composite, built from a common requirements pattern in insurance operations. The figures are illustrative.
The chain was internally consistent and wrong at step three. The report was never slow to run. It was slow to arrive, because a team lead exported it, cleaned it by hand against a spreadsheet of reopened claims that lived on a shared drive, and emailed it out. Nobody in the conversation mentioned that step, because the director didn't know it existed and the analyst didn't ask a question that would have found it.
Why Five Whys is attractive for requirements
People ask for solutions. "Run faster", "add an export button", "send me an alert" are fixes the asker has already designed for a problem they haven't stated. A requirements practitioner's first job is to recover the problem, and Five Whys is the simplest tool for it: no template, no workshop, no diagramming software, and it works in a hallway.
It also has a respectable lineage. Taiichi Ohno described asking "why" five times as the basis of Toyota's scientific approach to problems in Toyota Production System (published in English in 1988). That origin is part of the appeal: it sounds like engineering rather than interviewing.
What the common version misses
The common version treats Five Whys as an interrogation that converges on a single root. Two properties of the technique make that dangerous.
It produces a chain, and real causes are trees. Each "why" has several true answers. The interviewer picks one (usually the one closest to their own expertise) and follows it. A developer running the claims conversation will hear "slow" and drift towards query performance. A process analyst would have drifted towards the manual step. The technique doesn't tell you which branch to take, so it amplifies whoever is asking.
Nothing in the method checks the answers. Each answer is a claim from someone with partial knowledge. Step three, "because it's slow to run", was the director's belief, stated with confidence and never tested. Every later step was built on it.
These aren't new objections. Alan Card's 2017 paper in BMJ Quality & Safety, "The problem with '5 whys'", made the same case for root-cause analysis in healthcare: the technique is widely promoted, its popularity is not the result of evidence that it works, and it tends to reduce complex problems to a single causal path. He kept its value as a teaching tool. That distinction is useful for requirements too: Five Whys is a good way to open a discovery conversation and a poor way to close one.
How it works when it works: branch, verify, stop at a decision
A version that holds up has three changes from the classroom one.
Branch at every answer. After each answer, ask "is that the only reason?" before asking "why?" Write the alternatives down even if you only follow one. A two-level tree with three branches each is nine candidate needs, and it takes about the same time as a five-step chain.
Verify each answer before building on it. For every answer, name the evidence that would show it was false, and get it if it's cheap. "It's slow to run" is falsified by one look at the job log. "Adjusters wait for it" is falsified by asking two adjusters what they do on Monday morning. This is the discovery move: the data that would disprove the answer. If you can't name any, the answer is an opinion and should be labelled as one.
Stop at a decision, not at five. The right depth is the first level at which the answer changes what you would build. Going deeper ("why do reopened claims live in a spreadsheet?" → "because the claims system can't flag them" → "because the vendor contract...") eventually reaches causes nobody in the room can act on. Stop at the level where a requirement can be written and owned.
The claims report, done again
Here is the same conversation with the three changes. It took about forty minutes across two sessions, including a twenty-minute sit-in with an adjuster.
Level | Answer | Alternatives raised | Evidence checked | Result |
1. Why faster? | Adjusters wait for it to prioritise | They could prioritise from the live queue | Asked 2 adjusters: both wait, because the live queue doesn't show reopened claims | Holds |
2. Why does it come out late? | It's slow to run | Manual preparation; distribution delay | Job log: runs in ~4 min at 06:10. Report lands in inboxes at ~13:30 | False |
2b. What happens between 06:10 and 13:30? | Team lead cleans it against the reopened-claims spreadsheet | — | Sat with team lead for one run: ~3 hours of matching by claim number | Holds |
3. Why the manual match? | The claims system can't flag reopened claims in the extract | Report author unaware of a flag | Checked schema: a reopen_date column exists, unused by the report | Decision point |
The requirement that came out of the table is not "run faster". It is: include reopened claims in the aging report using reopen_date, so the report is usable at 06:15 without manual preparation; retire the shared spreadsheet once two weekly runs match it. That requirement has an owner, an acceptance test (the two matching runs) and a measurable outcome (report usable by 06:15). The director's original request would have been met as a side effect.
The step that changed everything was 2b, and it came from a branch, not from the next "why". The chain version never asked what happened between the job finishing and the report arriving.
Why this matters more when an AI writes the code
When a requirement goes straight into a ticket and the ticket goes into an AI coding assistant, the stated request is the specification. Ask for a faster report and you will get a faster report: indexed, filtered, well-tested and irrelevant to the Monday problem. Generated code is complete with respect to what you said and silent about what you didn't, which is the argument of What AI-Generated Code Structurally Skips. Discovery techniques are the step that decides what gets said. The faster the build, the more expensive a wrong requirement becomes in relative terms, because the wrong thing arrives sooner and looks finished.
How to tell whether your Five Whys is working
Run these on the last three requirement conversations where you used the technique.
The falsification test. For each answer in your chain, write the piece of evidence that would have shown it was false. Count how many you actually checked. If the answer is zero, your chain is a record of one person's beliefs, and the requirement inherits their blind spots.
The branch count. Count the alternatives you wrote down. A five-step chain with no alternatives means you followed one path and never saw the others.
The decision test. Compare the requirement you wrote to the original request. If they are the same, either the request was right (it happens; "add a logout button" usually is exactly what's needed) or the conversation didn't get past the solution. Look at the evidence column to tell which.
The solution-word check, before you start. Underline the solution words in the request: faster, export, alert, dashboard, button. Each one is a design decision the asker has already made. Those are the words to ask "what would that let you do?" about first.
When to use something else
Several interacting causes. If early branches multiply quickly, switch to a cause-and-effect (fishbone) diagram, or to observing the work directly. Five Whys handles one path at a time.
Incidents with safety, financial or regulatory consequences. Use a structured method designed for complex causation. Card's critique applies with full force here.
Politically loaded requests. Repeated "why" can read as a challenge to someone's judgement. Frame it explicitly ("I want to make sure we build what actually fixes Monday") and reflect each answer back before asking the next.
Preference requirements. "The logo should be on the left" has no hidden problem to find.
Putting it into practice
Before the conversation: underline the solution words in the request and list who does the work today, not just who asked.
During: at each answer, ask "is that the only reason?" and record alternatives. Mark each answer verified, checkable or opinion.
Between sessions: check the cheap evidence: logs, schemas, ten minutes watching someone do the task. Most false links break here.
Write the requirement at the decision level, with the acceptance test that would show the need is met, not just the feature delivered.
Carry the table into the ticket. The evidence column is the context an engineer, or an AI assistant, needs to build the right thing. For the techniques that pair well with this one, see requirements elicitation techniques that work and running your first stakeholder interview.
Final takeaway
Five Whys recovers the problem behind a request only if each answer is treated as a hypothesis. Asked as a chain of beliefs, it converges confidently on whatever the asker already suspected. Asked as a branching search with evidence checked at each step, it is one of the cheapest discovery tools there is.
Your next action: take the next feature request that contains a solution word. Before writing the ticket, build a two-level why-tree with alternatives, and check one piece of evidence per branch. If the requirement you end up with differs from the request, you've just saved the build. For the AI-feature version of this conversation, read discovery for AI features: scoping before you prompt.
Sources
Ohno, T., Toyota Production System: Beyond Large-Scale Production, Productivity Press (1988; Japanese edition 1978). The source of "ask why five times".
Card, A. J., "The problem with '5 whys'", BMJ Quality & Safety 26(8):671–677 (2017). https://qualitysafety.bmj.com/content/26/8/671
