万字长文：B端产品经理修炼指南（防御矩阵异形入侵）

编辑导读：很多人对B端和C端的了解就仅限于，B端的客户是面向企业，C端是面向个人。事实上，两者的差异性还是很大的。本文作者将从产品架构、需求管理、业务理解等几个方面介绍B端产品经理的修炼指南，希望对你有帮助。

经常有人问我，什么是B端产品，我一般都会说，B端产品就是面向企业用户的，C端产品是面向个人的。这只是笼统的说，其实B端产品和C端产品的差异性还是很大的。今天就从产品架构、需求管理、业务理解等几个方面把B端产品仔细说一说，也欢迎大家一起探讨。

一、B端产品的本质

说B端不得不提C端。

C 全称是 Customer，即消费者（泛指用户）的产品，个人用户或终端用户，使用的是客户端。例如：微信、美图等等。

B 全称是 Business，即商家（泛指企业）的产品，通常是企业或商家，为工作或商业目的而使用的系统型软件、工具或平台。例如：阿里云、企业内部的 ERP 系统等。

B端产品和C端产品的用户不同：

C端：一个个鲜活的个体，多元化的个体，用户的年龄、职业、文化程度、收入水平、工作单位、个人喜好都不尽相同。他们的需求五花八门，他们的审美也不一致，C端产品要做到的就是满足一部分人一部分需求。用你的产品的用户也许会对某个功能设计很不满意，也不必在意，他可能根本就不是你的目标用户。

B端：B端产品服务于企业用户，这个「企业」可以是一个组织、商家、团队，是某种经营的主体，也可能是企业中的多个角色，例如在线客服系统，他的一线使用人员用这个系统和用户进行沟通，客服部门的管理人员用它的统计后台来管理客服人员，产品经理通过客服系统里用户问到的问题来提升和优化产品。所以B端产品需要满足一个系统中不同角色的不同的需求。

B端产品和C端产品的决策者不同：

C端产品只要用户感觉好用就行，但是B端产品的决策者不一定是使用者，一个企业的客服系统，不是客服人员决定使用哪家的，一个企业的OA系统也不是企业员工来决定的，B端产品的决策者比较看重产品能够为企业带来的实际价值，决策者关注的重点无非就是两个，多赚钱和少花钱。

需求方可能更关注是否能提升本部门员工的 KPI和话语权，而不是是否降低成本。需求方是To B产品在线上推广时的主要目标用户人群。使用者的需求其实和 C端用户的需求很类似，关注的是能不能解决问题，使用是不是流畅，界面是否好看。所以一般B端产品的销售人员面对企业的不同的角色会着重介绍产品的不同优点。

C端产品重定位以及交互能力，B端产品重架构以及抽象能力。C端产品是解决了用户的某个需求，B端产品是为了提升企业业务中的某个能力。B端产品的本质是为了降本增效。

二、B端产品经理的大架构观

B端产品一般都会包含两个以上的角色，功能比较复杂，考虑的场景比较多，整体架构必须是从上到下的，做B端产品经理，必须要有大架构观，当然架构难度越大，对产品经理要求越高。在所有架构设计中，最为复杂的，往往是多组织架构设计，架构能力不仅仅体现在模块之间的集成关系，也体现在模块内部的功能细节。

产品架构设计核心主要是抽象建模，主要涉及到：

归纳法：归纳法是在大量经验的基础上进行分门别类，总结到其内在规律和梳理几大板块。归纳的时候要尽量整合尽可能全的场景，特别是要做中台产品时，难度是很高的。所以在进行产品架构设计前，一定要尽可能全面的去了解各类典型的场景，和有经验的人多交流。
演绎法：在归纳法的基础上基于演绎法去推演系统如何去支持可能延伸的需求，用来验证当前的架构设计是否合理。

除了产品架构，还有业务架构、信息架构和技术架构，这些和产品架构是什么关系呢？

业务架构：为了达到业务目标（通常是商业目标）所搭建的业务体系和商业模式，比如著名的亚马逊飞轮效应和Google搜索的印钞机模式。
信息架构：主要是产品在结构层的一部分，通常是在交互设计阶段考虑的产品给用户呈现的产品全貌，让用户可以清晰快速的找到功能的策略。
技术架构：在一些偏向技术型的产品里，产品架构和技术架构很接近，比如云计算产品，其用户本身就是程序员，所以云计算产品的产品架构和技术架构就很接近了。

