我理解的 toB 产品框架(四)

还没看过我前几篇文章的童鞋,请在阅读本篇之前,看看:

我理解的 toB 产品框架(一)

我理解的 toB 产品框架(二)

我理解的 toB 产品框架(三)

前文再续,书接上一回。前文提到的产品框架即使做得再好,它还是一套普通的红绿灯交通系统,未来的 toB 产品应该是一套智能话的交通系统。以前人们需要花很大力气在构建系统上,比如私有云设备贵、部署成本高,同时还需要花人力与时间在干预系统上,就像现在交通繁忙时段交警需要人工介入一样。

那么未来的 toB 产品会怎么样?我想使用审批做为例子:用户初次使用产品,只需要设好组织架构,AI系统会自动推算出企业最优的审批模式。同时,在做审批的时候,不再需要人为做判断,而是系统判断同意或驳回。但当系统无法判断时,用户也只需要做少量干预即可。那么未来的 toB 产品依然是以底层权限为基础,在权限上搭载大数据分析系统,AI系统基于大数据分析系统所得的结果,做一定的机器学习,从而做到多数流程自动化。(目前最接近此形态的有苹果的Siri以及微软的Cortana)

同时表单将变得更加智能,传统的键盘输入,会被智能补全或者语音输入所取代:

这篇文章貌似有点短,顺便把前面挖的坑填一填。在第一篇提到的 C 端产品,与 B 端产品的差别巨大,为何会这样?以下是我的几点小思考:

  1. 多角色问题。C 端产品一般用户构成较为单一,人物画像构建比较简单,而且大体需求相差不多。但是 B 端产品角色必定是两个或以上,即客户与用户。客户是指为产品付款的人,多数是公司的管理者,而用户则多为员工。两者人物画像差别巨大,同时两者的需求还会出现矛盾的地方,客户需要的是管控,用户需要的是自由。
  2. 业务瓶颈。做 B 端产品,不只是需要了解企业,还需要了解业务,而一般的互联网从业人员可能很少拥有很强的业务能力。比如做CRM系统的人,可能根本没做过销售。在做产品时,很难将自己代入到用户那,因为自身就不是销售。
  3. 企业的潜规则。拿报销做为例子,如果按照互联网思维去做报销系统,一般会从提高体验,提高效率上着手去做。但是这不一定会有企业买账,因为对于企业来说,利润最大化才是企业的核心需求,报销速度越快,例如掉得越快。财务拖你一个月,企业就多一个月的流水。这就是企业的潜规则。那么做为一名产品经理,就需要同时考虑潜规则去做报销。比如是否能将报销前置,使得企业能削减成本的同时,满足员工的报销需求?(或者换个角度看,无需员工花钱)企业版滴滴,就是个很好的例子,企业提前买一定数额的里程,因为是提前购买,可以获得一定的优惠。企业将这些快车里程分发给员工,员工无需付费就能享受到快车服务。(报销的需求,要根本解决就是要换个角度思考,与其玩报销,不如玩赊账或提前付费)
  4. 不只需要了解客户与用户,还需要了解客户的客户以及客户的用户。这句话有点绕,其实就是在第三篇文章中,说到的一个趋势,平台未来会打破原有企业信息孤岛,对接上下游。这个时候,我们设计的产品不只是企业在用,可能个人也在用。
Comments
Write a Comment