立即登录 挖掘用户需求是产品经理的日常功课，但真正挖到点子上的人并不多。需求不是凭空产生的，关键要看它能否为用户创造价值，为产品开发带来实际意义。尤其对B端SaaS而言，客户成功团队需要持续输出服务，产品体验必须过硬，这就要求产品经理真正沉到用户的场景里去。
B端和C端有个天然差别：做C端产品，产品经理自己就是用户，既能当教练也能下场当运动员，产品好不好用自己门儿清。但B端不一样，你做的财务系统、CRM、供应链工具，自己日常根本用不上。客户场景看不到全貌，需求挖掘就成了实打实的挑战——怎么挖出客户真正的痛点？怎么以解决方案专家的身份跟客户对话？有没有可能跳出惯常套路，让思考更清醒一些？
最近重读赫克托·麦克唐纳的《后真相时代》，书里从多个维度拆解案例，还原人们对"真相"的认知方式。这让我想到，客户需求这件事，是不是也可以用类似的框架来理解？我试着把书中关于真相的认知维度，对应到B端SaaS的需求挖掘上，或许能搭一个更合理的判断框架。以下从片面真相、主观真相、未知真相三个层面展开。
---
客户需求的片面真相
跟客户聊需求，对方说的每句话可能都是真的，但合起来未必是完整图景。信息经过层层过滤才到你手里——决策者关心投入产出，采购部门在意合规和预算，一线员工只在乎好不好用。企业B端SaaS里，这三者说的需求往往天差地别。
盲人摸象的寓言谁都听过。每个人站在自己的位置，摸到的确实是真切的局部，但离"大象"的全貌相去甚远。这种片面性从何而来？
背景变迁催生需求。 我们对需求的理解，很大程度上取决于当下场景。疫情期间的远程办公就是个典型例子——协同软件突然要扛住全员居家，"云办公"从锦上添花变成刚需。那些功能以前没人要吗？未必，只是环境变了，需求的紧迫性完全不同。类似的，政策调整、行业周期、组织架构变动，都会让同一类需求从边缘走向中心。
需求的复杂性被低估。 B端产品经理不在客户现场泡着，很多隐性需求根本看不到。客户提了个"简单"的报表需求，真做起来才发现要对接三个系统、清洗七种数据格式、适配两套权限体系。这种复杂性不是客户故意隐瞒，而是他们自己也没意识到。
数据的客观性陷阱。 数字不会说谎，但筛选数字的人会。同样的业务数据，按月度汇总和按周拆解，呈现的"真相"截然不同；包含退货的GMV和剔除后的净收入，导向完全相反的决策。产品经理得警惕：数据字段是真实的，解读方式却可能把你带偏。
---
客户需求的主观真相
当你向团队描述"这个功能客户非常需要、非常有价值"时，其实已经掺入了主观判断。你或许听过太多"我认为""我觉得"，甚至不自觉替客户脑补需求，把"我觉得他们会用"当成"他们确实需要"。
主观真相的可贵之处在于它会流动、可被重塑；危险之处也在于此——需求的对错，有时取决于谁在说、怎么说。
怎么尽量逼近真实？一是扩大样本量，单个客户的强烈诉求可能是孤例，十个客户的相似反馈才构成值得投入的信号。二是时刻锚定商业场景，脱离具体业务语境谈需求，很容易把"我想做"包装成"客户想要"。别替客户预设那些尚未发生的极端场景，先把眼前跑通的流程吃透。
---
客户需求的未知真相
还有一类需求，产品里暂时没实现，甚至市场上还没验证过——这就是规划型需求。在产品落地之前，你无法用结果倒推它是否正确；但只要市场逻辑自洽、客户痛点真实存在，它就具备"真相"的潜质，等待被证实或证伪。
B端客户往往会基于业务预判提出前瞻需求。一家准备出海的企业，可能要求CRM提前支持多币种结算和时区适配；一个计划拓展下沉市场的品牌，会需要门店管理系统预留加盟模式的扩展接口。这类需求紧密绑定客户的战略走向，产品经理的行业理解深度，直接决定了能不能接住话、接对话。
这里有个判断锚点：如果业务发生在已验证的存量市场，客户的历史数据和既有路径能为需求提供事实支撑；如果瞄准的是增量市场，那就更考验产品经理的洞察力和试错勇气。说到底，需求从客户中来，但最终的提炼和升华，得高于客户的即时表达。
---
需求挖掘的方法论市面上已经很多，本文尝试换个视角——从真相的三种形态切入，帮产品经理建立更立体的分析框架。核心目的只有一个：在用户需求、使用场景、业务逻辑和产品规划之间，找到经得起推敲的联结点，少踩"伪需求"的坑。
B端产品经理既要像教练一样把控方向，也得比教练走得更深，去触摸客户真实的业务肌理。每一个需求都值得被审视：它来自谁、在什么背景下、服务于什么目标、有没有被过度加工。保持这份警觉，需求的真伪自然会浮现出来。