B端产品特点

B端产品特点

一、强调抽象和逻辑

解释说明：B端产品的目标是解决企业、组织的某类业务问题，因此系统设计的重点在于如何让业务流程闭环、将核心流程跑通，进而赋能业务发展。

举例：在做B端产品时经常会遇到单据审批状态的逻辑，以合同为例：真正业务中合同单据只有领导审批通过之后系统内才能正式使用，应该如何设计产品逻辑？

解决方案：可以将合同状态分为：草稿、审批中、已生效、审批驳回，并且不同状态下又要具备不同的操作按钮与处理逻辑。

状态	定义	按钮	备注
草稿	合同提交审批前状态	删除、编辑、查看、提交审批
审批中	合同提交审批后、得到审批结果前状态	查看、撤销审批
已生效	审批通过后的合同状态	查看	问题：已生效合同如需修改，请思考如何处理？
审批驳回	审批驳回后的合同状态	查看、编辑	编辑后合同状态为草稿

深层分析：并不是说B端产品不需要考虑体验，更强调逻辑的原因在于目标和动力与C端产品不同。

• 目标：B端产品最基本要求是要提升原本同样业务流程的工作效率，而不是像C端产品一样如何提升用户的留存率，所以用户体验并不是最重要一环。

• 动力：B端产品使用者不是C端的每一名用户，所以企业在保证软件能用、好用的前提下，没有动力投入更多成本追求更好的视觉体验。

二、业务强驱动

解释说明：B端产品好坏的评价标准是能否现有业务问题、甚至引领业务发展，这就要求B端产品经理能够深入了解业务、判断业务发展方向，才能够设计出适合企业生存发展的好产品。

举例：电商集采是典型的、具备相对成熟方案的B端产品能力，公司A自行研发一套系统用于集中采购，请设计核心流程。

解决方案：作为产品经理，首先要了解企业电商集采流程，完全不同于我们个人在淘宝、京东购买产品。如果没有相关业务知识，建议先自行学习采购相关知识，再进行业务调研（思考：设计业务调研清单 ），否则会非常非常难受，下图是流程示意图。

深度分析：

• 为什么B端产品要考业务方驱动：B端产品是为了解决组织内某个或某一类具体业务领域问题，而业务方是离业务最近、离使用用户最近的，所以从谁更懂用户、谁才更能真正解决用户问题的角度看， 业务方驱动产品需求是正常的。

• 如何与业务方共同驱动产品：要想与业务共同驱动产品，只有一种解决方式：不断学习业务，比业务更懂业务。不过这是一个非常漫长的过程，可以通过视频、书籍提升专业知识能力，可以通过多次调研沟通了解业务操作，如果有条件可以亲身操作才能感同身受。

三、配置能力强

解释说明：相比于C端产品，B端产品是一群人在使用，所以避免不了会存在各种权限的配置（包括页面权限、按钮权限、数据权限等）、审批流的配置（合同审批流、付款审批流等人员的配置）、下拉列表值集权限配置、流程节点配置等。在这样的情况下，B端产品需要充分考虑市场情况，在设计之初就要在产品结构层上留出一定空间，能够把一些流程必要但是标准不统一的部分做成可灵活配置的功能，能够达到虽然业务流程不标准但是产品依旧能标准化的目的。

• 权限配置：B端的产品业务都会根据每个角色的不同而划分不同的业务场景，不同的业务对应不同的流程，所以需要各种不同业务流程的专业性解决方案。以集团内部业务协同系统为例，业务场景简化为发布公司需求，下表为简化后的角色和对应权限（思考：B端权限设计RBAC是什么？）

角色	权限
业务人员	可以增删改自己发布的需求
公司管理员	可以增删改自己发布的需求，并且查看该公司及下级公司发布的所有需求
集团管理员	可以增删改自己发布的需求，并且查看该公司及集团各级发布的所有需求，对重点需求进行置顶、加热提高推荐概率的处理。
超级管理员	可以增删改查系统内所有需求，并且进行所有的操作。

• 审批流配置：审批流是非常成熟的功能模块，但是不同审批流能够满足的业务场景却有所不同，下表是常见的审批流规则需求。

审批流示例	审批流节点
A部门付款审批流	业务员→部门领导→财务部领导→公司领导→财务人员
A部门合同审批流	根据合同金额做判断，合同金额小于等于50万，无需审批；大于50万小于等于200万，部门领导审批；大于200万，公司领导审批
A部门用印审批流	业务员→管理员1
A部门会签审批流	业务员→6位中层领导→公司领导，只有6位中层领导全部审批通过后，单据才能流转到公司领导。
A部门采购审批流	业务员→6位中层领导→公司领导，只要6位中层领导中有人通过，单据即可流转到公司领导。