好的产品架构一定要有高可用，即在多业务产品组成的产品矩阵中，每个产品可独立交付价值，也可组合成不同的解决方案。高可靠：在单一产品内，基于解耦化和模块化的设计，对模块类逻辑的调整，其复杂逻辑所造成的影响往往控制在模块内，模块之间依然还是通过定义好的输入输出进行交互。可扩展性高：在单一产品内，基于模块化定义好的规则，不需要事无巨细的了解整个产品的所有细节逻辑就可以快速扩展产品功能。

所以B端产品经理在提需求时要考虑以下几点：

考虑系统边界：哪些能做，哪些不能做
考虑系统承载能力：例如产品的并发和压力测试
考虑功能的灵活性和可扩展性：例如不同渠道的对接是否支持，不同模块的单独售卖是否支持
考虑极端和异常：例如上传下载的文件大小的限制
考虑基础功能：例如注册、找回密码、修改密码等基础工作。

例如有赞在产品设计就提出以下原则：

1、首先要是能够最小可用的全场景闭环。

商家端的产品要做成全场景、完整业务链路的闭环，因为任何一个环节的缺失和不完善都会导致商家的生意无法正常运转。

2、每个商家都应该是独立的个性化的。

商家都是独立的，每一个商家都有个性化配置一切的权利。实现每一个商家的独立和每一个商家的个性化，而不是规定他们一定要怎么样。

3、产品结构及呈现方式需要可延续可拓展。

一个被信任的商业服务产品首先应该是持续稳定的，产品的结构和呈现方式一旦确定下来，就不能轻易改版。这要求设计需要面对业务变化的时候可延续，面对功能和服务增加的时候可拓展。

三、谁要理解业务

B端产品经理应该是行业专家：

B端产品经理应该是行业专家，B端产品经理要培养10个自己的核心用户，亲自为他们服务，这样才能做到充分了解业务。那么都要了解哪些业务呢？

行业信息——行业分解认知、行业组合认知，行业规模
行业分析——业务流程、产业链、商业模式，行业上下游分析
行业常识——业内典型企业与领导者，行业的地域分布

技术同事要不要了解业务：

我只是负责写代码，不用了解业务，只需要了明白产品经理的需求文档就可以了，但是产品经理的需求文档，是基于业务来的，如果技术同事能够了解业务情况，就能够更好的了解需求文档。

技术同事了解业务后，能够更高效的了解需求，知其然还知其所以然。这样在和产品沟通过程中更高效，甚至，技术同事也许能根据业务和技术提出更好的解决方案。

所以这就需求产品经理完成以下工作，帮助技术同学了解业务：

需求文档尽可能多写一写业务描述
定期对技术同事做业务培训
技术同事参加部分测试工作
带领技术同事去业务现场参观

当然技术同事了解业务的前提是产品经理要首先了解业务，个人认为，了解熟悉业务是B端产品经理所有工作内容中比重最大的部分，如果这些做不到，那么做出的产品就是无根之水。那么如何了了解业务呢？做充分的需求调研。

四、怎么做需求调研

竞品分析：

竞品分析不仅仅是分析竞品的产品，而是要全面分析，例如分析竞品的业务指标，分析竞品的战略部署，分析竞品的资源有哪些，分析竞品的演化路径。

做竞品分析只有做深了才能有价值，要知道竞品也是投入了大量的人力物力和资源再做，他们也是有一大批的聪明的人在规划，所有的动作都是经过深思熟虑后才做出来的，他们有大量的经验可以直接哪里使用。

做竞品分析最好的案例，大家可以去了解一下中国高铁，当初如何获取到世界上最先进的高铁技术，以技术换市场的方式快速吸收竞品技术，并为我所用。

在一个成熟的行业，找到几家成熟的竞品，重复做好分析，能起到事半功倍的作用，或者说前期花1个月的时间做竞品分析也不为过。那么该如何做竞品分析呢？

试用竞品产品：冒充用户，注册试用账号，找竞品的用户，借用账号。这方面就八仙过海，各显神通了。
面试对方岗位：投递地方岗位，通过面试和对方负责人或者相关人员详谈。面对面和对方核心人员聊天也是一个也是一个不错的方法。
面试对方的离职员工：约竞品的离职员工来详谈，获取一些竞品信息。
参加竞品高管的演讲会议：高管出去做分享演讲，一般会释放一些有价值的信息，例如产品核心战略方向等。
全网收集竞品的新闻稿件：一般企业用户的新闻稿件能够挖掘出一些有价值的信息，例如竞品的合作伙伴信息或者产品新功能上线信息。

