产品这个工种,toC还是toB好?

本文将从以下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:

  1. 页面结构统一,上下结构便于沉浸式阅读,左右结构便于偏操作性功能;
  2. 模块区域统一,所有B端产品的操作按钮都在页面同一侧;
  3. 简便性,便捷使用但不能过于舒适–这与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产品要往上走难度会更大。

公众号:老贺的故事屋

本文作者 @小贺大星

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部