产品经理分为两类业务，toB和toC，两者有相似之处和差异。作者从自己的经历出发，从七个维度分析两者的异同，方便大家做出岗位选择。

本文将从以下七个维度讨论这两类产品经理的异同。在你的职业生涯中，你分别经历过toC、toB对于产品工作，慢慢感知两者的区别很有意思，所以并行记录。

一、产品使用决策者

C端用户不同于b端客户。

曾经在猎头安排的一个纯粹的toC在产品经理职位的面试场，我谈到了用户的新游戏玩法。面试主管听了之后提出了一个典型的问题–你在的是获客手段，你真的做过C端产品，为什么不叫获客呢？

说明两者还是很容易混淆的。

1. 定义不同

用户直接使用产品，并有直接决策权，包括是否使用，是否支付，因此用户满意度是C端产品保留的重要指标。

toC医疗产品必须面对用户，用户是生物意义上的活人，他必须有血、肉、情感和冲动行为。

toB客户不一定直接使用产品，但有直接决策权，尤其是购买决策。客户可能是某种生物意义上的人，也可能是某种组织，类似于法人和法定代表人。

2. 关注点不同

由于定义的不同，这两类角色也有不同的关注点。

B客户关心的是客户的成功，客户愿意投入额外的资金、日常生活和精力一起使用这个产品来实现成功的目标。

C终端用户关心的是让自己感觉更好，更个性化的需求，更具体的情绪。用户投入的能量必须在不知不觉中消耗掉。如果用户感到困难或意识到额外的能量，很可能会导致用户的高损失。

3. 方式不同

由于宾语的不同，这两个动宾短语意味着动作的起点完全不同。

比如价格战略。

可以为B端客户打价格战，因为价格优势在资源型强的B端行业有很大的优势。与客户达成合作必须有合同期限。合作的概率意味着收入甚至利润。

如果在C端用户维度上使用价格战，电子商务场景可能会引起短期火花，医疗场景会适得其反。

用户往往怀疑太便宜的医疗产品和服务。价格战往往筛选出对价格敏感、对平台/品牌难以忠诚的用户，因此流量往往在短时间内相当可观，但真实用户对数据的保留并不乐观。

二、产品设计理念1. 使用驱动力差异

toC场景的驱动力是用户当前的情绪，让自己更好的原始动力，或者放松娱乐，或者得到社区的认可。

因此，C端产品的设计非常重视体验，特别是需要提前感知用户的操作意图，让酷感和舒适感贯穿用户路径。

toB场景的驱动力是如何有效地完成当前任务，降低错误率，避免资本损失。有一定的压力要求，产品设计需要简单易懂，但不能太舒适。例如，一些非常干扰用户但必须有异常的红色提示，检查错误的弹出窗口提示等。

2. 单个产品中交互思维的差异

C目前，更多的设备是手机，屏幕更小，所以分辨率更高，多页之间会有闭环跳转。原则点为3：页面跳转平稳，符合人性操作，与极端场景兼容；操作简单易懂；用户使用习惯的一致性。

B由于其交互设计原则点有3：

页面结构统一，上下结构易于沉浸式阅读，左右结构易于部分操作功能；模块区域统一，所有B端产品操作按钮在页面同一侧；使用简单方便，但不太舒服–这与B端产品需要考虑的体验并不矛盾。简单易用的产品BC都需要一直追求. 与其他产品的交互要求

C端产品更注重人机之间的互动，一个toC产品可以是整体闭环，对其他产品系统的交互要求不高或更少。

B端业务因复杂度高，单一产品无法实现完整的场景链路，往往需跨越多个产品。

产品通过界面互动，所以有些toB产品经理会在接口层面写文档。

如果是技术产品，应该还可以，但考虑到接口文档并不是商业产品或不了解代码层的产品的可取性。

根据业务路径，通过逻辑顺序梳理产品之间的交互，没有必要去接口细节。

三、产品衡量指标/商业模式

产品测量指标主要是指产品用户数量、使用时间、损失率、点击率、产品满意度等。商业模式是指通过产品实现的方式。

toC产品本身的测量指标与商业模式基本相同，因为它慢慢渗透到用户的特点中——用户决定是否继续使用C端产品。因此，产品数量多，使用时间长，产品的商业价值更大。

而toB由于其自上而下的产品特性——客户为员工购买产品，产品本身的衡量指标对商业模式的形成影响不大。体现在产品用户数量和使用时间上，Ctr这些指标与客户支付成功率关系不大。

客户满意度、客户支付概率往往与产品本身的个性化能力支持能力密切相关。

客户满意度不等于产品满意度，因为客户不是直接使用产品的人。

更新的产品能力与客户支付的概率一致。当出现新场景时，如何快速支持产品或找到支持的方法？toB产品的能力点，但这种能力点很难体现在产品本身的衡量指标上。

一些大公司会考虑B端产品的重用性，但由于该指标与客户支付成功率的相关性不高，因此很难反映该指标的商业模式价值。

四、协作方式1. toC合作-自闭环

单个C端产品从业务到产品技术ued自闭环可以形成最小的团队分工mvp。

产品发布上线后，可以在短时间内获得用户的数据反馈，并根据数据分析快速迭代。因此，C端合作模式更轻，产品角色有更大的机会发挥主导作用。

2. toB协作-链路长

以供应链合作为例，由于B端系统复杂性高，角色分工多，包括业务产品、系统单模块产品和系统细节领域的技术。

因toB产品链也很长。三个月前开发完成后，当有新的数据反馈时，可能会进行新的产品设计和开发。toB生产技术团队需要这样的角色，可以称为流程团队/业务产品，负责承担市场需求，抽象合理的市场需求。

根据抽象后的需要，系统单个模块的产品团队prd设计。

五、所需技能

B端的沟通能力非常重要，C端更注重钻研思维能力。

toB由于某种需求很难拒绝产品，toB商业模式是客户花钱购买产品的能力，所以大多数时候判断需求的合理性不是衡量B端产品能力的指标

只要客户提出这一需求，强资源型行业往往是合理的。

虽然不能说需求本身no，但经过深入沟通，可以对需求的实现做出更合理的选择。

toB产品不接近客户，接收需求来源或商务学生，或操作学生，在层层传输过程中，很可能会有需求理解的偏差。因此，我们需要与需求沟通者的学生进行深入的沟通。客户提出的原因是什么，具体的问题是什么，而不是如何解决的细节。

即使与客户沟通，沟通过程中也有很多技巧点。要引导客户多描述问题场景、原因和后果，通过具体的场景描述了解为什么会有这样的需求，不要被客户/需求传达者想象的细节绑架。

建议不要纠结如何在不了解这一需求的情况下实现它。

toC产品在选择需求时有更大的发言权，也有更高的要求。

需要更多思考需求的价值点，这也是toC产品本身的核心竞争力。判断什么样的需求能解决什么问题，问题本身能否带来相应的商业价值。

这种思维不仅要贯穿C端产品收到的每一个需求，还要形成自己的产品思维体系，有一套系统的产品思维模式By对不同需求的场景理解。

六、互通性

因为都是互联网产品，自然有可以互通的部分。

1. 用户路径的相似性

其实不管是B还是BC产品设计，回到源头或考虑用户路径。

toC用户路径也可以是情化驱动，场景需求需要研究和选择。

而toB用户路径对应的场景比较清晰，甚至可以列举。

2. 理解场景的能力很强

不管是面对 C终端用户或B端客户对场景理解能力的要求相同。

虽然同一个用户是同一个人，但可以看作是不同场景下需要服务的客户，因为在不同场景下使用同一产品的需求不同。

就客户维度而言，企业中每个人的利益动机都不一样。

因此，客户关心的成功有很多场景，不同场景下定义的成功是不同的。我们需要深入了解客户场景，以了解客户关心的具体成功。

七、应届毕业生如何选择

toB产品需要更多的了解行业属性，toC产品需要了解用户心理，研究产品本身的设计能力。

考虑到后续的兼容性，建议应届毕业生优先考虑toC产品，首先从产品的底层能力巩固基础，学习如何判断需求的价值，如何评估需求的可行性，培养自己的产品系统思维。

在有了一定的产品设计基础后，选择你感兴趣的行业，并尝试这样做toB转型。深入培育自己喜欢和认可商业模式的行业，在现有产品基本能力的基础上打磨行业认知，逐步增强作为产品的竞争力。

当然，如果你一直对产品设计本身感兴趣，你可以不做toB转型，继续走向产品设计能力，打造具有足够行业影响力的C端产品。但在这个时代，机会越来越少。

目前的感觉是toB产品入门门槛高，但toC产品要往上走难度会更大。

微信官方账号:老贺故事屋

本文由 @小贺大星 每个人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于CC0协议

本文仅代表作者本人，每个人都是产品经理平台，只提供信息存储空间服务。