C端产品经理转型B端?你需要三三三思!
C端到B端,同样是做产品,你可能觉得只是职责上的差异。但B端和C端又是如此的不同,在产品特性、产品设计、产品运营以及对产品经理的技能要求等方面都有着差异点。想要转型?需三思!
现在的互联网行业,就像是35岁的互联网人一样,开始逐渐进入下半场。C端流量红利开始消退,很多企业开始了转型,将目光投向B端服务。阿里、腾讯也开始加码企业级服务的投资。
产业互联网的兴起,不同产业的企业间互联,好像也给了广大焦虑的互联网产品人一个可选的新方向: 从C端产品转型做B端产品 。
从C端转型到B端,同样还是做产品,你可能会觉得只是职责上的差异。但B端和C端又是如此的不同,考虑着转型到B端的你,从思维到方法,都需三思!
一、C端和B端的定义
先了解一下什么是C端产品和B端产品:
- C端: Consumer(也可理解为Customer),通常为消费者、个人终端用户使用的客户端。如:微信、淘宝、网易云音乐等;
- B端: Business,通常为企业内部或商家使用的系统或平台。如:企业内部ERP管理系统、财务管理平台等。
二、C端和B端在产品特性上的差异
1. 所处行业与场景需求
C端产品并没有明显的行业特征,比如微信社交、淘宝购物、美团点餐、高德导航,更多的是满足了使用者在“生活场景”下的各种个人日常需求。
B端产品通常行业特征相对明显,更多的是满足了企业相关用户在“工作场景”下完成协同工作的一些特定组织需求。
2. 用户量级与类型
C端产品的用户量级大而广,用户可具体到每一个“终端个体”,一般称之为“用户”。
而B端产品的用户量级更小、相对也更垂直,用户类型通常是“组织群体”,包括决策者、管理者、普通员工,区别于一般“用户”,更多情况下是被称为“客户”。
3. 展示方式
C端产品通常以手机端为主,PC端为次。
B端产品多数都集中在PC端使用,使用“左导航右内容”的布局。
4. 盈利模式
C端产品大都免费开放给用户,在提供免费功能的基础上,再通过“拉新、留存、促活”等手段,转化其中一小部分用户。像漏斗模型一样,最终为服务付费的这部分用户为产品贡献了收益。
这一切得益于C端产品大量级的用户规模,所以靠的是“规模经济”。
B端产品没有用户量级上的优势,偏向于服务企业内部的工作协同,就需要为不同的生产关系和工作协作场景做个性化定制,靠企业对“定制付费”来获得收益。
三、C端和B端在产品设计上的差异
1. 功能设计
对于C端产品而言,需要至少有一个核心的主要功能点能满足用户的某一项诉求。围绕这个具体的核心功能,再去考虑附加更好的用户体验和增值服务。
B端产品来说,要解决的主要是不同生产关系的协作沟通需求。在中心化的组织架构下,B端产品需要满足不同层级和组织内外的协作沟通,功能呈现模块化。
2. 角色设计
C端产品的用户虽然大致需求一致,但每个人的身份、年龄、兴趣、偏好都不尽相同,这就要求产品经理从众多终端用户中抽象出样本特征,形成不同的用户画像,有针对性地满足各类人群的个性需求。
而B端产品的用户量级小,但用户角色众多(决策者、管理者、普通员工),需要好好分析各角色的需求关注点,并做好角色分配和权限管理上的设计。
比如在B端产品的用户中,有“决策者、管理者、普通员工”的区分。他们同样是B端产品的用户,但对产品的期望和关注点是不同的:
- 决策者(老板) :关注企业的总体效率和成本;
- 管理者(部门领导) :关注管理职责和工作成绩;
- 普通员工(使用用户) :关注软件是否简单易上手、能否减轻工作负担。
3. 视觉体验设计
C端产品需要兼顾“用户体验”和“商业化变现”的平衡,所以会额外重视在视觉体验上的设计。不仅要让用户有快速流畅的使用体验,更要用趣味性的设计引导用户自发地做社交分享。
B端产品需要满足用户集中精力完成具体工作事项、不被打扰地进行严谨的流程操作,所以在视觉体验上多是保持干净简单的简洁风。
四、C端和B端在产品运营上的差异
1. 运营目标
在相同转化率的前提下,想到得到分子的增长,分母必须要等比例的更多增长。C端产品的盈利模式决定了想要创造更大的价值,就需要倚靠持续的用户量级的增长。
B端产品相比C端,更看重看中稳定的专业能力,不求大起大落,只求不要出错,避免给企业带来损失。
2. 运营策略
C端产品倚靠大量级用户的盈利模式,决定了C端产品需要利用“红包、优惠券、精神奖励”等营销方式,以利益激励用户主动在线上进行“对外分享传播”,实现以不断新增的日活来加持自身体量。
B端产品有着天然的“封闭”特性,营销上也更传统,通常将线下“大型会议、峰会、行业展会”作为主要场地,近距离接近客户,通过树立行业级别内的“专业形象”来吸引企业客户的兴趣。
3. 运营程度
C端产品早已将运营专业化,并细化到各维度的运营了,比如运营的工种可以细分为“活动运营岗、用户运营岗、增长裂变岗、内容运营岗”等等。
B端产品的运营往往不被重视,也没有C端那么专业化。在运营预算有限的情况下,通常是“运维多于运营”,只集中精力关注用户对产品的认可度和系统问题的定位。
五、C端产品转型到B端要面临的挑战
转型B端产品的这些挑战,你准备好了吗?
1. 管理者需求与用户需求的隔阂,需要妥协
B端产品的用户比较特殊:通常使用B端产品最多的是普通员工,但最终决定拍板产品的却是员工上方的管理者,甚至是管理者上方的大BOSS。
一边是实际使用的多数人,另一边是有实际决定权的少数人。少数服从多数的场景,在这里好像并不那么适用。
B端产品的管理者通常对产品有从管理层级上有特殊的要求,但这些从管理者角度输出的产品功能,和实际系统使用者所期待的需求可能并无交集。
这一段无交集差距带来的隔阂,是无法忽略的。
一个抱着“只需做一个被大多数用户称赞的产品”想法的B端产品经理,注定是不合格的。
B端产品经理必须有所妥协,去综合考虑如何整合多方需求、不同角色用户的使用习惯及学习成本,完成一个能最终被管理者认可的产品,去实现产品在管理角度和企业商业上的价值。
2. B端竞品很少,难以获得分析机会
B端产品因为其行业特性和面向企业内部使用的场景特点,决定了B端产品相比于C端产品,具有较高的使用门槛。
很多B端产品会有“软件收费、仅支持企业用户”等等限制,所以通常你能了解接触和亲自体验的B端对标竞品可能并不多,也就很难获得竞品的调研机会。
3. DAU断崖式骤降,带来巨大心理落差
大多数B端产品的用户量级还无法跟C端产品相提并论。
当你经手过几十万、几百万DAU的C端产品后,转型到DAU以百人为单位计数的B端产品,流量思维也好似无用武之地,你确定产品用户量级上的落差不会给你带来心理上的落差吗?
4. 数据运营难有成效,成就感偏低
做C端产品时,我们重点关注”拉新、存留、转化“上的运营,侧重分析用户各种数据(DAU、MAU、停留时长、使用路径、跳出节点等),为我们新的产品决策提供数据依据。在我们做完一系列数据分析和运营举措后,数据质量有可能再次得到改善和提升。
这些增量数据的背后,正体现了产品与运营联手的价值与成就。
而B端产品因为有限的用户量级,其产品运营上的更多可能性也被限制,C端的一些常规运营手段难以在B端施展。B端的数据运营也很难有大的成效。
做B端产品的你,没有亮眼的数据成绩,往往注定会长期一段时间坐在冷板凳上,等熬出一些业绩才能收获到一点成就感。
5. 交互体验设计较单一,乏味无趣
B端产品的交互相对于C端产品,更为单一,缺乏多样性。因为注重业务逻辑功能的实现,加上对工作性价比的考量,很多B端产品在设计上通常大大地减少对用户体验的考虑,甚至直接忽略。
很多B端项目团队中,没有专职的UI设计师,更不用说设计规范。
在C端产品中会常有做比较酷炫、眼前一亮的交互体验的机会,但在B端产品里却不常有。
很多你在用户体验上的想法和灵感,可能无法施展。
6. 可能要承担更多的职责
由于一些在C端里常规的优化体验及运营等工作难以在B端施展,某些B端团队的人员配备会较为精简。在人力资源有限的情况下,B端产品经理可能会被要求参与到产品的不同阶段里,承担起除了产品以外的职责。
作为B端产品经理的你,可能在制作原型的阶段就会被要求要同时完成一部分的UI设计和交互设计。甚至还有的时候,你需要面对用户去像客服一样地答疑,或者面对商家群体去做渠道支持。
7. 容易进坑,缺乏持续性思考和产品归属感
当你在公司连续做过几个B端产品,可能会在夜深人静的时候扪心自问:“我这是在做项目,还是在做产品?”
做C端产品时,你能比较完整地参与到产品的全生命周期,特别是在产品上线后一系列的持续运营过程。我们可以在新功能点上线后,跟踪用户的使用反馈和运营数据,从而完善优化迭代计划、不断地改良产品功能细节和用户体验。
而企业内部更注重人力成本和价值投入产出比。B端团队内的人员投入产出比也会常常被管理层考量。所以在项目时限、人员产值考量等客观条件下,B端产品很容易被安排进不同的项目里做产品。
很多时候,你还没有时间好好地对你刚完成的功能模块做复盘回顾并为第2次持续迭代优化做积累和准备,一个新项目的需求任务已经派到了你的头上。
而复盘和总结回顾,正是一个产品自我打磨和知识积累的必要方式。
快速的项目转换,带来的是持续性思考的中断。缺少了一份持续跟进,对于自身产品方法论验证的有效性也会大打折扣。
若你作为乙方去做B端产品,情况则是更甚,与甲方的合作方式等限制要求很容易导致你只能关注到项目的短期目标。
更不用说,也许你接手的正是前人埋下的、想填却没时机填的坑。这种情况下,就很难要求B端产品经理还能保持一份持续性的思考习惯。
如果说“产品经理就是产品的妈,把产品像自己的孩子一样一手带大”,那么被安排进不同项目的B端产品经理,就像是“产品”这个娃娃的近房亲戚。血缘关系是有的,但你还不好去直接认养。
归属感,始终少了那么一点。
六、如何迎接转型B端的挑战?
C端产品转型到B端,纵然是需要面临极多的挑战。但,谁说挑战就只是打击?
迎接挑战,我们可以考虑从以下几点做起:
1. 锻炼全局思维和逻辑能力
B端产品是针对行业或企业内解决方案,往往业务复杂程度高、流程冗长,涉及的相关角色众多,因此需要B端产品经理具有优秀的理性思维。
一方面,B端产品经理需要运用全局思维进行产品整体框架的搭建和业务流程的梳理。
另一方面,强大的逻辑能力也是必须的,需要从整体到局部,将业务需求和用户需求逐步细化拆分为相互独立但又具关联性的各个功能模块。
这是B端产品经理最硬性的要求,你必须从现在就开始锻炼。
2. 做好行业和业务深耕的准备
B端产品需要了解行业的现状及发展趋势、行业的产品或解决方案等。只有熟悉了行业内部的业务现状和经营痛点,才能针对业务进行流程效率及用户服务质量的提升改进方案。
对于本行业中可调研的竞品较少的情况,B端产品也可以学着用一些间接的方式去了解,比如:
- 接近竞品用户,去获取他们在使用竞品时的实际感受;
- 假装自己是潜在用户,找可供免费试用的商业软件产品去试用体验;
- 对于成本较高、无法低成本试用的商业软件产品,可以阅读其官网上公开的用户操作手册。
3. 提前学习B端的特有知识
很多B端产品共同的要素,可以提前进行知识学习的。比如“机构管理、用户权限管理(RBAC模型)、数据仓库”等。了解一些B端技术知识和规则,可以反过来帮助你反思在产品上的设计。
4. “流量思维”到“服务思维”的转变
在C端产品中运用的流量思维,在B端产品上已经不再适用了。利润渠道较单一的B端产品,最终需要靠服务去提高产品的溢价。B端产品需要将“流量思维”转变为“服务思维”,而不是片面地追求流量和用户量。
要明白,在B端服务好一个老用户远比盲目扩加新用户更重要。
B端产品应当聚焦已有核心客户,在“需求沟通、业务分析、产品验收、后期维护迭代”各阶段中,与客户深入接触、做好专业服务保障、稳固合作关系。
5. 学会成本思维
企业选择一个B端产品,通常会考虑2大成本问题:
1)“这个产品能为公司降多少成本?”
B端产品是基于企业已有的业务形态,把传统线下工作流程,转为程序化、系统化的线上流程。所以企业客户是希望产品的功能能实现业务流程上效率的提高,降低企业经营过程种的各种成本。
2)“试错成本有多大?”
B端用户一但选择一家产品后,持续付费率和复购率会很高,因为B端用户中的决策人众多、决策周期长,所以离开现有产品的成本也比较高。
B端产品经理要有成本思维,既要替企业客户考虑如何降低成本,也要打消影响企业去重新选择另一家产品的顾虑。
6. 迁移和利用C端思维
面对B端产品的某些难操作的现状,并不是全都无能为力。一些C端思维是可以在合适的场景下迁移进来并运用在B端的。比如:
- 当B端产品业务逻辑功能已达要求,用户对使用体验有更高期望时,可以考虑加入一些C端产品中如何优化交互体验的设计方法;
- 当B端产品的使用用户达到一定量级后,可以考虑加入C端常用的会员体系、积分体系、用户激励体系等CRM运营手段;
掌握了C端玩法的B端产品,是可以在B端市场中获得更多就职机会的。
7. 把握近距离接触用户的机会
B端产品可能更容易近距离接近用户、倾听客户的声音。比起C端的超大用户群体,B端产品是有机会近距离靠近用户、更容易地搞清楚“我在为谁解决什么问题”的问题的。
好好把握能近距离接触用户的机会吧。
8. 学习更多软技能
为了B端产品工作能力的不断完善,我们可以掌握一些专业能力以外的软技能:
七、结语
无论如何,产品经理都是致力于解决问题的一个岗位。C端产品经理转型到B端,纵然是需要面临极多的挑战,但就像你让一个B端产品转型到C端一样,Ta又何尝会觉得没有挑战呢?
应对改变、自我刷新,对大多数人来说都不是一件简单的事。但这世上,唯一不变的事情就是“变化”本身。
若是做好了决定,就对准那些挑战,迎头去碰撞吧!
作者:葛晓玲,一个互联网重度依赖者。微信公众号:产品零感(feelingPM)
本文由 @葛晓玲 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议
作者暂无likerid, 赞赏暂由本网站代持,当作者有likerid后会全部转账给作者(我们会尽力而为)。Tips: Until now, everytime you want to store your article, we will help you store it in Filecoin network. In the future, you can store it in Filecoin network using your own filecoin.
Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: