当用户不是客户，需求价值怎么定？

摘要：

产业互联网时代，数字产品的商业模式日趋复杂：B2B、B2B2C、C2B、多边平台等等，客户和用户分离是非常常见的。虽然价值驱动需求是共识，但在复杂模式下，如何确定需求价值，如何做优先级决策，却是知易行难。一些思考，抛转引玉。

如果说起产品管理的痛点，大多数人都会提到“确定需求的价值，为需求排优先级”。[《产品领导力》](https:

/productleadershipbook.com/)一书的作者Richard Banfield所做的调研也显示了这一点——产品管理者最大的苦恼就是对需求排优先级。其中特别提到，对于企业产品管理者，这个烦恼更甚。

（图1 令产品领导者夜不能寐的烦恼）

直觉上，对需求排优先级，不就是按价值排就好了吗？事实却是，知易行难。产业互联网时代，相对于To C产品为主流的互联网时代，有B2B、B2B2C、C2B、多边交易平台等不同形态的数字产品，其商业模式更为复杂。产品的客户和用户往往是分离的，需求价值的判断、优先级决策就更加困难。

当用户不是客户，到底该如何理解价值？需求的价值该如何确定？优先级如何权衡？这些问题，有必要深入探讨。

1. 什么是客户？什么是用户？

（图2 谁是客户，谁是用户）

通常来说，我们定义客户为“为产品或服务直接或间接付费买单的人”，定义用户为“产品的最终使用者”。如果仔细说来，有两个有趣的问题值得探讨：

1、是否只有直接以金钱方式向产品付费的才是客户呢？

现如今有相当一类数字产品，作为用户，我们不是直接付费的。典型的如游戏类应用、社交媒体类应用，比如绝地求生游戏和微信。当前微信和企业微信对个人用户、企业用户都不收费。这里有两种看法：一种认为只要不收费、就不能算作客户；一种则认为虽然没有直接付费，但却天天在微信上花了这么多时间，算是一种隐形的投入，应该算作客户。个人倾向于后一种，因为这就是产品存在的价值所在。

2、产品的用户，一定会是客户吗？

在大部分的消费者产品（C端产品）模式下，使用产品的人往往也是买单的人，即客户同时也是用户。但在面向企业的产品（B端产品）模式下，客户和用户是分离的；而在不断涌现的平台业务模式下，客户和用户的关系则更为复杂。

（图3 复杂商业模式下，产品客户和用户是分离的、且动态变化的）

从上面列举的这些例子可以看出，在复杂的商业模式下，数字产品的客户和用户可能是分离的、且动态变化的。

2. 客户问题和用户问题

在面向消费者的产品中，大多数情况下，客户和用户同一个体，那么通常我们认为用户的问题无非是马斯洛需求层次模型中的某一种。我们在构建产品时，会紧紧围绕着用户的这种诉求。

（图4 消费者用户的需求 – 基于马斯洛5个需求层次）

但当客户和用户分离的时候，客户问题和用户问题也会出现偏离。以最常见的儿童教育类产品来说：

家长作为客户，提出直接的诉求是“促进孩子学习、孩子的能力得到提升”和“不要太贵”，评价的标准是“孩子的成绩有没有提高，孩子的表现有没有比同龄孩子好”，本质的诉求是“安全层次的需求”。
孩子作为用户，本质上的诉求是“好玩，像玩游戏一样”的体验，以及能得到表扬、有成就感。既不关心价格，也不关心成绩（可能会在父母的压力下关心成绩，但不是发自内心的关心）。本质上的诉求则在爱与归属、尊重感等更高层次的需求。

对于B端产品来说，偏离情况就更严重了。如果做过B端产品的运营，你一定觉得下面的场景特别熟悉：

