当用户说'想要一匹更快的马'时，福特造出了汽车——这个经典案例背后藏着需求挖掘的关键密码。本文将拆解需求的三个层次：表述层、场景层和动机层，揭示99%的产品经理都忽略的追问技巧，教你用'您现在是怎么做的'这一句话，挖出用户都说不清的真正痛点。

有个经典段子：用户说想要一匹更快的马，福特直接造了汽车。这个故事被无数产品课引用，结论往往是”用户要的不是马，是更快的到达方式”。

但我今天想说的不是这个。

我想问的是：福特听到”要一匹更快的马”这句话之后，他做了什么？

大多数人只记住了结论，却忽略了过程。福特不是听到了这句话就原地造车，他做了一件事——追问这个需求背后的人，在什么场景下，说出了这句话。

这是一个产品经理最重要的习惯，但99%的人都在假装自己有。

你采集到的”需求”，很可能只是一个抱怨

我们来做个小测试。打开你的需求池，搜索”用户说””用户反馈””用户希望”这样的关键词，然后仔细看每一条记录。

你会发现一个有趣的现象：大部分所谓的”需求”，长这样——

• “用户希望页面加载更快”
• “用户希望功能更简单”
• “用户希望能导出数据”
• “用户希望操作步骤少一点”

这些话对吗？对。有用吗？不太有用。

因为它们都是表述，不是问题。”页面加载更快”是多久？现在的加载时间是3秒还是8秒？用户是在什么场景下觉得慢的？是付款页还是首页？是WiFi下还是地铁里？

没有这些信息的”需求”，就像医生没问你哪里疼、多久疼一次、疼之前吃了什么，就直接开药。

你说这药能对症吗？

需求的三个层次，你卡在哪一层

我观察过很多产品经理做需求采集，发现一个规律：大多数人的采集深度，停留在第一层。

第一层：表述层。用户说什么，我记什么。”用户说想加一个批量操作功能”，ok，记下来。

第二层：场景层。追问用户为什么会有这个需求，在什么场景下遇到这个问题。这个批量操作是什么场景下需要的？一天操作几次？每次操作多少条数据？手动一个个点要多久？

第三层：动机层。这个需求背后，用户真正想解决的是什么问题？是效率问题？是安全感问题？还是他只是想”不被领导骂”？

很多产品经理卡在第一层，觉得记下来就算完成任务了。然后到了评审会上，被技术问”这个需求解决什么问题”的时候，开始磕磕巴巴地复述用户的原话，技术一脸问号——所以你加这个功能是想解决什么？

这不是技术不懂产品，是产品经理自己也没想清楚。

追问的技巧，比你想象的简单

有人说，我知道要追问，但追问好难啊，用户不配合怎么办？

其实追问的技巧很简单，就一句话：不要问“您想要什么”，要问“您现在是怎么做的”。

“您想要什么”是开放式问题，用户只能用他们有限的经验来想象解决方案，然后给你一个”更快的马”。

“您现在是怎么做的”是描述性问题，用户会开始回忆自己的操作流程，然后你就能发现那些他自己都没意识到的痛点。

举个例子。用户说”我想导出数据”，你追问”您现在是怎么导出的”，他可能会说”我每天要从系统里把订单数据复制到Excel，然后手动整理”。

你看，这句话里藏着多少信息：每天都要做、要做数据整理、可能涉及多个字段、这是重复性工作。这些信息，用户在”我要导出数据”这句话里，一个字都没提。

但如果你不追问，你永远不会知道。

一个让你停止假装采集的反向思考

说了这么多正向的方法，我想泼点冷水。

追问能力再强，也救不了一个根本不愿意花时间做采集的产品经理。

我见过太多这样的情况：产品经理知道要追问、知道要深挖、知道要做用户访谈，但业务方催得急、自己也觉得”差不多就行”，然后就按第一层需求直接上了。

结果呢？做完了发现不对，改。改完了还是不对，再改。一个功能反复折腾三四轮，技术骂产品不靠谱，产品委屈说需求变了。

需求没变。是你从一开始就没对。

所以这篇文章不是一篇”技巧大全”，而是一面镜子。如果你能对照自己过去的需求文档，发现自己大部分记录都停在表述层，那今天的文章可能对你来说就值了。

从下一次采集开始，试着多问一句”您现在是怎么做的”。

可能只是这一句话，就能省掉你后面积累的几次返工或者可以让你的需求设计以及评审更加顺畅。

写在最后，做个小总结吧

• 核心观点：产品经理的本质是”翻译”——把用户困惑翻译成产品语言。
• 深一层：需求采集不是机械动作，而是”持续在场”的理解姿态。
• AI时代：真正差距在于谁能比用户更早发现问题。
• 落点：做到这一点，靠的不是技术，是愿意蹲下来倾听。