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