系统支持邮箱里面有上千封的用户反馈。一些使用系统数年的用户会提出各种类型的用户界面改进需求，以使他们在日常工作中更有效或更有效率。一些新用户会抱怨说找不到各种功能的入口，要求产品提供更详尽的上手指引。一些用户觉得放在左下角的标签栏特别好用，一些用户觉得那个一点用都没有，抱怨说“真不知道那个丑丑的标签栏有啥用”。有的用户说以前的界面主题设置真好看，新版界面丑死了；另外一些用户说“还是新界面清爽”……

这多多少少反映了用户关心的问题，虽然问题根因可以挖掘，但基本上可以认为是围绕“产品体验”类的问题。

（图5 B端产品，客户关心“MONEY”，用户关注“产品体验”）

B端产品的客户，通常是管理者，这些人不会通过邮件反映问题，而是说“小李，什么时候能不能来我们这一趟，有些问题需要跟你们交流一下…..”。作为产品经理的你，赶紧拉上大客户经理跑到客户那里去。这位客户会这么说：

“我们的业务这段时间错失了好多机会，无法快速增长，你们能不能帮我们分析和优化下我们的营销支出?”
“当前客户市场几近饱和，获新客成本特别高，如果想要实现我们收入同比增长20％的目标，就必须对存量客户提供个性化服务，你们有什么想法？”
“我们正面临着一个试图抢占市场份额的小型竞争对手的巨大下行价格压力，我们正在寻找新的方式与我们自己的客户合作以阻止损耗。”
“我们知道细分市场特别重要，但除了我们多年来一直在做的传统细分市场之外，我们不知道如何找到新的细分市场，你们有没类似的案例？”
“我们无法整合整个企业的客户数据，现在各个渠道、各个业务条线的客户数据还没完全统一起来，导致在做个性化服务的时候有很多苦难，你们能帮我们在3个月内搞定吗？”

你会发现客户关心的几乎全都是跟“MONEY”直接或间接相关的问题：要么就是直接提升收入或降低成本，要么是间接地提升销售量、转化率、开拓新市场、更好地用户留存等；要么是优化业务运营，比如更好的品牌、提升工作效率、合法合规降低风险等。

（图6 C端用户、B端用户、B端客户通常的诉求）

3. 产品价值 = 客户价值 or 用户价值？

当产品的客户就是用户时，比如印象笔记，那可以说“需求价值的衡量标准，就是用户价值”，产品的构建、需求的决策，都会紧紧围绕着用户来。但如果产品客户和用户分离了，在其诉求完全不同的情况下，那需求的价值到底应该是客户价值，还是用户价值呢？或者说两者皆有？

如果VIPKID只关注客户（家长）“看中成绩、定价便宜”的诉求，不注重用户（孩子）“游戏化”的体验诉求；或者反过来，单注重孩子的诉求，忽略家长的诉求，那它一定不会发展到今天。

B端产品客户有着大的决策权，是否就可以不注重用户体验呢？显然不是。IBM Notes的消亡是好例子。Zoom近年在企业视频通讯领域的逆袭恰恰说明了重视产品体验所产生的价值。反过来，是不是我赢得了用户，就一定能赢得客户呢？也不一定。早几年苹果的电脑如此受用户追捧，但企业选用苹果电脑的仍然是少数，因为太娇贵。

在多方参与的多边平台模式下，比如网约车平台中，在启动阶段追求消费者网络效应时，一边注重乘客端App的使用体验，一边还会不断补贴乘客；而当乘客大量聚集后会导致运力不足，则会转为重点补贴司机端，以保证运力。即使是这之中的第三方服务者，平台也依然会重视给其提供的价值，与其共生共长，比如在淘宝电商平台上靠运费险服务切入并成长的众安保险。

如果把产品所形成的业务闭环看做一个小生态体的话，客户和用户（无论是外部用户，还是内部用户）都是这个生态体的有机组成部分，思考产品的价值要综合考虑客户价值和用户价值，是个系统思考的过程。

4. 客户诉求和用户诉求，孰重孰轻？

如果客户和用户诉求可能不一样，需要系统思考产品给客户和用户带来的价值，这在思维层面接受起来不难。但在实践层面，进行需求决策可就困难了：客户和用户的诉求，孰重孰轻，该优先谁？

这就应该回到一个产品定位的基本命题：

产品到底为谁打造？想解决谁的问题？为谁带来什么价值？

这通常是由产品愿景、使命、价值定位来决定的。产品的愿景定义了“我们想往哪里去，想成为谁？”；产品的使命定义了“我们要解决谁的问题，为谁带来什么价值”；价值定位确定了“我们如何去解决，提供什么独特的价值”。

（图7 产品金字塔：愿景、使命、目标、战略、行动）

在每一个颗粒化的需求层面，非常容易迷失。而产品愿景和使命，可作为产品价值的核心基点。以前述B端产品“基于智能语音交互的银行客服系统”为例，对应的愿景可能是“银行领域最专业的智能客服”，使命可能是“专业为银行零售运营降本增效”，从而能知道产品是为“银行零售运营部门”解决问题，带来价值。

此时如果我们面临三个诉求：

诉求1：来自客户——银行零售运营主管，“把语音服务可以支持的场景从余额查询、转账、业务咨询，扩展到支持信用卡还款、智能推荐、交易记录查询”；
诉求2：来自用户——运营部的客服人员，“希望能尽快提供语音转换为文字功能，以方便对自动方式处理不了的诉求，更快捷地提供人工响应”；
诉求3：来自干系人——零售业务的一个负责人，“希望改变当前语音交互的界面布局”。

如果从愿景和使命出发，我们会看到这三个诉求与愿景和使命的相关程度：诉求1 > 诉求2 > 诉求3(基于我们已知的上下文)。

再以在网约车平台为例，如果对应的愿景可能是“引领汽车和交通行业变革的科技公司”，使命是“让人们的出行更安全、更美好”，那我们知道其核心是给需要“出行的人们”解决问题，带来价值。那对“消费者乘客”整体体验则是核心基点；不同方式的运力资源则是支撑这个价值的手段。决策时，不应该为了获取运力的资源，而让消费者的体验受损。当这种诉求冲突的时候，正确的解决方式，不是稀里糊涂就以司机端诉求为主，而是寻求创新性的解决方案：如何在不损害乘客体验的情况下，获取更多稳定的运力资源？

当权衡客户、用户诉求时，需要在战略宏观层进行系统思考，产品愿景、使命是我们的核心工作纲领，是我们做价值权衡的核心基点。

5. 产品的特性需求，价值该如何确定？

从产品愿景和目标，到一个个特性需求识别出来，实际上经由了这样一个从愿景和目标，到客/用户，到问题，到方案再到特性需求的逻辑分析过程。这里用敏捷中的User Story（下面简称Story）来代表我们识别出的产品需求。那么Story产生的过程，大致会有这样四个关键阶段：

（图8 产品需求／Story产生的过程）

从产品愿景与使命出发，来定义产品价值基点；
综合挖掘客户和用户本质诉求，定义问题、痛点或期待；
综合考虑产品业务目标、客／用户诉求和体验、技术可行性及成本，以及预算、能力和时间等约束，形成可行的设计方案；
根据设计方案，对产品能力需求进行梳理，识别和拆分出Story。

这个过程中需要特别澄清的是：

Story是方案域的产物，而不是问题域的产物；而价值是针对问题的，因此当我们在做需求优先级决策时，应该回溯到所针对的客／用户问题，及产品的愿景、使命和现阶段的目标，而不是仅仅停留在功能层面；
Story是基于业务目标、客／用户诉求、技术可行性及成本、预算能力时间等上下文约束下当前方案的一个体现；在去思考其价值和做决策的时候，必须充分了解到这些上下文，基于这些上下文达成共识；
产品需求优先级的决策，“对产品需求做减法”，则是从源头就开始的，对场景、对客户用户干系人、对问题和期待、对设计方案持续排优先级，最后才是对特性需求排优先级。

（图9 对需求做减法，需要从源头开始，持续排优先级）