时间: 2021-07-30 11:27:42 人气: 8 评论: 0
作为B端产品经理，理解业务是开展一切工作的基础。那么B端产品经理，又应该从哪些方面理解业务呢？ 快来看看本文的解答吧。
新人入职新公司后，第一个工作就是了解公司业务，一般都是看公司项目PPT、产品需求文档，根据现有系统功能梳理功能结构图、产品流程等方式，但并不能系统化地帮助我们了解公司业务，容易流于表面。
由于TO B业务往往具有鲜明的业务特性，如果我们对业务只是局部理解，或者理解有偏差，做出来的产品可能无法适应和支撑业务。
作为B端产品经理，理解业务是开展一切工作的基础。
B端产品经理在日常工作中，常常**收到各种各样来自不同部门的需求，所接收的需求，更多是意向，我们的工作就是要推导出意向背后的真正需求是什么，然后设计产品方案。
错误的理解业务，可能**直接影响需求的推导过程，如需求的定义、用户分析、需求分析的角度和实现方式等，最终可能导致产品方案的设计有所偏差。
与销售部门收集需求过程中，可能听得最多的是类似“客户有一个A想法”。
但实际上A想法是客户的解决方案，甚至是销售人员的解决方案，而不是真正的业务需求。
如果我们立即考虑怎么去实现A，做出来的方案，往往不是客户想要的。
而是要思考：客户为什么想要A？A能解决哪些问题？A与业务之间有哪些约束条件和弹性条件？有没有B方案呢？等等。
产品是基于业务之上的，只有对业务有足够深入的理解，才能发现业务需求背后的本质问题，从而制定更符合业务需求的产品方案。
决策是获取和处理信息，再对行为作出预测和判断的过程。
产品经理无不时刻处于决策的环境之中，上至产品策略、产品方向，下至产品功能设计、页面文案。选择做什么，不做什么，如何做，用什么方式去做，都是一个个的决策。
而我们所做的决策受业务信息的理解程度影响。
某TO B垂直领域平台的运营人员提出“年度报告”需求，根据客户日常基础数据提炼出营收增长、运营效率提升等方面的数据，并有积分抽奖小活动，感谢客户一年以来的辛勤劳动和支持。
产品上线一周后，尽管“年度报告”入口在客户端工作台的显眼位置，但打开率寥寥无几，活动更加无人参与。
产品经理可能没有意识到，企业客户的决策者和使用者，两者的用户特征和需求关注点是截然不同的。
决策者（老板、高层）确定购买产品服务后，极少或根本不**登陆客户端。
使用者（员工）并不关注减本增效方面的问题，至于积分抽奖活动，更加不敢私用积分。
产品经理对业务特征和用户特征的理解偏差，导致了错误的决策，最终浪费研发资源。
如果我们对业务有足够深刻的理解，就能提高我们做出正确决策的概率。反之，**导致我们做出错误的决策。
俞军老师曾经说过：产品经理的核心技能，其实是输出决策质量，持续的输出决策质量。
进入主题之前，我们先梳理一下TO B业务与产品之间的关系。
企业**根据市场环境，结合自身优势和资源制定商业模式，商业模式的落地可能需要1个或多个项目支撑和运转。
每个项目也可能**发展为1个或多个业务，每个业务**有明确的业务定位和业务目标。
产品**根据业务定位转化为产品定位，同时为支撑业务目标**设定不同阶段的产品目标，产品目标最后**落地为我们最经常接触的一个个产品功能。
对于大部分产品经理来说，可能接触不到制定战略、商业模式这一层面的工作。
所以本文将从产品经理最经常接触的业务定位、业务目标、业务场景、业务关系、业务角色、业务流程、业务规则的角度讲解，让我们更好的理解业务，帮助我们快速进入岗位角色或开展工作。
B端产品一般都是由业务驱动的，这就决定了产品面向的目标客户群体是谁，要做什么东西，什么东西不能做，怎么做，为什么这样做，帮助客户解决什么问题，有什么价值，都受业务定位的影响。
（1）业务定位
业务定位指企业对客户群体和业务方向的选择，是业务立项之初最为重要的环节。从定义上可以找出两个关键点：选择客户群体，选择业务方向。
举例：
有**的业务定位：中小商户的软件服务商。
从中可看出，有**选择的客户群体是中小型规模的商户，业务方向是成为软件服务商。
（2）产品定位
产品定位，是产品与用户的连接点，通过用户研究，挖掘客户群体的特征和需求，定义产品的方向和边界，如果有竞争对手，还需要考虑差异化的方向是什么。
业务定位与产品定位是挂钩的，从**上讲，先有业务定位，然后才有产品定位，产品定位是业务定位的产品化结果。
举例：
有**的产品定位是：做生意，用有**。
结合有**的业务定位“中小商户的软件服务商”，看看有**业务定位与产品定位的关联性。
中小商户最典型的特征是做生意，赚当下的钱，有**围绕中小商户，以软件服务商的身份，切入零售、美业、教育细分市场。
挖掘出商户网上开店、网上营销、管理客户、获取订单等需求，提供适用行业多场景的SaaS软件产品。
大多数时候，我们进入公司的时候业务定位和产品定位已经明确了，可通过业务负责人或产品负责人获知。
我们在产品设计时，需要围绕已设定好的产品定位去设计产品，清晰的业务定位，有利于产品经理了解团队当下做的事情和方向。
业务目标的主要获知来源，同样为业务负责人或产品负责人。
每个业务都**有1个或多个业务目标，即在一定时间范围内要完成的预期成果，如销售额、渠道转化率等。
业务目标需要产品目标做为落地的支撑，业务目标是定义产品目标的方向来源，只有明确业务目标，我们才能设定产品目标。
产品为配合业务目标的达成，**依据业务所处阶段和业务目标制定产品目标。
举例：
某TO B平台全年业务目标为1亿GMV，产品负责人根据业务发展阶段和业务目标，分析和制定了用户端和商户端的产品目标。
业务在不同的发展阶段，**面临不同的问题、矛盾，甚至机遇，所以，业务目标并不是不可变的，**因阶段而变化，产品目标也**随之发生变化。产品经理在工作中需时刻关注业务目标的变化，要与之适应设定不同的产品目标和产品规划。
企业为了给客户提供更多的产品和服务，或利用未被充分利用的企业资源，或避免单一业务的风险，或寻找新的增长点，甚至为了资本运作，**同时发展多个业务，建立业务矩阵。
了解当前业务和其他业务关系的目的是，一个业务体系为何**存在这些业务，这些业务之间是如何进行协同来支撑项目发展的。
TO B业务常见的方式是以某业务为核心，向产业链的上下游延伸开拓新业务，带动不同场景的其他业务，完善和互补业务场景，业务之间关联性很强。
滴滴出行以快车、出租车、顺风车、专车、代驾、单车等出行业务为核心。
通过挖掘个人车主/专职司机的车生活场景，提供缴纳违章、车险、优惠加油、养车等业务服务。
以及为企业用户提供差旅用车、加班用车、活动用车、**议用车等出行业务。
当然，也有业务关联性不强的情况，如支付工具想做社交。
了解当前业务在业务体系中与其他业务的关联，疏导出各业务的内在联系和推演发展趋势，有助于设计出更合理产品架构。
业务角色就是搞清楚这个系统到底有哪些人在用，可分为内部角色（如财务人员、销售人员、客服人员）和外部角色（如终端用户、商户、配送员）。
虽然TO B业务十分复杂，但只要拆分出业务角色了解他们的具体诉求，就能把握需求边界和业务流程，业务角色是业务需求的源头。
仓库人员角色有入库、出库、调拨、**点等诉求。商户有营销活动、提高曝光度、经营管理等诉求。
拆分出业务角色只是开始，接下来，要明确哪些业务角色是核心？角色之间的层级关系是什么？角色的限制条件是什么？角色之间的差异是什么？角色之间是否有协作关系？角色之间是否有互动？等等。
TO B业务具有多人协作的特点，一个业务角色在不同的业务流程下，可充当不同的身份。
根据业务的承接和交互关系，可分为请求服务、响应服务、调度服务、完成服务类型。
如运营部门员工组织一次场外活动发起物料采购申请（请求服务类），运营部门主管审批通过（响应服务类），采购部经理审批和安排采购工作（调度服务类），采购部员工完成物料采购入库（完成服务类）。
同时，每个业务角色的诉求，**随着业务发展阶段的变化而变化。
业务场景是需求的灵魂，来源于真实的现场实景，通常存在某种需要被满足或解决的问题。
了解业务场景的目的在于获取需求和进一步分析需求，基于场景了解业务角色诉求和业务情况，可以让我们更清楚业务角色为什么**提出这些需求，他们想解决什么问题。
在梳理业务场景时，我们要从用业务角色的角度进行思考：业务角色可能遇到哪些问题？可能存在的异常场景？产品方案是否能解决他们的问题？
运营：话费订单可以增加人工“标记订单失败”功能吗？
产品：系统目前可以根据直充结果自动修改订单状态了，为什么还要人工标记订单失败？是遇到什么问题了吗？
运营：最近话费供应商经常不定期维护直充通道，导致话费直充时效不确定，导致投诉率上升，影响用户体验，人工标记订单失败后，可及时给用户退款。
产品：好的，以前为什么没有发生过这种情况呢？
运营：目前话费供应商的供货能力好像有点问题，经常维护其实是缺货，去找其他资源调货了。
从案例中的业务场景，站在运营同学的角度，我们还有很多问题需要考虑：
如果人工标记失败后但实际又充值成功了，怎么办？如果接入多家话费供应商，日常运营维护**不**很麻烦？当充值时效较长时怎样处理？等等。
业务场景分析的过程，其实就是解决问题的过程，针对这些问题，分别提出不同的解决方案，最后落地为产品方案。
业务场景衍生需求，基于需求设计产品。当我们充分了解业务场景之后，才能更好的设计产品方案。
业务流程是由不同业务角色分别共同完成的一系列活动，这些活动的内容、方式、责任都有明确的界定。
任何业务流程，都可从整体到部分、由上至下的角度进行理解。
首先根据业务定位和业务目标，以实际业务场景为基础，还原业务的主流程，再深入各个阶段的分支流程，考虑细节流程、辅助流程、异常流程，流程是否闭环，避免整个产品只有功能，而没有业务。
以某B2B电商为例，梳理出业务主干流程（已省略部分细节流程和异常流程），如下：
其中“发货”流程属于业务主干流程分支流程，如下：销售出库——分配仓库——捡配单——分配物流——扫描出库
通过了解业务流程，可理解业务节点与业务节点之间，业务与业务之间的协同和集成关系。
否则看到的，可能是孤立的业务节点或业务，业务节点之间出现断点是无法协同支撑业务的。
同时，业务流程有严格的先后流转顺序限定，一定程度上也反映了流程之间的层次关系。如买家的进行订单支付，是建立在生产采购单的基础上。
业务规则能让业务角色知道在什么情况下，该做什么或不做什么，用于控制和影响业务目标，维持业务结构、规避风险的规范和策略，可分为通用业务规则和一般业务规则。
通用业务规则对业务的规范和导向作用，不是通过硬性的制度、规章手段来实现的，而是通过共同意识的引导来实现的，是一种软性约束，如企业价值观。
早期淘宝通过《大淘宝宣言》，明确消费者理应获得优于传统商业环境的商品与服务，消费者的地位至高无上。
当消费者与商家纠纷不清的情况下，淘宝客服基于《大淘宝宣言》的基本原则，应优先维护消费者的利益。
一般业务规则都是基于业务场景、业务经验或数据分析产生出来的，一个业务通常**包含很多不同类型的一般业务规则，如运营类规则、交易类规则、售后类规则等。
淘宝交易类中的**时规则，买家自拍下商品之时起算，**过24小时未付款的，交易自动关闭。
不同的企业**根据自身的业务情况建立适合的规则体系，同时还**根据市场环境调整业务规则。
在新冠病毒疫情期间，淘宝推出0账期服务，帮扶商家一起度过难关，意味着淘宝结算规则的变化。
理解业务规则能帮助我们更好的转化和设计产品规则，业务规则与产品规则存在着紧密而复杂的关系。
无论是刚加入新公司，0-1设计产品，还是某个需求的产品设计。
做B端产品，实际上就是了解业务的运作，搞清楚复杂的业务逻辑，场景思考，对业务进行抽象，提出解决方案，最后产品化的过程。
而这一切，都是基于深入理解业务才得以开展的工作。
作者：青木，B端产品经理；公众号：青木产品笔记
本文由 @青木 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议。