问卷调查：

问卷调查主要是通过问卷方式，让调研用户的做一些选择性题目，通过回收问卷分析一些相关指标。那么明确调研目的，才能根据目的制定调研题目。一般题目不要太多，太多了会消耗用户的回答的耐心，从而影响回答准确性，从而使得调研结果失真。

用户访谈：

用户访谈在过程中可以与用户有更深入、更专注、更有质量的交流，通过面对面沟通、电话、网络视频、都可以与用户直接或间接进行交流。根据不同的研究目标，访谈可以分为设定主题方式和开放式。访谈目的避免出现假大空的情况，要去沟通并明确目的，尽量把目的和背景范围缩小，提前做好访谈提纲。通常一对一的访谈应控制在1个小时之内，多对多则控制在2小时之内，太长的访谈时间容易对用户会造成负担和疲劳，用户会为了赶紧结束交流而不经思考、草率回答。

数据分析：

数据是不会说谎的，竞品的数据能给我们提供一些决策依据和验证我们的一些设想。做数据分析，主要是三个方面：

要了解哪些数据：不同行业主要关注的数据指标是不一样的，所有一定要明白自己业务的核心数据指标有哪些？例如用户规模数据、付费用户数据等。

怎么了解到这些数据：收集数据就需要一些数据工具产品，行业类的数据服务，通常会提供一些行业分析报告。这类型的数据都是从全局去看待整个行业的现状以及未来的趋势。部分有特色的另行说明，例如:

艾瑞：艾瑞咨询，会发布各种互联网行业研究报告。而艾瑞数据，可查看移动app/ pc web/ 网络广告/ 移动设备/ 海外app/ 微信小程序等指数，实时性较低
极光大数据
CBNData（第一财经商业数据中心）
TrustData
360研究报告：数据安全方向
艾媒咨询
麦肯锡

如何分析这些数据：

这个要先跟你的行业和产品，确定你有收集哪些数据？例如智能客服行业，要收集的数据一般是：客户数、产品价格、活跃用户、销量、甚至是销售人员数量。根据他的客户数量和产品价格，基本可以核算一下销售额，根据销售人员数量初步判断他们的产品的销售策略。如果可以获取他们的服务客户类型，也可以判断他们的产品的适用领域。

头脑风暴：

在需求不明确或者需求挖掘阶段，可以通过头脑风暴方式明晰需求。一般头脑风暴要有一个主持人确定一些规则，设计公司 IDEO 的头脑风暴的七条守则：

暂缓评论（Defer Judgment）先不要急于对别人的观点发表是非对错的评论，这样会打击提出点子者的积极性，先提后评。
异想天开（Encourage Wild Ideas）华人总是怕自己说错话，在别人发言时，脑子想的是“我要怎么讲是对的”、“我要怎么讲才能表现我的水准”。这是因为我们缺乏允许异想天开存在的环境，只有让异想天开大行其道，才能鼓励每个人真正去思考设计，而不是思考自己的水准和对错。
借“题”发挥（Build on Ideas of Others）有些时候别人会提出来很疯狂的点子，你自己虽然是专家，知道行不通，但在座的很多不是专家，说不定听到这个疯狂的点子会得到启发、获得灵感，在这个疯狂点子的基础上，提出更实际的方案。所以，只有在暂缓评论的环境下，才能让更多的人借异像天开的点子发挥。因此前三个规则是鼓励出好点子的环境基石。
不要离题（Stay Focused on Topic）每一次讨论，要定一个明确的题目。不然的话异想天开的结局是不能收敛。
一次一人发挥（One Conversation at a Time）讲话的时候，一次一个人讲，不要七嘴八舌的。这样就没办法做记录。
图文并茂（Be Visual）鼓励大家在想点子的时候，把这个点子用图案的方式画出来。你不是很会画图也没关系，这是因为，有时收集了很多很多点子张贴在墙壁上，也许有几百个，你过几天再回去看，如果只有文字的话，有的时候会想不起来这到底是什么。所以画图可以帮助记忆。
多多益善（Go for Quantity）在一个小时之内，鼓励大家尽量讲，要讲究速度！IDEO 公司内部一般一个小时可以汇集 100 个点子。如果与客户一起合作脑力激荡的话，因为企业文化和习惯的不同，这个数字会相对少一些。

