产品经理分为两类业务，toB和toC，二者有相同之处也有差异。作者从自身经历体会出发，从七个维度阐析二者的异同，方便大家做出岗位抉择。
本文将从以下7个维度浅谈这两类产品经理的异同。在自己的职业生涯中，分别经历着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端更多使用设备还是电脑端，更倾向于单个页面完成80%的操作，因为其交互设计原则点有3：
- 页面结构统一，上下结构便于沉浸式阅读，左右结构便于偏操作性功能；
- 模块区域统一，所有B端产品的操作按钮都在页面同一侧；
- 简便性，便捷使用但不能过于舒适–这与B端产品需考虑体验并不矛盾，简洁易用的产品不管BC都需一直追求。
3. 与其他产品间的交互要求
C端产品更关注人机之间的交互方式，一个toC的产品可以是一个整体闭环，对其他产品系统的交互要求并不高，或者说较少。
B端业务因复杂度高，单一产品无法实现完整的场景链路，往往需跨越多个产品。
而产品之间是通过接口来交互，所以有些toB的产品经理会把文档写到接口层面。
如果是技术出身的产品应该还好，但是对业务出身的产品，或者并不了解代码层的产品来说，考虑到接口文档并不是一件可取的事情。
基于业务路径把产品之间的交互通过逻辑顺序梳理出来即可，并没有必要到接口细节。
三、产品衡量指标/商业模式
产品衡量指标主要指产品使用人数，使用时长，流失率，点击率，产品满意度等。商业模式指通过产品达成的变现方式。
toC产品本身衡量指标和商业模式基本一致，因其慢慢渗透用户的特性-用户决定自己是否继续使用C端产品。所以使用产品人数多，使用时间长，这个产品的商业价值就更大。
而toB产品本身的衡量指标对商业模式的形成并无太大影响，因其自上往下的产品特性-客户购买产品给员工使用。体现在产品使用人数，使用时长，Ctr这些指标与客户买单成功率关联度并不高。
往往是客户满意度、客户的买单概率与产品本身的个性化能力支持能力强关联。
此处客户满意度并不等于产品满意度，因客户并不是直接使用产品的人。
更新的产品能力，和客户买单概率相吻合的，当有新的场景产生的时候，产品如何能快速支持，或者想办法去支持，是toB产品的一种能力点，但是这个能力点却很难体现在产品本身的衡量指标上。
某些大公司会考量B端产品复用性，但因着此指标与客户买单成功率关联度并不高，所以也很难体现该指标的商业模式价值。
四、协作方式
1. toC协作-可自闭环
单个C端产品从业务到产品技甚至ued都可以自闭环，形成最小团队分工的mvp。
产品发布上线之后，短时间内便可以获得用户的数据反馈，基于数据分析快速迭代。因而C端协作方式要求更轻便，其中产品角色有较大机会能起主导作用。
2. toB协作-链路长
以供应链协作为例，因B端系统的复杂性较高，角色分工较多，包含业务产品，系统单个模块的产品以及系统细节领域的技术。
因toB的产品链条也较长，3个月前开发完，到有新的数据反馈的时候，可能已经在做新的产品设计开发。所以toB的产技团队中需要这类角色，可能叫流程团队/业务产品，他们负责承接市场需求并对合理的市场需求进行抽象。
而系统单个模块的产品团队，则是根据抽象之后的需求进行prd设计。
五、需要的技能
沟通能力在B端需要非常重要，C端更看重钻研思考能力。
toB的产品很难拒绝某一种需求，因为toB的商业模式是客户花钱购买这个产品能力，所以大部分时间对需求的合理性判断能力并不是衡量B端产品能力的指标项
在强资源型的行业中，往往只要客户提出这个需求便是合理的。
虽然不能对需求本身说no，但是做深入沟通后，可以对需求实现做出更合理的选择。
toB产品离客户不近，接收需求来源或是商务同学，或是运营同学，在层层传导过程中，大概率会有需求理解的偏差。所以需要和需求传达者的同学深入沟通，客户提出的原因是什么，具体是解决什么问题，而不要落入到如何解决的细节中。
甚至和客户沟通，沟通过程中的技巧点也非常多，要去引导客户多描述问题场景、前因后果，通过具象的场景描述去理解为什么会有这样的诉求，不要被客户/需求传达者设想的实现细节绑架。
建议不要在不理解这个需求的前提下，去纠结要如何实现。
toC的产品在需求的选择上因为有更大的话语权，同时也就有更高的要求。
需要更多思考需求的价值点，而这也是toC产品本身的核心竞争力。判断什么样的需求能解决的是什么问题，以及解决的这个问题本身，是否能带来对应的商业价值。
这类思考不仅要贯穿在C端产品接收到的每个需求中，而且需要形成自己的产品思考体系，能有一套体系化的产品思考模型来By场景化理解不同的需求。
六、互通性
因为都是互联网产品，天然便存在可以互通的部分。
1. 用户路径的相似性
其实不管是B或C的产品设计，回到源头上还是要考虑用户路径是什么。
toC的用户路径也可以是情绪化驱动，场景诉求需要钻研，并做取舍。
而toB的用户路径对应场景是相对明确的，甚至可以枚举。
2. 强场景理解能力
不管是面对 C端用户还是B端客户，对场景理解能力的要求都一样高。
同一个用户，虽然是同一个人，因为在不同场景使用同一个产品的诉求并不同，所以可以看成不同场景下需要服务的客户。
客户维度来看，更是如此，企业里头每一个人的利益动机都不同。
因而客户在意的成功有非常多场景，不同场景下定义的成功并不相同。需要深刻理解客户场景来共识客户关心的成功具体是什么。
七、应届生如何选择
toB产品需要更多的是了解行业属性，toC产品则需了解用户心理，去钻研产品本身的设计能力。
从后续的兼容性考虑，建议应届生优先选择toC产品，先从产品底层能力去夯实基础，去学习如何判断需求的价值，如何评估这个需求的可行性，去修炼自己的产品体系化思路。
有一定产品设计基础之后，再去选择自己感兴趣的行业，尝试做toB的转型。深耕在某一个自己喜欢且认可商业模式的行业，在已有产品基础能力的地基上，去打磨对行业的认知，逐渐加厚作为产品的竞争力。
当然如果对产品设计本身一直感兴趣，也可以不用做toB的转型，持续往产品设计能力上走，去打造一款有足够行业影响力的C端产品。只是在当前这个时代，这样的机会越来越少。
目前的感觉是toB产品入门门槛较高，但是toC产品要往上走难度会更大。
公众号：老贺的故事屋