在B端SaaS领域，挖掘客户真实需求从来不是一件容易的事。B端产品经理往往不是产品的直接使用者，这种身份差异本身就带来了一堵无形的墙。和客户沟通时，接收到的信息经过层层转述和筛选，常常已经偏离了需求的本质。

《后真相时代》的作者赫克托·麦克唐纳提供了个挺有意思的视角：真相并非非黑即白，而是存在着片面真相、主观真相和未知真相三种形态。这个框架恰好可以用来重新审视B端需求挖掘的困境与破局之道。

片面真相：被筛选过的需求信号

和客户访谈时，一个容易被忽略的问题是：即便对方说的每句话都是真的，但由于角色立场不同，我们接收到的往往只是经过筛选的局部真相。



企业采购SaaS产品时，决策者、需求提出者和实际用户可能是三个完全不同的人。决策者关心成本和投资回报，需求提出者在意功能能否满足现有业务流程，实际用户则在乎操作体验是否顺手。这三者的诉求往往存在张力，而产品经理作为外部介入者，接触到的信息本质上已经被各方的角色视角过滤了一遍。

有句话叫盲人摸象。每个利益相关者都只摸到了大象的某个部位，得到的都是真实的局部，但拼在一起却未必是完整的大象。

造成这种片面性的原因是多方面的。

首先是场景依赖。需求往往依附于特定的业务背景，背景变了，需求的合理性也会跟着变。疫情期间远程办公需求的爆发就是个典型例子——在线协同软件在疫情前已经存在，但居家办公这个新场景一下子激活了大量原本被忽视的功能需求。这些需求并非凭空产生，而是被特定环境激发出来的。

其次是需求本身的复杂性。B端产品的使用场景通常涉及多个角色、多条业务流程，产品经理不可能时刻泡在客户实际使用环境中。这就导致很多隐性需求难以被直接观察到。比如客户提出一个看似简单的报表导出需求，背后可能涉及数据权限分级、格式兼容、自动化定时任务等一系列关联要素。产品经理如果不深入追问，很容易陷入头痛医头的被动局面。

第三是数据的迷惑性。很多产品经理迷信数据，认为只要数据是真的，结论就客观。但数据呈现本身具有很强的主观性。同样是用户活跃数据，日活、周活、月活三个维度可以讲出完全不同的产品故事。客户提供的统计数据往往带着他们自己的解读逻辑，这种解读可能是有意的筛选，也可能是无意的偏差。

主观真相：被建构的需求判断

当产品经理判断某个功能需求“有价值”“有吸引力”时，实际上已经进入了主观真相的范畴。主观真相的核心特征是：它可以被建构，也可以被改变。

在需求挖掘过程中，最常见的主观陷阱有两个。

一是“我认为客户需要”。产品经理基于自己的使用习惯或行业经验，替客户做了需求判断。这种替代思考的危险之处在于，它混淆了“产品经理认为有价值”和“客户真正需要”这两个完全不同的命题。

二是预设商业场景。很多需求在被验证之前，都存在于假设之中。产品经理可能会构建一个看似合理的商业场景，然后基于这个场景推导需求。比如“客户应该有批量处理的需求”“企业用户肯定需要权限管理”。这些推断可能有道理，但也可能只是一厢情愿。

应对主观真相的方法需要回到商业本质。样本取样是必要的，但关键不在于数量，而在于样本是否覆盖了真实的决策链条。如果只访谈了最终用户，可能会错过采购决策的关键考量；如果只和决策者沟通，又可能忽略实际使用中的痛点。更重要的是，不能脱离具体的商业场景谈需求。任何需求都生长在特定的业务土壤里，土壤不同，需求的价值就不同。

这里有个值得警惕的认知偏差：产品经理很容易把自己的需求误认为客户的需求。这在经验丰富的资深产品经理身上尤其容易发生——因为太熟悉产品，反而失去了对普通用户视角的敏感度。

未知真相：面向未来的规划需求

相比前两类需求，未知真相有些特殊。它更多指向产品规划层面，是尚未实现的功能构想。在产品真正做出来之前，这些需求无法用市场结果来验证对错。

B端客户经常会基于自己对行业趋势的判断，提出一些前瞻性的需求。比如“明年我们可能要开拓海外市场，你们的全球化能力准备好了吗”“未来合规要求可能会更严格，你们的数据安全体系需要提前布局”。这些需求背后是客户对自身业务发展的预判，SaaS厂商需要判断这些预判的可靠性，以及自己的产品路线图是否应该与之对齐。



这类需求的验证逻辑取决于市场阶段。如果是已经被验证的存量市场，客户的需求往往有事实支撑，产品经理需要做的是把需求翻译成产品语言。如果是尚未被验证的增量市场，产品经理的行业洞察力就变得至关重要。需求来自客户，但要高于客户——这要求产品经理不仅能够准确记录客户表达的内容，还要能够从中提炼出普适性的产品机会。

回归需求的本质

回到开头的问题：如何跳出传统方法，更理性地思考客户需求？

片面真相告诉我们要警惕信息的局部性，尽可能还原需求的完整背景；主观真相提醒我们需求判断容易被主观因素影响，需要用样本和场景来校验；未知真相则要求我们在规划层面保持开放的同时保持审慎。

B端产品经理的角色很有意思，既要像教练一样指导需求方向，又要像学生一样保持对客户业务的好奇心。需求挖掘不是一次性的信息采集，而是持续的理解与验证过程。那些看似明确的需求背后，可能藏着没被说出口的顾虑；那些看似超前的规划，可能只是竞争对手制造的焦虑。

最终，一个合格的需求判断框架，应该能够帮助产品经理在信息的迷雾中找到方向：不轻信单一信源，不被自己的经验绑架，也不被未来的不确定性吓退。这种能力的养成，需要不断在实践中校验自己的判断，也需要对行业的持续深耕。