五、如何做需求分析

何为需求？需求=预期-现状，B端产品基本上是将「线下已有需求」系统化，所以需要「还原业务」，而非「创造业务」。

当需求收集来之后，就需要做减法了，一般分为以下几个步骤：

需求过滤：产品定位，我们获得需求后，落地执行前，第一个要考虑因素。只有符合产品定位的需求，产品才具备落地价值。对应不符合定位的产品需求，要舍弃，对应技术不能实现的需求要舍弃，对应投入太大，不足以支撑的需求要舍弃。所以，我们在收到需求后，落地执行前，自己要先评估需求，过滤需求。

需求合并：有些需求是抽象了之后可以合并的，例如导数运营数据的需求和数据看板的需求其实是类似的，在开发之前可以合并成一个，如果面板数据足以满足了导数数据字段，是不是可以舍弃导出功能。

需求分类：需求分类一般会有两个维度，

第一是按照需求的类型一般分为：

新功能需求，业务部门新提交的功能
优化需求，这里涉及到文案优化、设计优化等

第二可以用KANO 模型对需求进行分类，分别是：基本型需求、期望型需求、兴奋型需求、无差异型需求、反向型需求。

基本型需求：也称为必备需求、理所当然需求，是用户对产品或服务的基本要求。是用户认为产品“必须有”的属性或功能。当其特性不充足时，用户很不满意；当其特性充足时，用户也不会因此而表现出满意。
期望型需求：是指用户的满意状况与需求的满足程度成比例关系的需求，此类需求得到满足或表现良好的话，用户对产品的满意度会显著增加。
兴奋型需求：又称魅力型需求。指不会被用户过分期望的需求，但一旦得到满足，用户满意度也急剧上升。即使还不完善，用户变现出的满意状况也非常高。反之，即使没有满足，用户也不会因而变现得不满意。
无差异型需求：不论提供与否，对于用户体验无影响，它们不会导致用户满意或不满意。
反向型需求：又称逆向型需求，指提供后用户满意度反而会下降，而且提供的程度与用户满意程度成反比。

六、如何做好需求管理

1. B端产品经理要做好流水账

B端产品经理要学会写流水账，B端产品架构复制、流程复杂、角色复杂、需求来源也复杂，好多B端产品再做的过程中，产品经理都发现之前的需求自己都不记得了，好脑子不让烂笔头，做好流水账，你会发现流水账能解决很多问题。做需求管理每个产品经理都要有一套自己的科学的方法论，如果没有的话，建议大家考一下PMP。

2. B端产品经理要不要学PMP

什么是PMP：

PMP是项目管理专业人士资格认证，由美国项目管理协会(PMI)发起，严格评估项目管理人员知识技能是否具有高品质的资格认证考试，其目的是为了给项目管理人员提供统一的行业标准。

PMP学什么：

熟悉项目监控，项目评审的主要内容与方法。掌握风险管理的主要内容及其分析工具和规避手段。培养具备项目管理专业素质，技能全面，高水平项目管理能力的项目人经理。

PMP考什么：

PMP试卷是200道单项选择题，中英文对照，其中25道题目不计分，计分题答对106道就可以通过考试，不计分的题是按照正确率最高和最低的来选择的。每年四次考试。考试是选择题考试时长4个小时，报考条件：需要35个学分、要有工作经验，考试通过率比较高，每三年要付费续证。

PMP要考吗：

有时间有钱=要考，可以让自己系统的学习项目管理的方法论，让自己的产品经理技能和知识系统梳理一下。

3. 优先级划

不能从一个维度来确定，要多个维度的统一分析后得出的优先级，不同的行业的不同维度的权重不一样。一般会从这几个维度来给每个需求打分。

用户价值
商业价值
成本（战略成本、开发成本）
产品周期
战略方向

打完分之后，将需求放到四个象限，将需求分为：重要且紧急、重要不紧急、不重要但紧急、不重要也不紧急四类。

然后按照：紧急重要>紧急不重要>重要不紧急>不重要不紧急排优先级。

