本文节选自《决胜B端》第二版。B端业务涉及多角色协同，并且不同角色的诉求不同，产品经理在产品设计前，首先应该梳理清楚业务中存在哪些角色和利益方，这是理解业务运作、合理安排调研计划的基本前提。
利益方是一个经典的概念，在软件工程、需求分析工程、项目管理中都有提到，利益方的另一个名字叫作涉众（StakeHolder），也可以叫干系人。如果对利益方识别不准确，不仅影响调研工作的开展，甚至会让产品经理迷失，搞不清产品到底要解决谁的问题。
3.4.1 B端业务有哪些典型的利益方
不论是哪种类型的业务，我们都可以将利益方归类总结为三大类，即从企业内部（这里所说的企业，是指使用软件的企业，而非研发软件的企业）、企业外部、政策法规这三个视角进行分析。
企业内部
业务提出人：一般是指公司的最高层管理者，包括董事长、总经理、CEO，业务提出人制订公司的战略、规划，对某个业务的开展提出要求和预期，并招聘业务管理者负责具体业务的设计、执行和落地；业务提出人一般也是软件购买的出资人，提出业务诉求，并且出资购买软件。
对应“业务分析的三层框架”，我们一般和业务提出人探讨战略层面的主题，例如向他们了解对企业的规划、对业务的展望和期待。
业务管理者：对某一具体业务负责，可能是事业部负责人（例如M公司分销业务负责人），也可能是职能部门负责人（例如财务部负责人）。业务管理者作为业务结果的终极负责人向CEO汇报，并承载具体企业战略的执行和落地。业务管理者一般也是B端产品服务的终极客户，因为B端产品核心的价值就是帮助业务管理者达成业务目标。
我们一般和业务管理者探讨战术层面的主题，例如向他们了解业务的设计思路、策略、管控模式等，当然也并不绝对。
业务执行者：包括一线业务人员，以及一线的管理者；业务执行者负责业务具体的开展运作，也是B端软件产品最直接的核心用户。我们将一线管理者归类为业务执行者，是因为一线管理者并不为业务最终结果负责，一般情况下业务执行者只需要做好岗位要求的工作内容即可。
我们一般和业务执行者探讨执行层面的主题，例如向他们了解具体的业务运作流程、规则等。
业务协作者：包括企业内部配合相关业务部门开展工作的兄弟部门或团队，例如M公司分销业务开展中相关的仓配团队、财务团队，以及仓配相关的产品研发团队。
我们一般向业务协作者了解与执行层工作开展相关的内容。
企业外部
在业务工作开展中，企业外部的相关组织和人员，属于业务外部利益方，可能包括平台业务中的供给方、需求方，交易中的买方，以及外部合作机构以及第三方的技术服务商，等等，这些相关人员和角色也是产品经理在分析业务开展与调研工作中不可忽视的对象。
政策法规
政策法规是一类比较特殊的涉众，包括法律法规、行业政策、协会要求等。虽然政策法规不是自然人，但却在业务开展和执行中具有明确的利益诉求，并约束了业务的运作。例如金融类、支付类软件产品的设计，必须严格遵守银保监会的相关要求与规范。
在M公司的分销业务中，相关利益方如下。
?业务提出人：M公司的创始人兼总经理。
?业务管理者：分销业务的负责人。
?业务执行者：分销业务的运营人员、销售人员。
?业务协作者：M公司围绕分销业务的财务、仓储、配送、相关产品研发团队。
?业务外部利益方：M公司的供应商、从M公司购买生鲜品的客户、分销平台打算对接的第三方聚合支付公司等。
3.4.2 通过涉众地图分析利益方特征
在产品设计与项目管理工作中，常常通过涉众地图（Stakeholder Mapping）这个工具来分析不同利益方的相关特征。
我们首先通过“软件购买的决策权（影响力）”“软件使用的兴趣和利益（兴趣）”这两个维度，绘制一个四象限地图，如图3-7所示。
接下来，我们尝试将不同的利益方放置在四个象限的不同位置，完成涉众地图的绘制。因为不同类型的B端产品区别非常大，所以我们以业务型和工具型为例，分别探讨。
图3?7 涉众地图——二维矩阵
业务型产品的涉众地图分析
绝大多数的业务型和交易型B端产品，软件的购买决策人是管理者，使用人是执行者；同时，两者对软件的兴趣和利益都很浓厚，只是出发点不同：前者希望软件帮自己管理业务，后者因为每天都要使用软件，所以对此更加在意。
因此，我们将业务管理者绘制在第I象限，将业务执行者绘制在第IV象限。
业务提出人不一定关心软件系统的采购和使用，但作为一把手，同样具有采购的决策权，所以我们将其绘制在第II象限。
业务协作者和外部利益方，一般不会参与软件选型采购决策，但可能会用到软件功能，所以我们将其绘制在第III、IV象限交接，偏向于第III象限的位置。
业务型B端产品的涉众地图如图3-8所示。
图3?8 业务型B端产品的涉众地图
工具型产品的涉众地图分析
绝大多数的工具型和基础服务型B端产品，软件的购买人和使用人都是执行者。
业务执行者既具备购买决策力，又是软件使用最大的兴趣方和利益方，我们将其绘制在第I象限。
业务管理者作为业务执行者的上级领导，在工具的应用以及购买决策方面都可能介入，但相较而言程度要比执行者弱很多，所以我们将其绘制在第I、II象限交汇处，但位置更偏向左下方一些。
业务提出人，作为公司的最高层，一般情况下不会关心公司的具体工具软件的购买，因此我们将其绘制在第II象限。
工具型、基础服务型B端产品，可能并不存在业务协作者或外部第三方，即便有，关联性也很弱，所以我们将这两类涉众绘制在第III象限。
工具型B端产品的涉众地图如图3-9所示。
图3?9 工具型B端产品的涉众地图
我们总结绘制了两种典型B端产品类型背后的涉众地图，大家要注意的是，这里给出的只是参考示意，并非绝对的标准，目的是让大家产生思考。在实际工作中，即便是同类产品，基于不同的行业、客户规模，涉众地图也可能是不同的。
3.4.3 定义利益方的优先级
通过涉众地图，我们可以得出不同利益方在软件产品的购买决策和兴趣利益上的分布特点，这对调研工作有很好的指导作用，同时，也引发了进一步的思考：
?面对不同的利益方，究竟谁的优先级最高？
?我们的产品，究竟解决谁的问题？
?面对有限的研发资源，我们应该先满足谁的诉求？
?业务管理者不是最终用户，但却具备采购决策权，他们的需求，我们应该全力支持吗？
?业务执行者使用软件最频繁，但采购决策权较弱，他们的需求，我们应该全力支持吗？
?面对业务管理者和业务执行者利益冲突的情况，我们应该以谁的利益为主？
这些问题是软件产品设计前必须严肃思考并给出明确答案的，因为这是产品规划以及具体执行的核心指导方针，决定了软件产品后续的演进蓝图甚至商业成败。
如果我们对涉众地图的四个象限定义四个优先级策略，则具体分别如下。
?第一优先级：重点管理（全力满足诉求）。
?第二优先级：尽量满足（尽量满足诉求）。
?第三优先级：保持沟通（持续沟通，有选择性地满足诉求）。
?第四优先级：关注动态（关注即可，不用满足诉求）。
不同象限应该安排什么样的优先级呢？接下来，我们分别来聊一聊项目制和SaaS模式下的不同应对方式。
3.4.4 项目交付制的利益方优先级原则
项目交付制的软件产品是传统IT企业最经典的运作方式。在项目交付制中，客单价高，软件产品是一次性买断的，因此如何成功拿下客户是最重要的事情，在软件产品的设计实施过程中，会优先解决购买决策权比较大的利益方的诉求，即图3-10中被标记为灰色的第I、II象限的位置。
图3?10 项目交付制的优先级原则
象限I是最核心的服务对象，需要“重点管理”。
象限II是次重点服务对象，即便他们对软件使用的兴趣和利益不大，但因为拥有很高的决策权，所以依然要采取“尽量满足”的策略。
象限III不论是决策权还是使用软件的兴趣都很弱，是所有利益方中和项目、业务最不相关的群体，可以采用“关注动态”的策略，保持关注即可。
象限IV是软件的核心、重点用户，但因为其采购决策权较弱，所以在项目交付制中可能会采取“保持沟通”的策略，并不会优先跟进支持。
以业务型B端产品为例，通过涉众地图定义的优先级策略如图3-11所示，大家可以看到不同利益方在象限中的位置，以及每个象限的优先级。
图3?11 项目交付制模式下业务型产品的优先级原则
3.4.5 SaaS模式的利益方优先级原则
和项目交付制不同，SaaS软件按年收费，首年年费并不高，更看重客户的续费，因此，软件能不能帮客户解决实际问题，客户用得开不开心，变得更加重要，尤其是一线执行者，作为软件最直接的用户，是SaaS产品必须重点服务的对象之一。对于SaaS产品，更关心第I、IV象限中的利益方，如图3-12所示。
图3?12 SaaS产品的优先级原则
象限I是最核心的服务对象，需要“重点管理”，因为这一象限兴趣利益最大，购买决策权最大，当然是第一服务对象。
象限II采用了“保持沟通”的策略，这和IT项目制完全不同，SaaS要解决实际的业务问题，持续赋能客户，产生续费和增购更重要，因此，即便象限II中的群体拥有很高的购买决策力，但从SaaS模式的长久利益出发，并不是重点服务对象。
象限III和项目交付制的原则一样，“关注动态”即可。
象限IV又是一个和项目交付制处理策略不同的区域，在SaaS模式下，我们对象限IV采取“尽量满足”的策略，因为位于象限IV的利益方和业务强相关，是软件产品真正应该服务的重点对象之一。
依然以业务型B端产品为例，通过涉众地图定义的优先级原则如图3-13所示，大家可以将其和图3-11做一下对比，感受一下两者的区别。你也可以尝试自己绘制工具型B端产品在两种模式下的涉众地图，以及自己所负责的产品背后的涉众地图和优先级原则。
3?13 SaaS模式下业务型B端产品的优先级原则
以上我们探讨了在两种软件交付模式下，所涉及的不同利益方的优先级管理策略。不论我们设计的是内部使用的软件系统，还是商业化软件产品，不论我们采用了项目交付制，还是SaaS模式，都需要识别产品背后的利益方，并决定服务的优先级。想清楚这些问题，很多棘手的情况就都有解决思路了。
例如，假设你是一名设计给销售人员使用的SFA CRM的SaaS产品经理，如果客户老板普遍反馈希望加强拜访管理功能的约束和限制，但是一线销售人员又不希望增加这样的功能，那么到底该不该加呢？作为一名产品经理，首先应该思考的是老板希望这么做的目的和诉求是什么，有没有更好的双赢的解决思路，如果深刻分析后发现老板和员工在这件事上就是存在不可调和的矛盾，必须选择其一去支持，我想，此刻你心中一定有了答案。
还有个有趣的话题，有人说钉钉是一款给老板使用的企业协同工具，而飞书是一款给员工使用的企业协同工具，飞书代表了SaaS软件的最新实践理念，更关注员工和一线用户，释放了团队和个人的激情与活力。你认为飞书背后的利益方有哪些，位于哪个象限？飞书为谁服务？要解决的终极问题是什么？是谁的诉求？
