问题比答案值钱：把模糊抱怨改写成可解的问题

「这个流程太麻烦了」「用户说不好用」「感觉留存不行」——这类句子每天都在会议室出现，它们听起来像问题，实际上只是情绪。真正的起点不是找答案，而是先把抱怨改写成可以被回答的问题。改写做得好，答案往往自己浮出来。

抱怨与问题的差别

抱怨描述的是感受，问题描述的是差距。差别只有一处：问题里必须有一个可比较的基准。说「太麻烦」的时候，麻烦是相对什么说的？相对竞争对手、相对上一次版本、还是相对用户心里的预期？基准不同，解决方案完全不同。

• 抱怨：注册流程太长
• 问题：新用户在注册页停留中位数 96 秒，其中 41% 在手机验证码这一步离开，而竞品的中位数是 35 秒

后者不一定要写这么多字，但它必须包含三个要素：对象、差距、可验证的度量。

改写的三个动作

一、问「具体是哪一次」

把抽象的「用户觉得慢」落到一次具体的使用上：哪个人、在什么时候、做什么操作、等了多久、当时在什么环境里。一次具体经历胜过十句概括评价，因为具体经历里藏着条件。

二、找出参照物

人不满意，永远是拿某样东西在比较。参照物可能是竞品、上一份工作里的系统、线下流程、甚至是想象中「本该如此」的样子。问出参照物，才知道要追的是速度、是确定性，还是控制感。

三、给一个能证伪的指标

把问题写成一句可以被数据推翻的话：「如果在结果页加一句预计完成时间，电话咨询量会下降三成」。能被证伪，才有资格进入排期；不能被证伪的，只能算愿望。

一个定义清楚的问题，已经完成了解决方案的一半。反过来，定义不清的问题会让团队反复做正确的事，却始终解决不了真正的问题。

问题陈述卡

团队里可以统一用一张三行的卡片：

• 谁：在什么场景下
• 现在的差距：现状 ____，期望 ____，差距 ____
• 怎么算解决：指标从 ____ 到 ____

三行写不满，说明还没到讨论方案的阶段。这张卡还有一个副作用：当有人带着方案来开会，先要求他补这张卡，很多方案会在这一步自己消失——因为它们服务的其实是提出者的焦虑，不是用户的问题。

为什么这件事反直觉

大多数团队的激励偏向「给答案」：谁能立刻提出方案，谁显得能干。定义问题的人往往在会议里显得缓慢、啰嗦、不产出。于是问题定义这一环长期缺失，团队在错误的方向上高速前进。

把评价标准从「谁先给出方案」改成「谁先把问题说清楚」，是成本最低的一次组织改造。它不需要新工具，只需要主持人在每次讨论开始前多问一句：我们要解决的问题，一句话是什么？