The Five Whys
Trace the surface request down to the root cause, then decide whether to build it as requested.
What users give you is the solution they could think of. Ask "why" a few times in a row and you'll reach the reason that produced their idea in the first place. The technique originated on Toyota's factory floor and later crossed into product work; the core is always the same—don't stop at the solution they propose. five-whys-wiki
What you'll run into:
- You build the feature as requested, and users still walk around it
- The same module keeps generating requests; patch one, another appears
- The feature list keeps growing, but nothing fixes the problem at the root
"Five" is a rough number, not a quota. Most chains bottom out by the third layer. The real rule: keep asking until the answer stops being "because the system doesn't support it" and becomes a business fact.
How to trace
With each layer, shift the object of your question from "the solution" toward "the situation":
| Layer | What you're asking | What the answer is |
|---|---|---|
| 0 | What do they want | A solution. Usually some interface they've seen |
| 1 | What will they do with it | A task. Context starts to appear |
| 2 | Why must they do it by hand | A gap. The step where the system breaks |
| 3 | Why does the gap exist | A structural problem. Often the original information architecture |
| 4 | Why was it designed that way | A business fact or legacy constraint. You can stop here |
The deeper you go, the more fundamental the problem—but the higher the cost to change it. So after reaching the bottom, step back one layer and pick a level you can afford. This is why "reaching the bottom" isn't the goal by itself: the deepest layer is usually organizational or procedural, which a product can't move. The real payoff sits one or two layers up.
When to stop
| You can stop | You're not there yet |
|---|---|
| The answer became a business fact | The answer is still "because the system doesn't support it" |
| The answer points at organization or process, outside the product's reach | The answer is still another feature name |
| Asking further starts producing repeats | The answer is "everyone does it this way" |
| You can derive a solution different from the original request | You still can't say exactly which step blocked them that day |
The first row on the right is the most common trap. "Because the system doesn't support it" says nothing—it just restates the problem, and asking once more moves you forward.
Three common misuses
- Question the situation, not the person. Five whys in a row easily becomes an interrogation, and the other person goes on the defensive. Replay the day together instead: ask "what happened at that step" rather than "why did you do that."
- Never chase a single chain. Real problems usually have several parallel causes. If layer two splits into two causes, branch—don't force one path to the bottom.
- Don't build the deepest layer just because you found it. Root causes tend to be architectural and take months to change. The right move is to get the root cause, then climb back to a level whose cost you can accept and fix it there.
Note for the AI
Having the AI ask for you keeps things more neutral than asking yourself—it won't defend your solution.
Below is a user request plus the background I know:
Request verbatim: [what the user said]
Background: [the scene you know, who this person is, what they're doing]
Act as a neutral product advisor and run a root-cause analysis:
1. Ask down layer by layer, giving your guess and reasoning at each
layer, at most five layers.
2. Label each layer: solution, task, gap, structural problem,
or business fact.
3. If a layer may have multiple parallel causes, branch them out;
don't pick just one.
4. Finally offer three solution directions at different levels,
each marked with the cost of change (hours / days / weeks+).
5. Explicitly list the assumptions you made while guessing, and
which of them I need to confirm with the user.
Don't give code, and don't give interface solutions.
Point five is the key. It separates "this step I'm guessing" from "this step you told me," so you know exactly what to ask in the next interview.