用户说的“需求”，为什么不能直接做：从原话追问到真实场景

假设你刚入行，接到第一个需求：运营同事转来一条用户反馈——“希望 App 支持批量导出数据”。你很自然地开始想：导出哪些字段、导出成 Excel 还是 CSV、一次最多导多少条。

这些问题的答案都拿不到，因为它们问早了一步。用户给你的这句话里，混着三种东西：他想要达到的结果、他当时的处境，以及他自己想出来的一个解决办法。而 只有前两种才是真正的问题，第三种是可以被替换的。批量导出只是他此刻能想到的解法之一——也许真正让他难受的是每天要花四十分钟手工复制数据，而这个痛苦完全可能用别的方式消掉。

这一篇要解决的就是这个动作：拿到一句原话之后，怎么往下追，才追到那个“真正要解决的问题”。

先拆掉一个流传很广的说法

“不要听用户的，因为他们只会要一匹更快的马。”这句话被挂在亨利·福特名下，用来证明用户的话不可信。

问题在于，福特很可能没说过。Quote Investigator 追溯到的可靠出处只能到 20 世纪后期的其他人，最早把这句直接归给福特的印刷文字出现在 1999 年之后3；福特博物馆维护的一份约两百条经核实的福特语录里也没有这一条4。

这个澄清有用，不是咬文嚼字。如果把这句当作“用户的话基本没用”，你会走向另一个极端：完全不问用户，凭自己猜“他们真正想要的是汽车”。真实情况温和得多——用户的话是有用的信息，只是它是原料，不是结论。用户最清楚自己的处境和代价；而“应该用什么方案解决”，通常是你比他更该判断的事。

用户为什么说得不准

不是他有意骗你，有三个机制在同时起作用。

第一，他汇报的是自己脑子里的解释，而不是真实的决策过程。心理学里一篇被反复引用的研究（Nisbett 和 Wilson，1977）指出，人对影响自己判断的过程并没有直接的内省通道，被问到“你为什么这么做”时，给出的答案往往只是一个听起来合理的因果说法5。所以他说“我想要批量导出”，可能只是他记得自己上周抱怨过导出这件事，而不是他真的最在意它。

第二，问题本身会引导答案。你问“你觉得这个功能有用吗”，礼貌和场面会替你回答“有用”；你问“如果做出来你会用吗”，他只能预测一个还不存在的自己，这种预测向来不准6。

第三，他的注意力停在表面。他记得的是那次操作很烦，不会自动帮你拆出“卡在哪个环节、几点、在哪台设备上、当时还有谁在等”。

一个被讲过无数遍但值得重新听的例子

哈佛商学院的克莱顿·克里斯坦森常讲一个快餐连锁店改奶昔的故事1。这家店的奶昔销量上不去，做法很标准：先按产品分层，再按人口统计画用户画像——典型奶昔消费者大概是什么年龄、什么性别；然后请符合画像的人来评价“理想的奶昔该更稠还是更稀、要不要加果粒”。他们诚实回答了，产品照着改了，销量没动。

后来一位研究员换个方式：在店里坐一整天，记录每杯奶昔是什么时候卖的、顾客是不是一个人、有没有买别的东西、是不是带走喝。结果 40% 的奶昔在早上卖出去，顾客几乎都是独自一人、只买一杯、开车带走。第二天他在门口拦人问：你雇这杯奶昔来干什么活？

答案很一致：他们面对一段又长又无聊的通勤，需要让空出来的那只手有点事做；人还不饿，但知道十点会饿，想现在吃点东西撑到中午。约束是：赶时间、穿着上班的衣服、最多空出一只手。香蕉撑不到中午；贝果配奶油奶酪会弄脏手和方向盘；甜甜圈过了十点就顶不住。奶昔要用细吸管吸二十分钟，手是干净的。所以更好的改法不是“更健康”，而是更稠（撑更久）、加果粒（吸到果粒有点意外感）、把机器挪到柜台前、卖预付费卡让人快速进出。而给孩子当奖励那个场景的用户，面对同一个产品、同一个柜台，却需要一杯更稀的——因为家长不想站在那儿等半小时。

