最大的陷阱，是把客户嘴上说的需求当成真问题

做企业产品，最大的陷阱，就是把客户嘴上说的需求，当成真问题。

会议开了三轮，流程图画得很完整，部门主管也把问题、功能和优先级说得头头是道。产品团队回去加班赶方案、做原型、排计划，几个月后系统上线，大家却发现真正干活的人不爱用，原来的问题也没有解决。

很多项目不是输在技术上，而是从一开始就把客户说的话，当成了客户真实的工作。

需求≠真问题

客户说的需求，只是他想到的解法

客户说想增加一个导出按钮，这只是他嘴上说的需求。真问题可能是，他每周都要从几个系统里导出数据，再花半天时间整理成领导需要的经营报表。

如果团队直接去做导出按钮，功能当然可以按时交付，但那半天的重复工作依然存在。只有继续追问他为什么要导出、导出以后要做什么、最终想得到什么结果，才有机会发现：他真正需要的不是一个按钮，而是一份能够直接支持经营判断的结果。

客户嘴上说的需求，很多时候只是他基于现有流程想到的解决办法；真问题，才是那个持续影响业务结果、迫使他不得不用这种办法应付的矛盾。

把这两者混在一起，需求响应得越快，项目反而可能偏得越远。

会议室里有一套流程，现场还有一套

主管描述的往往是组织希望大家怎么做；一线员工每天执行的，才是事情实际上怎么发生。这两套流程很少完全一致。

制度里可能只有五个步骤，实际操作中却夹着十几个临时判断：什么时候要绕开系统，什么情况要找人确认，哪个数据不能完全相信，月底和大促时又要换一套做法。这些内容通常不会出现在SOP里，也很少有人在正式会议上主动提起。

不是一线员工故意隐瞒，而是他们早已习惯了。

现场观察

所以，识别真问题的第一步，不是先找主管开需求会，而是坐到真正做事人旁边，看他完整地干一遍活。看他打开哪些页面，来回切换哪些表格，在哪一步停下来思考，什么时候找同事确认，又在哪个地方凭经验做了一个系统无法解释的决定。

听不懂不是尴尬，而是一个非常诚实的信号：你离真实业务还很远。

光看还不够，最好亲手做一次

旁观者看到的是步骤，操作者感受到的才是阻力。

一个按钮多点三次，看起来只是体验问题；可当它每天要重复几百次，就可能是一线员工最想摆脱的负担。一个数据晚十分钟更新，写在需求文档里似乎不严重；但如果它刚好影响当天的投放判断，后果就完全不同。

最有效的办法是把自己当成一个刚入行的小白，亲手把这项工作做一遍。自己开账户，自己上数据，自己跑流程，自己处理异常。直到能够和用户聊同一种语言，能够独立完成一次完整操作，能够真实感受到那些让人烦躁、犹豫和不安的时刻。

别急着写方案，先做一个能被批评的东西

人对着一张白纸，很难说清自己真正需要什么；但面对一个具体的东西，判断会立刻变得敏锐。

与其花几周写一份面面俱到的产品方案，不如先用合成数据做一个轻量原型。它不需要漂亮，也不需要功能齐全，只要能把关键流程跑起来，就足以拿到用户面前。

用户一上手，真实反应就会出现：这一步根本不会这么做，这个数据我们不敢直接用，这里少了一个确认动作，这个功能看起来方便，实际会增加工作量。

这些脱口而出的否定，比十份调查问卷更接近真相。

真问题，往往藏在奇怪的那一天

如果你问一线员工平时怎么做，得到的通常是一套整理过的标准答案。换一种问法，效果会完全不同：上周二下午三点，你当时正在忙什么？最近一次出问题是什么时候？月底、大促、人员请假时，这套流程会变成什么样？

真正有价值的问题，经常藏在这些不标准的时刻里。那些隔一阵子才出现一次、每次只耽误二十分钟、从未被写进正式材料的怪情况，往往决定了系统到底能不能真正替用户接住工作。

看起来不合理的地方，未必需要被改掉

有些看起来低效、奇怪甚至错误的操作，并不是漏洞，而是一线人员在长期实践中形成的业务经验。它也许是在规避某种风险，也许是在适应平台规则，也许是在平衡多个目标之后做出的现实选择。

这时候最重要的不是马上改，而是多问一句：为什么要这样做？

分不清真问题和客户的合理选择，越努力，越可能把客户原本有效的经验优化掉。

五个检验问题

最后，拿五个问题检验一下

在决定投入开发之前，不妨再问自己五遍：

1. 这个问题能不能落到时间、成本、收入、风险或质量等具体结果上？

2. 它是一线用户亲身经历的，还是主管转述的？

3. 团队有没有亲手验证过它确实存在？

4. 有没有排除它其实是客户合理选择的可能？

5. 解决以后，价值是否足够大，并且能够明确归因？

五个问题都能回答清楚，再谈产品、开发和交付，成功率会高很多。

企业服务里最稀缺的，从来不是一个会写方案的人，也不是一个能快速做出系统的人，而是一个愿意蹲在现场，把客户的工作真正学会，再分清什么该改、什么不该改的人。

客户嘴上说的需求，当然要听，但不能听完就做。

真正的问题，不是客户在会议室里告诉你的那句话。它藏在用户每天重复的动作里，藏在没有写进SOP的经验里，藏在那些被所有人习惯、却从未被认真看见的麻烦里。

当我们不再急着证明自己懂技术，而是先努力听懂客户，产品才真正开始。