问题定义：用 5W2H 把「感觉有问题」变成可处理的问题
多数讨论卡住，是因为每个人说的「问题」不是同一件事。先用 5W2H 对齐对象、时间、范围和判断标准。
结论先行：定义问题的产出应该是一句可验证的描述：谁、在什么场景、出现什么现象、用什么标准判断它被解决。
工作中常见的场景是：会上有人说转化不行、协作不畅，然后大家开始各自动员经验，讨论半小时仍没有结论。原因往往不是没人有想法，而是问题本身没有被定义。不同的人在心里替换了不同的对象、时间和标准。
5W2H 的七个问题
| 维度 | 要问什么 | 示例 |
|---|---|---|
| What | 现象是什么 | 新用户注册后 24 小时内流失 62% |
| Who | 影响哪些人 | 首次使用的新用户，不含老客 |
| When | 从什么时候开始 | 从 10 月改版后开始 |
| Where | 在哪个环节 | 注册成功页到首页之间 |
| Why | 为什么值得解决 | 影响次月留存与付费转化 |
| How | 怎么衡量解决 | 7 日留存提升到 35% |
| How much | 投入多少 | 两周开发，一个人力 |
把描述改成可验证的句子
转化不好无法验证，注册后 24 小时内流失 62%、高于上月的 48% 则可以验证。定义问题时，尽量把形容词换成数字、时间范围和对比对象。没有数据时，至少写清观察到的具体现象和出现频率，例如「每周至少三次收到同类投诉」。
定义之后先确认边界
- 哪些不在这次范围内：例如只处理新用户，不改老客流程。
- 哪些是已知约束：人力、时间、不能改动的系统。
- 谁来判断问题是否解决：一个人，而不是一个委员会。
边界不清，讨论会不断扩张。把不做什么写下来，和写做什么同样重要。边界还能防止一种常见情况：方案讨论到一半，有人提出另一个更根本的问题，会议因此失焦。
从模糊到可处理
一段 5W2H 定义
- 原始说法：最近客服压力很大，体验不好。
- 定义后：10 月以来退款类咨询占比从 18% 升到 31%，平均处理时长 26 分钟，主要集中在退款进度不透明。
- 范围：只处理退款状态展示，不改退款审核规则。
- 衡量：咨询占比降到 20% 以下，处理时长降到 15 分钟以内。
常见误区
- 把方案当问题：我们需要一个数据看板其实是方案，问题可能是看不到渠道效果。
- 把现象当原因：响应慢是现象，原因可能是排班或工具。
- 范围过大：一次想解决整个体验，通常什么也改不动。
一个快速检验： 把问题描述读给不在项目里的同事听，如果他能在三十秒内说出「那要解决的是不是某件事」，说明定义基本清楚；如果他要反问三个问题，说明还需要补 5W2H。
定义问题大约占整个解决过程的三成时间，但它决定了后面七成的方向。宁可多花半小时对齐，也不要在错误的问题上高效执行。