Five Whys
What the user gives you is the solution they could think of. Ask why several times in a row and you'll start to feel the reason that gave them the idea in the first place.
- 照着需求做了功能,用户还是绕着走
- 同一个模块反复被提需求,补了一个又来一个
- 功能列表越来越长,但没有一个从根上解决问题
"Five" is approximate — you don't have to hit exactly five. Most cases bottom out by the third level. The real rule: keep going until the answer is no longer "because the system doesn't support it" but becomes a business fact.
How to Drill Down
Each level down, shift what you're asking about from "the solution" to "the situation."
| 层 | 这一层在问什么 | 问出来的东西属于 |
|---|---|---|
| 第 0 层 | 他要什么 | 方案。多半是他见过的某个界面 |
| 第 1 层 | 他拿这个方案去干什么 | 任务。开始有场景了 |
| 第 2 层 | 为什么必须自己干这件事 | 缺口。系统在哪一步断了 |
| 第 3 层 | 为什么会有这个缺口 | 结构问题。通常是当初的信息架构没设计对 |
| 第 4 层 | 为什么当初这么设计 | 业务事实或历史包袱。到这一层可以停了 |
When to Stop
Three Common Misuses
- Ask the person, not the incident. Five whys in a row easily turns into an interrogation, and the other side starts playing defense. Switch to reviewing the day's events together, replacing "why did you do that" with "what was going on at that step."
- Only one chain. Real problems often have several parallel causes. If two causes show up at the second level, branch—don't force one chain to the end.
- Don't just do the bottommost one once you reach it. The root cause is often an architecture issue that takes months to fix. The right move is to get the root cause, then go back and pick a layer whose cost you can accept and solve that first.
Note for the AI
Having the AI drill down for you keeps you more neutral than doing it yourself — it won't defend your solution.
下面是一条用户提出的需求,以及我了解到的背景: 需求原话:[用户说的话] 背景:[你知道的场景、这个人是谁、他在做什么] 请扮演一个中立的产品顾问,帮我做根因分析: 1. 逐层往下追问,每一层给出你的推测和理由,最多五层。 2. 每一层标注:这是方案、任务、缺口、结构问题,还是业务事实。 3. 如果某一层可能有多个并行原因,请分叉列出,不要只选一条。 4. 最后给出三个不同层次的解决方向,各自标注改动成本 (小时级 / 天级 / 周级以上)。 5. 明确列出你在推测时用到的假设,哪些需要我去跟用户确认。 不要给代码,也不要给界面方案。
Point five is the key. It separates "this step is my guess" from "this step you told me," so you know what to ask about in the next interview.
