思考总结 | 比起2c产品,2b产品的特性与特殊增值点有哪些
互联网产品市场和移动应用市场上,2b产品开始遍地开花。相较市场上玲琅满目的2c产品,2b产品如今依然显得还不成熟,市场依旧处于开发ing和待开发的阶段。
2b市场的机会已经被很多人发现,很多团队都在试图耕耘出一块新土地,并试图种植出最好的果实。但传统的2c经验,移植到2b的新土地上,是否真的完全合用?
虽说,产品思维适用于所有产品,但2b相较2c,的确有它特有的调性,这些特点,在2c产品中可能很少被考虑,甚至在2c产品中,是被要求尽量避免出现的问题。
以下观点是个人的工作总结,各位看官随意浏览,如果有不同的看法,非常欢迎在评论区指出,非常感谢。
一、特性
2b产品和2c产品,在服务对象上有很大的区别。产品切入的第一角度,就是目标群体。目标群体的特质化,也将导致产品的架构特质化。不同的产品,即使同是2c产品或同是2b产品,因为战略方向不同,服务群体不同,产品调性也呈现丰富多彩的差别。服务群体的不同带来的是需求的变化,使用情景的变化,使用习惯的变化。
2b产品,从大的方向上来说,服务于一个群体,产品的功能需要覆盖一群有关系的人,以及这一群人的附属环境(公司环境,工作设备,工作情景……)。这些服务的基本方向,决定了2b产品在组成上,拥有和2c产品截然不同的基本特性。
1. 团队id
2c往往满足个人需求,而2b需要解决群体需求。产品提供的服务、存储的信息、操作的权限,是面向多人的。所以,第一个最基本的特点,2b产品需要支持多个id共存,以满足团队管理。
微信私人对话信息仅面向对话的双方开放,而群聊则面向多个用户id,因为对话情景不同,对话的开放性不一样,同样是对话的功能,涉及的id数量范围就有变化。那同理,一个帮助用户记笔记的软件,如果是2c产品,可能就只能服务于一个用户ID,用户注册登录,绑定在一个专属的id上,才能看到这个id特定的笔记内容,并对其进行编辑操作分享,如果换一个账号,查看的个人笔记也就不一样了。如果发展成为一个2b的工作笔记服务软件,合理的功能模式,应该是同一批数据,开放给多个相关的账户id,这个时候,服务器记录的数据信息,绑定的对象就不再是一个又一个的账户id(当然,也可以是),而是一个团队id,这个团队id允许绑定多个个人id,那么,个人id在登陆后,通过对应绑定的团队id,就可以查看团队id对应的所有数据,实现数据的多账号共享。
2b产品往往也支持多团队切换。举一个很简单的例子:工作中,你加入了团队A,负责A项目的产品策划工作,同时,你还处于团队B,参与项目B 的产品运营工作,同时,还处于团队C,为一线销售团队的各个负责人提供各种产品服务信息文档。在这三个团队的工作中,你需要频繁地交换文件,于是,你使用了一个专门用于文件共享的软件,每个人上传的资料,对同一团队的成员都是开放共享的。那么,这样的一款团队数据共享应用,基本的账号管理中,一定需要一个多团队切换的功能,才能保证,在A团队中上传的资料,仅属于A团队,在其余团队中无法查看。
团队的区分,往往也是实际业务需求。例如,2c产品的付费业务,往往属于个人购买,我购买了,就属于我的,我喜欢用在哪个群组就用在哪个群组,随心所欲。但在2b产品中,付费业务往往属于团队共有资源,例如云盘空间存储量、工作电话拨打时长、邮件和短信业务数量等。团队A购买的资源,分配给了个人帐号,结果,个人账号可以将其用在团队B的工作中,这明显就是不合理的。团队id的门槛设置,就是为了将所有功能业务的数据完全隔离,进入应用,就必须先区分工作团队,给个人帐号扣上对应的团队帽子。这就将团队id的优先度提前到功能操作之上,这种产品架构,在2c产品中,往往是很少见的。
所以,在有一定复杂度的2b产品中,应用的数据应该是凭借团队id来进行区分的,而不是个人id。
2. 个人id等级区分
当数据需要覆盖到多个账户id,往往存在权限管理的需求。qq群中都需要区分管理员和普通成员,在实际团队工作中,更需要这一类身份区分的设计。这种id等级的划分,往往基于团队/公司的职位等级和岗位性质,例如,团队管理员需要知道所有队员的工作进度,老板可以查看所有成员的工作笔记,高等级的账号可以管理团队成员的添加和删除,而一般职员只能管理自己的工作业务,不能/没有权限查看、管理其他人的工作进度。
基于这种实际团队工作机制,2b产品在一个团队id对应的各项功能和数据中,有的功能和数据仅开放给特定的高级账号,其余账号只能查看管理基本数据和个人创造的数据,其余的数据没有权限访问。这种账号等级的区分,才更符合一个有一定工作复杂度的团队的实际管理。
团队权限基于团队而产生,所以,在不同的团队中,个人账号的权限是允许不同的。一个个人账号id,可以绑定多个团队id,从而以不同身份权限参与到不同团队的工作中去。切换团队,也对应切换了身份权限。这也说明了一点,2b产品的数据,更多的是凭借团队id进行隔离。
3. 保密性 安全性
工作内容要求一定的保密性和安全性,这个不需要解释。信息保密的需求,2b产品会比2c产品更为迫切。2b产品往往需要考虑,如何保证工作内容、对话内容不泄露,从而诞生了一些相对特殊的产品功能。
2b产品可能不允许复制,只允许粘贴;可能设置秘密通话功能,对话内容数据24小时内自动粉碎;可能属于公司私有云服务,外网无法登录;可能高级账号可以对部分文件进行云备份;可能每一个账号的操作轨迹都会被自动记录,由高级账号进行监测;可能账号与硬件绑定,切换硬件账号失效……
可能部分2b产品,相比2c产品,易用性会相对较低,但在2b市场,产品服务价值往往远大于体验价值。设计一款优秀的2b产品,切中价值痛点,构建完整的产品维度,隔离管理相关数据,并保证数据的安全和保密,才是基本的要求。而易用,在不折损其他价值的情况下,会成为一项加分项。
二、增值点
2b产品在解决基本的业务需求之后,可以将产品线延伸到什么程度?除了基本业务服务,什么功能可以让产品更加成熟、更有价值?
1. 营销价值
一些帮助连接企业和客户的2b产品,解决的实际上是经济需求。用高效、高质、统一、持久的模式,实现工作管理和业务变现。如果使用2b产品完成对外商务任务,例如,假设使用某款2b产品来发起并管理新产品发布会的信息,那产品的的最直接价值是:完美完成发布会信息的发布和管理。那在发布会结束之后呢?这样的产品对于这场发布会还有什么影响价值?它的功能线还能延伸到什么程度?
像这种可以实现企业向外对接客户的2b产品,它的核心价值是实现人的对接,可延伸的价值应该做到人的营销。核心功能get到客户,延伸功能维护客户,并激发客户,争取让一般客户转换为忠诚客户。如果能做到这个程度,那这样的辅助客户对接的产品,对人的影响,会从对接的时候开始,一直影响到对接结束之后很长一段时间。不仅帮助平台方(B端)积累商务资源,还帮助转化商务资源。
2b产品不仅应该是一款提供专业功能的功能性产品,在有可能的情况下,还应该考虑覆盖较全的商务情景,把事情做了,还要保证事后的商务效应。
2. 工作轨迹
这个和产品的保密性要求高低有关。有一定保密性要求的2b产品,往往都有考虑账号的轨迹记录的问题。
这个轨迹可以理解为两个概念。第一,指的是工作成员的账号轨迹:7:00 A账号更新了任务,B账号参与了聊天,C账号修改了个人资料,D账号实施了一次XX界面的截屏…………巨细则由产品本身的要求来定。总而言之,处于指定团队内的所有账号的所有活跃状态,都会被记录下来,可由高级管理员进行查看、操作、删除等。这样的工作轨迹可用于:
- 复查信息修改情况,异常情况下可以找到恢复节点(如果产品信息允许备份并恢复的话)
- 明确数据的修改动态
- 掌握成员帐号的动态
等等
第二,可以理解为涉及的客户信息的登记轨迹。其实就是客户数据记录和管理:A先生在7月2号参与了本公司的某某发布会,在8月4号又参与了公司展览,一季度内交易金额为XXX……所有记录在案的客户信息跟踪记录并持续更新,可以帮助:
- 分类客户
- 帮助找出潜在客户
- 帮助有针对性地跟踪特定客户
等等
以上皆为个人看法,归纳的并不完整。有相关经验有看法的,欢迎留言,多谢共享。
本文由 @小卷 原创发布于人人都是产品经理。未经许可,禁止转载。
对于2B中的B是学校角色的时候就很难过了,尤其是公立校,因为他上面紧密相连的是教育局,有很多时候,学校决策者做的决策和其主要需求都是跟教育政策,教育局安排直接挂钩的,挖掘这部分用户的痛点需求细节真的好难!
文章写得很好,学习了~不过个人感觉特性里的第一点和第二点,小标题有点描述不清,第一点应该是在讲述团队角色,要按照团队id划分角色,定义功能权限和数据权限,第二点再讲个人身份,同一个人在不同的团队可以定义为不同的团队角色,在功能和数据上也就有了区分。
仅供参考~~请多多指教
是的,可能是表达还不够准确