产品经理分为两类业务，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协议
本文仅代表作者本人，每个人都是产品经理平台，只提供信息存储空间服务。