B端产品的进化是一个漫长的过程。产品经理是必须对项目结果负责，以价值结果为导向的，所以我们在项目的各个环节都要主动思考怎样让项目更顺畅的完成，以及各个环节自己能做哪些事情。

要想快速推进项目，最快最好的方式是和整个团队达成共识，减少不确定性，增加确定性，这样才能提升整个团队的工作效率。

七、不能商业化的B端产品是废物

1. 学会商业画布绘制

刚跨入产品经理这个行业的时候，我们会认为做需求、画原型、写需求文档，就是产品经理的职责，只要将产品的所有逻辑梳理清晰，我们就能做好产品。随着经验的增长，我们会发现做好需求、画好原型、写好需求文档只是做好产品的开端。

企业做产品通常分为3个阶段：创造价值、传递价值、获取价值。创造价值、传递价值、获取价值是企业商业行为的一个有机整体，是企业商业模式的体现。

产品经理在未来的职业发展中，不能一味的考虑如何研发产品，更重要的是对整体商业模式的思考。良好的商业模式是保证产品各项稳定的唯一途径，也是衡量产品价值的唯一标准。

例如，B端产品的销售策略与C端不同，B端产品的决策者和使用者不是同一类人。决策者往往是企业领导层，使用者是一线员工，因此，B端产品在设计时，首先要额外关注领导的需求，保证与领导高度相关的功能的可用性和易用性，例如统计分析、报表导出等辅助经营决策的功能。

商业模式设计的理论体系非常完整，已经发展了上百年，如下图商业画布模板，大家可以参考相关的经典书籍系统性的学习。

互联网的商业模式大家应该并不陌生，包括产品直接付费、广告流量付费和线上、线下服务付费等。基于商业模式的思考，衍生出很多方法用于商业模式的分析。

商业模式画布是帮助个人和企业分析如何创造价值、传递价值、获得价值流程和关系的基本工具。商业画布更体现了一种商业领域思维方式，它能够展现企业在商业链条中的地位。

在产品全生命周期的过程，应该在产品开发前、开发中、产品上线、产品运营甚至产品退市等各个阶段，都利用商业画布对产品进行分析。产品经理要尽可能多的参与商业模式设计，多与老板沟通，多提出自己的想法，在商业模式设计方面老板通常更有前瞻性。

2. 避免“销售驱动”

一般的B端产品都是“销售驱动”，销售驱动的一大特点是，产品研发的重点落到了某些特定的客户上，代价是牺牲了产品核心价值的创新、新的功能、质量提升和技术优化。

用这种“驱动方式”发展下去的产品，首先是可以服务好一两个大客户，或者前期更容易开拓市场，但是最终会失去寻找到真正不可替代的价值点的机会，甚至发现“销售驱动”的产品变得更难销售了，更不用说能成为Scalable的商业模式了。

可怕的是，团队可能往往意识不到为什么到达了这种地步，甚至没有意识到出现了问题。因为大家认为有人愿意花钱就是有价值的产品，实际上，公司已经从卖产品发展道路卖人力的路上，所以首先，我们应该应当想清楚。产品的服务边界到底是什么，销售过程中是绝对不能承诺的。

我们做的是B端产品，不是项目，做项目，就是一两个程序员往客户那一驻扎，您说你想要啥我们就做，做完您看行就验收，不行我们再改，觉得没问题我们就回去了；做产品，是标准的，不会特意为客户修改，您要觉得拿点不顺眼不想买了我也没办法，我们不修改，我们不改您就不买我们也没办法，您要买了，那我们就上门安装、实施，就这样。

当然，也不是说用户不能提需求，要知道哪些需求是正确的，哪些是不能做的，这就需要产品经理做好评估，并说服老板和销售

正向评估：如果做，能使哪些用户在什么场景受益？用户会因此使用、消费、甚至推荐我们的产品吗？

负向评估：如果不做，是否会造成用户口碑变差，甚至弃用我们的产品？

数据导向：预估这个需求对大盘数据（AARRR）有何贡献？如果无法在短期看到对大盘数据的直接提升，应该取什么样的数据指标来评估其价值（GSM模型）？

做了这个需求正确的数据应该是：活跃用户数增长、企业平均账户数增加，以及最重要的——边际成本持续降低。

八、总结

什么是好的产品：解决用户需求、有足够的粘性，用户体验好，有盈利的模式。想一想你家的产品满足这几个点吗？