五个为什么 | 发现问题 | 做产品
五个为什么
用户给的是他能想到的解决办法。连着问几次为什么，你才会摸到那个让他产生这个想法的原因。
你会遇到的现象
-
照着需求做了功能，用户还是绕着走
-
同一个模块反复被提需求，补了一个又来一个
-
功能列表越来越长，但没有一个从根上解决问题
「五个」是个约数，不是必须问满五次。多数情况下问到第三层就见底了。真正的规则是：一直问到答案不再是「因为系统不支持」，而是变成一个业务事实为止。
怎么追
每往下一层，问的对象要从「方案」转向「处境」。
层这一层在问什么问出来的东西属于 第 0 层他要什么方案。多半是他见过的某个界面 第 1 层他拿这个方案去干什么任务。开始有场景了 第 2 层为什么必须自己干这件事缺口。系统在哪一步断了 第 3 层为什么会有这个缺口结构问题。通常是当初的信息架构没设计对 第 4 层为什么当初这么设计业务事实或历史包袱。到这一层可以停了
越往下，能解决的问题越根本，但改动成本也越高。所以追到底之后，还要往回走一步，选一个成本合适的层次下手。
每往下一层，问的对象从「方案」转向「处境」
「要一个批量导出按钮」 方案
为什么？——每周要向老板汇报
为什么手动抄？——系统里的口径和汇报口径不一样
为什么不一样？——两边是不同部门定的 处境
改动成本 同时在涨 这层可能 产品改不动
追到底之后 再往回走一步，选一个成本合适的层次下手 停止的信号只有一个：答案不再是「因为系统不支持」，而是变成了一个业务事实。
这张图解释了为什么「追到底」本身不是目的。越往下能解决的问题越根本，但改动成本也越高——最底层往往是组织和流程的事，产品动不了。真正的收获是中间那一两层。
什么时候停
可以停了
· 答案变成了一个业务事实 · 答案指向了组织或流程，产品改不动 · 再往下问，答案开始重复 · 已经能推出一个跟原诉求不同的方案
还没到底
· 答案还是「因为系统不支持」 · 答案还是另一个功能名 · 答案是「大家都这么做」 · 你还说不出他那天到底卡在哪一步
右边第一条最常见。「因为系统不支持」等于什么都没说，它只是把问题换了个说法，再问一次就能往下走。
三个常见误用
-
**对着人问，不是对着事问。**连问五次为什么很容易变成质问，对方会开始防守。改成一起复盘那天发生了什么，用「那一步是怎么回事」代替「你为什么这么做」。
-
**只有一条链。**真实问题往往有几个并行原因。追到第二层时如果出现两个原因，就分叉，别硬挑一条走到底。
-
**追到底就直接做最底下那个。**根因往往是架构问题，改起来要几个月。正确做法是拿到根因之后，回头挑一个成本能接受的层次先解决。
给 AI 的话
让 AI 帮你追问，比你自己追更容易保持中立——它不会替你的方案辩护。
复制 PROMPT · 追根因 下面是一条用户提出的需求，以及我了解到的背景：
需求原话：[用户说的话] 背景：[你知道的场景、这个人是谁、他在做什么]
请扮演一个中立的产品顾问，帮我做根因分析：
- 逐层往下追问，每一层给出你的推测和理由，最多五层。
- 每一层标注：这是方案、任务、缺口、结构问题，还是业务事实。
- 如果某一层可能有多个并行原因，请分叉列出，不要只选一条。
- 最后给出三个不同层次的解决方向，各自标注改动成本 （小时级 / 天级 / 周级以上）。
- 明确列出你在推测时用到的假设，哪些需要我去跟用户确认。
不要给代码，也不要给界面方案。
第五点是关键。它会把「这一步是我猜的」和「这一步是你告诉我的」分开，你就知道下次访谈该去问什么。
接着看
用户访谈怎么问 追问的四把铲子在那一篇。这里的五层是「那次为什么这么做」这一把往深里挖的版本。
什么是需求 第 0 层到第 1 层的跨越，就是从「他说的话」到「他真正要的」。
数据模型先行 追到第 3 层经常会发现是数据没建对。那一篇讲怎么在开工前就把实体和关系定清楚。