这个故事里最值钱的不是“奶昔”，而是它换了一种问法：不是问“谁在买”，而是问“在什么处境下，他要完成什么”。前一种问法只能给你改进规格的线索，后一种问法才告诉你真正要竞争的对象是谁——在这里是香蕉、贝果和无聊的通勤时间，而不是别家店的奶昔。

（顺带说一句，这个例子本身也有争议：有研究者认为把任务定义成“打发无聊的通勤”定得太宽，更准确的应该是“在开车路上解决早饭”2。分歧在任务该切多细，但两边都同意同一件事：先搞清处境和目标，再谈产品规格。）

怎么问：把话题从未来拉回过去

Rob Fitzpatrick 在《The Mom Test》里给的三条规则，是这套追问最好用的操作版7：聊他的生活，别聊你的点子；问过去的具体事件，别问泛泛的看法和对未来的预测；自己少说，让他多说。

对应到提问上，是这样一组改写：

关键在最后一行。用户开口就要功能时，不要立刻评价这个功能好坏，而要问：你现在是怎么凑合的？ 那个“笨办法”指向的，才是他真正在对抗的限制。有人每天手工复制五百行，有人让实习生定时跑脚本，有人干脆放弃这项分析——同一句功能愿望背后，是三种完全不同的问题。

追问时手上有四条比较硬的线索：具体时间（哪一天、几点）、数量（多少条、多少分钟）、已经付出的成本（钱、外包、加班）、以及当时的情绪（他抱怨的是烦、是怕出错，还是怕老板看见）。能落到具体数字和日期的描述，比“经常会遇到”有用得多。

一条完整的追问链是这样：原话 → 上一次发生是什么时候 → 当时你怎么处理的 → 代价是多少 → 你想要的最终是什么样 → 什么条件下你才认它算解决了。走到最后一步，你就得到了一个能拿去做判断的问题陈述：谁、在什么情境下、想完成什么、现在被什么挡住、代价多大。而“批量导出”在这条链里只是候选方案之一，可能被砍掉，也可能被换成“每天自动把报表发到你邮箱”——前提是后者更接近他真正要的结果。

什么时候可以不再追

追问不是无限循环，有两种情况可以直接接受原话。

一种是，用户说的本来就是规则或约束，不是方案。比如财务说“发票必须带税号”，这是外部世界的硬条件，不需要追问动机，照做。

另一种是，跟你说话的人既是用户也是付款方，而且他明确说了要什么。企业客户说“我们要 SSO 登录”，这本身就是待交付的东西；你可以追问动机（是为了过安全审计，还是 IT 部门的统一要求），因为它影响实现方式和优先级，但不必推翻他的诉求。

反过来，最该警惕的恰恰是“只有一句功能描述、没有场景、没有代价”的需求。它可能来自用户，也可能来自老板或一张竞品截图。判断它值不值得做，靠的是能不能把它还原成一个具体的处境。

这也接得上上一篇的结论：产品经理认领的是“这件事对用户有没有价值”这一类风险。而“有没有价值”不是靠拍脑袋，也不是靠把用户的原话照抄进文档——它靠你能不能把原话翻译成“谁、在什么处境下、要完成什么、代价多大”。这一步没做，后面画的原型再漂亮，也只是在给别人想出来的解法做美化。

两个练习，先自己写再看提示

用户说：“你们这个搜索太烂了，能不能加个高级筛选？”

提示：追问“上一次你搜不到东西，是在找什么？后来怎么办的？”——可能发现真正的问题是搜索结果排序（根本找不到），也可能是筛选条件没地方保存（每次重来）。高级筛选只是候选方案之一。

用户说：“希望支持微信登录。”

提示：不要问“你想不想用微信登录”，而要问“你上次注册别的产品时，最后用的是哪种方式？为什么不继续用那个？”——如果答案是“记不住密码、每次都要重置”，那么要解决的是记忆负担，可能靠一次性验证码就够了，不一定非要接微信。