六大层面看BC差异

B端产品相较于C端产品，在用户、需求、产品设计、迭代、运营、商业六大层面都有哪些差异？
（《不枯燥的B端产品实战课》（2021年1月 周翔））
【PS：以分析B端特点为主，比其他说差异点的文章深入，作者的切实感受，不空洞。需求、设计部分值得多读几遍。】

用户

A.用户概念繁多且分离：

业务方：产品所服务业务领域中的人员的统称，也可以说是产品主要用户的统称。例如，一个内部的测试管理系统，其业务方就是所有测试人员、开发人员、产品经理等。
业务代表：业务需求沟通时的代表，也可以称为业务领域专家，是对业务非常熟悉的人，负责日常的需求沟通、上线验收等工作，也是产品未来的主要用户。业务代表可以是一个人，也可以是一个团队。
客户：购买产品的组织，而非具体的个人。例如，某个购买CRM系统的公司。
客户代表：产品在销售过程中与卖方沟通谈判的代表，一般都是产品未来的主要用户。
购买把关人：相关人员在与客户代表谈判过程中，可能会有其他人员帮助客户从某一方面进行把关，这类人员就是购买把关人。例如，某个公司想采购CRM系统，采购需求的沟通由销售部的人员来完成，但会邀请信息技术部的人员从技术层面进行把关，信息技术部的相关人员扮演的就是购买把关人的角色。
客户决策者：决定最终是否购买产品服务的拍板人，一般都是部门领导或企业管理者。决策者可能是产品未来的用户，也可能不是，这个差异决定了决策者介入购买谈判过程的程度，也影响决策者对产品功能的关注程度。
为什么C端产品的用户不需要区分这么细致，而B端的用户需要呢？

这是因为C端的用户概念指向的都是同一个人，需求和职责是统一的，因此在做C端产品用户分析时概念不需要区分得这么细。而在B端场景中，这些概念所指代的并不是同一个人，是分离的，这就意味着不同概念所指代的人的诉求不一样、关注点不一样、与产品的联系不一样、对产品的影响力也不一样，所以在做B端产品用户分析时就需要把每个概念进行细致区分。

两种分离

1）业务代表与使用者分离
一般来说，业务代表是产品的重度用户，也是业务领域中的专家，所以B端产品经理无论是在调研需求时还是在日常沟通中，都主要与业务代表打交道，这样做可以确保B端产品经理对业务相关内容理解的准确性，但业务代表并不能代表所有B端产品的使用者，B端产品经理如果只跟业务代表进行沟通，就会出现以下几个比较严重的问题。

• 遗漏其他角色的需求。业务代表所代表的用户角色毕竟是有限的，无法做到面面俱到，如果B端产品经理只关注业务代表的需求，会使产品的功能不完整，不能很好地满足其他角色的需求。
• 需求失真。即使业务代表帮助B端产品经理收集了其他角色的需求，在转述过程中也会出现需求失真的情况，对于有的需求，B端产品经理如果没有深入到用户场景中，很难理解用户真正的痛点。甚至对一些Bug，由于B端产品经理没有深入了解，也容易出现误判。
• 优先级干扰。B端产品经理在向业务代表征集需求时，很容易出现“领导需求优先，业务代表需求优先”的情况，而其他角色的需求则会被有意无意地弱化，对B端产品经理判断需求优先级产生干扰。

解决方案：B端产品经理要有意识地降低业务代表与使用者分离造成的影响，主动与其他角色用户沟通，了解他们的需求和想法。
2）决策者与使用者分离
对于需要付费使用的B端产品，决定是否购买这款产品服务的，一般都不是产品的最终使用者，而是组织的领导者，使用者在购买决策阶段更多的是站在使用和体验角度给出参考建议。
所以如果要想产品有更多的付费客户，B端产品经理不仅要分析使用者的需求，还要重点分析客户决策者的需求，并尽力满足，这样才有更大的概率拿下这个付费客户。
【PS：消费者购买决策过程中的角色可以分为五种：即消费的倡导者、决策者、影响者、购买者和使用者。】

B.产品角色多样且明确

对于大多数的C端产品来说，不同用户都是基于至少一个共同的核心诉求，才会不约而同地选择同一款产品。例如，小明想看球赛，小红想追偶像剧，他们基于一个共同需求——看视频。他们的产品使用权限都是一样的，最多有个会员与非会员之分，因此C端产品经理在分析用户及其需求时大多不需要做角色上的区分。

角色：产品中具有相同权限用户的合集。

如果需要区分角色，要么会把不同角色使用的产品分为不同的产品端，如打车产品的乘客端和司机端；要么就是角色种类极少且权限简单，可以很方便地进行融合。
在B端产品中，产品的角色复杂多样，这些角色有的与实际业务有对应关系，有的角色则是根据产品需要而设定的，如管理员。
【PS：业务需求，产品需求（系统强加给用户的）】
另一方面，这些角色是非常明确的，根据实际业务和系统管理上的要求很容易将其抽象出来，不需要产品经理深入挖掘就能发现。例如，一款HRM系统中的HRD、HR专员、部门管理者、普通员工、系统管理员等。
【PS：虽然角色明确，不需要深入的挖掘，但对于产品新人来说，熟悉业务仍有很大的挑战。此外，也能表明“默认角色”的重要性，角色的功能权限配置比较鸡肋。但是需要注意数据权限与“分级管理”。】

C.“特权”vs“平权”

即使C端产品经理在内部做用户切片时会对用户的重要性进行区分，但在服务用户时也一定是以“平权”为原则的。每个用户的重要性是一样的、权力也是一样的。
【PS：关联知识——用户分群，用户分层，用户画像，价格歧视】
在B端产品中，经常出现“特权”现象（中性词，无褒贬之意），它包括角色特权、人员特权和客户特权。
1）角色特权：不同角色对产品的使用权限大小不同，这与实际业务中的管理要求是相呼应的。
2）人员特权：B端用户的决策者与使用者通常是分离的，为了保证客户的续费率，会对购买决策产生决定性影响的人员进行重点关注，给予其更多的“特权”，他们的需求会优先响应，当决策者与使用者的需求相矛盾时，在无法折中的情况下，B端产品经理也会以决策者的需求优先满足。
3）客户特权：通常会根据付费金额、影响力对客户进行分类，其中有影响力的、付费高的客户会享有一定“特权”，他们的需求会被优先满足，销售团队会对其进行重点服务、跟进、回访，有的大客户还可以享受定制化服务，这就是客户特权。
无论是哪一类特权，都是B端产品经理在综合考虑业务需求、投入产出、资源等多方面因素后做出的正常且合理的处理。

需求*

1.业务方主导

在B端产品中，一般是由业务方主导需求，大多数的B端产品经理主要起到接收、分解、传递需求的作用。B端产品经理更像是一个画原型的“工具人”，在工作中也会缺少一些成就感。

• 业务复杂。通常情况下，如果B端产品经理之前没有相关业务经验，很难快速掌握足够多的业务知识，更不可能在短期内成为业务专家，因此就需要业务方的相关知识和经验做指引。
• B端产品经理经验不足。由于B端产品解决的都是专业领域中的痛点，这些领域大多对产品经理来说比较陌生，很多时候产品经理都不是自己所做产品的用户，因此很难真正理解用户想要什么，而业务方作为产品的重度用户，自然更有发言权。

在实际合作中，业务方主导的程度与多个因素有关？

• 业务特点。如果一个产品本身就没有业务方，或者业务方只是简单地提一些需求，没有其他硬性要求，那就不存在业务方主导一说了。
• 业务方的强势程度。如果遇到一个比较好沟通的业务方，愿意听从B端产品经理的建议，那么产品经理就能从自己的角度做出引导。
• B 端产品经理对业务的熟悉程度。对业务越熟悉，就越有主导权。业务方都听他的，因为他知道哪里会有坑，哪个需求没用。

【PS：关联话题：如何做引导？如何拥有主导权？如何快速熟悉行业和业务？快速成为业务专家？麦肯锡的一些方法。基于组织架构的业务分析方法。顶层设计，先进理念，咨询服务，平等对话。业务领域不强，产品领域补上长板。】

2.角色差异大

B端产品的角色复杂多样，每个角色基于自己的岗位和工作职责，对产品的需求也不一样，甚至完全冲突。比如，管理者想要更严格、更精细的管理系统，而被管理者则希望拥有更灵活、更自由的空间，这种核心诉求的冲突是无法调和的，而且不可能达到完美平衡，所以做出取舍也必然会伤害某些用户。
我们不能简单地采用“领导需求优先”的原则，而需要结合更多的标准，进行综合评估。
【PS：B端产品如何采集、分析、处理需求？】

3.相对明确且稳定

在C端产品领域中，用户需求是模糊的和动态的，需要产品经理深入调研挖掘，并能够根据用户需求的变化，调整产品的功能。很多时候即使C端产品经理做了调研，做出来的功能用户可能也不买账。而在B端产品领域中，每种角色的需求相对更明确，不过这与业务所在行业的成熟度有关，一个行业的成熟度越高，需求就越稳定，业务场景也越明确。
即使由于不同组织管理制度上的差异导致需求变化，相比于C端产品的需求还是要明确得多的。只要业务上的管理规则确定了，产品需求就可以视为明确了。
【PS：C端需求的特征？教育信息化行业的成熟度模型？模糊动态VS明确稳定。】
B端产品的需求稳定性很强，只要业务规则不变，同一角色的需求都是差不多的，也正是因为这一特点，B端产品能够表现出极强的生命力，其产品周期相比C端产品要长得多。

4.集体性强

集体利益优先：当个人诉求与集体利益冲突时，个人诉求需为集体利益让步。比如钉钉的信息接收方“强制接收”，以提高企业内部的沟通效率。
角色需求趋同：同一角色，无论用户的数量有多少，在这个角色背景下，用户需求基本一样。
任务多人协作：围绕同一目标，各有分工，协同完成任务。比如申请单的审批流程。另一个在B端产品中常见的多人协作场景是“对于同一目标，多人都有操作权限”，权力为集体共有。比如多人拥有对同一项目的编辑权限。

5.逻辑复杂

B端产品有着烦琐的流程、复杂的规则、错综交织的实体关系、不同角色权限的相互影响等。一个小小的需求变动，往往“牵一发而动全身”，如果B端产品经理没有极强的逻辑思维能力和抽象能力，在梳理需求时就很难发现这些关联点，轻则无法较好地评估工作量，重则前后逻辑自相矛盾，产品出现重大Bug。（与业务规则相关的文档一定要及时维护、保存，当遇到问题时方便及时查看。）

6.高门槛，低差异

C端产品因为与其相关的知识容易理解、规则逻辑简单、日常接触竞品比较便捷、使用频繁等，显得对“新产品经理”友好很多。
隔行如隔山，B端产品经理要想在短时间内学习足够的业务知识并将其理解透彻，显然有些不现实。比如一些如保险、金融产品不仅业务知识复杂，还涉及法律法规。
【PS：C端产品领域的高门槛是隐性的，比如社交产品，规则简单，做好很难。】
B端产品一旦跨过了这个显性的高门槛，竞品间就会越来越相似，差异化程度也会越来越低。这是因为业务的行业痛点是大同小异的，在解决行业共同痛点时，不同B端产品的解决方案是趋同的，且因为模仿成本和难度较低。一旦出现一个比较好的解决方案，很快就会被竞品模仿，因此B端产品很难从产品功能角度建立明显的优势。
【PS：B端产品如何建立优势？销售渠道，服务，时机。】
【波特提了三种卓有成效的竞争战略，它们是总成本领先战略、差别化战略和专一化战略。】
查看>>波特三种竞争战略

7.定性调研为主

需求调研分为定量调研和定性调研两种。C端产品在进行需求调研时一般两种方式都会用到，而B端产品在进行需求调研时则是以定性调研为主的，主要有以下两个原因。

• B端产品用户需求具有集体性。你只要调研清楚一个角色中的一两个用户的需求，就足以涵盖这个角色中用户的绝大部分需求。
• B端产品不同角色的用户相比于C端产品不同角色的用户要明确。而且B端产品的用户更加配合调研，愿意深入参与需求调研过程，帮助产品经理了解业务、了解需求。

【PS：需求具有集体性，所以打造标杆很重要，“定制化”阶段“打磨”产品很重要。参与配合。】

产品设计

这里的设计层面是指B端产品在设计方法和体验设计中所表现出来的特点。

1.高度灵活

高度灵活是指为了让B端产品满足更多场景需求和应对未来可能遇到的问题，降低产品变动的频率和开发成本，B端产品经理在设计产品时需考虑产品的高度灵活性，以达到在不改动或只是小改产品的情况下就能满足更多需求的目的。灵活性体现在产品功能设计和产品架构设计两个方面。
“设置”可以说无处不在，大到导航菜单，小到某个字段名称，可能都需要自定义设置，以达到B端产品要求的高度灵活性。
B端产品为什么需要这么高的灵活性呢？

因为对于B端产品而言，虽然在不同组织中，产品的业务领域是一样的，但在不同组织中，其业务领域中的制度、流程不完全相同，这些制度、流程都是长时间根据组织内部实际情况和管理方式逐步沉淀形成的，组织不可能为了适应你的产品规则而改变组织制度。

【PS：B端产品的配置？参数管理】

2.相对易用

使用B端产品时，在体验方面总感觉不太好，出现这种现象的原因主要有三个：
A.资源限制：
B端产品“重功能，轻体验”。B端产品经理会着重把精力放在功能设计上，对用户体验不那么重视，尤其在做内部系统时，总会用着一种“都是自己人，能用就好”的心态对待产品的功能设计。由于资源有限，公司也不愿在供内部使用的系统上投入过多资源进行优化。
B.业务复杂：
B端产品作为一个解决业务问题的工具，其用户体验往往与业务的复杂度成反比。如果一个产品业务本身就流程复杂冗长，那么产品经理对其优化的空间就会很有限，最终必然导致用户使用产品时的学习成本、使用成本非常高，用户体验就会很差。
C.产品特性矛盾：
B端产品要想有更大的市场，就需要拥有高度灵活性，能够灵活配置各种功能，但灵活性与易用性在跨过一个平衡点后就会相互制约，关系如下图所示：

在两者到达平衡点前，产品适度的灵活性能给用户带来良好体验，用户可以根据自己的需求对产品进行设置。例如，列表的自定义排序功能，不同用户在不同场景下的排序需求可能不一样，提供自定义的排序功能，能满足用户的个性化需求，提升用户体验。
但是，当灵活性提升到一定程度后，就会降低产品的易用性。因为产品的灵活配置意味着用户需要付出更高的学习、理解、记忆成本，才能将产品的功能配置成自己需要的，这时的体验自然不会很好。
另外，这个平衡点的位置因人而异。如果是一个之前用过同类产品的用户，对产品的灵活性的要求就会更高，但如果是一个“小白”用户，那最好只给他一种模式，因为每多一种配置，他都要理解新配置的意义和用法。
【PS：观点精辟且深刻。】
3.交互UI弱化
B端产品交互方式、UI设计要简单、朴素很多。
一是因为很多B端产品对这方面的要求不高，用户更多关注的是B端产品的功能。二是因为B端产品的页面形式多以表单为主，设计师可发挥的空间有限，多是给一些配色和排版布局的建议。
部分公司使用的内部产品，甚至连前端资源都没有，都是后端开发人员利用开源的前端模板来做的，如easyUI、bootstrap、vue.js+es6、Extjs（收费）等。
【PS：设计资源冗余，饱和式设计，常见的前端框架。】

迭代

1.0版本大而全

如果B端产品的MVP版本作为产品推向市场的1.0版本，那根本起不到验证产品对用户痛点解决程度的效果，因为没有B端客户会为一个“残次品”买单。
MVP由Eric Ries在《精益创业》一书中提出的，意思是最小化可用产品。
1）外：对客户而言，B端产品使用成本高
对任何一位客户来说，即使一款B端产品最初不收取任何费用，也没有谁愿意当小白鼠，因为一旦使用该产品，至少意味着公司人力成本的投入，如果没有获得预期的效果，那就是真金白银的浪费，所以B端产品的客户在选择、使用产品时要慎重许多。因此如果B端产品没有达到比较完善的状态，不能从一开始就满足客户大部分的需求，B端产品的客户是不会像C端产品的用户那样轻易尝试一款新产品的。
2）内：对团队而言，试错成本高
产品从稚嫩走向成熟，都需要经历一个过程。对于B端产品来说，在自身不够成熟的时候将其推向市场，就会把产品不完美的一面展现在客户面前，导致客户对产品产生怀疑，失去信心，这时他们就很有可能开始使用竞品，而一旦客户开始使用竞品，就很难再挽回了。如果流失的是潜在的大客户，对公司来说损失更大。

因为B端产品客户使用和转移产品的成本很高，所以B端产品客户的试错成本要远高于C端产品客户的试错成本，在这种情况下，B端客户对产品的信心极难建立，且非常脆弱，一旦产品在功能、稳定性、体验等方面没有达到客户的要求，甚至给客户带来了较大的负面影响（如因为系统不稳定导致数据丢失），基本就意味着永久失去了这位客户。所以，为了避免客户流失，B端产品需要达到一个很高的“成熟度”才能进行“商业化”。但是，如果要让团队“闭门造车”一两年才将产品推出市场，成本、风险都很高，一旦产品没有一定规模的市场，意味着公司这一两年的投入全部泡汤了。所以我们就需要一个既能帮助我们验证产品是否能够满足业务需求、解决业务痛点，又能给产品足够的时间进行逐步完善，还能让产品在完善的过程中也能发挥一定作用的过程。而这个过程，就是我们前面提到的定制化阶段，找到“小白鼠”，打磨产品，打造标杆案例。

【PS：白鸦全方位揭秘有赞的产品设计原则https://www.uisdc.com/youzan-product-design】

小步快跑，稳步上线

在《精益创业》这本书中，Eric Ries提出了互联网时代新的创业法则——小步快跑，快速迭代。后来由马化腾将这个思想发扬光大。在当时以C端产品为主的大背景下，这个思想是非常正确有效的，但对于B端产品来说，我们的迭代策略则应该是“小步快跑，稳步上线”。
这个策略是指当产品进入成熟期后，开发过程仍然采用敏捷的方式进行迭代，但要等迭代内容积累到一定程度后合并为一个大的版本推出。这种策略既可以降低原来B端产品瀑布式开发的风险，吸收精益敏捷方式的优势，又可以减少对用户的打扰和团队的消耗。
【PS：版本控制知识，敏捷，瀑布】
B端产品之所以相较于C端产品来说，在版本发布节奏上有区别，主要有以下几点原因。
1）稳定是第一优先级
对B端用户来说，其对产品稳定性的诉求大于获取新功能的诉求。而每一次发布产品的新版本无论在上线前测试做得多充分，都有产生新Bug的风险，所以，较少的版本发布是降低风险发生概率的有效措施。
【PS：思路清奇，不发布就没有BUG，哈哈哈】
2）减少对用户的打扰
无论是B端产品还是C端产品，每次更新对用户来说都是一次打扰——用户需要升级产品，不过由于现在B端产品逐渐转向“云”化，这种影响正在慢慢减小。但是由于B端产品的复杂性，每次更新意味着可能要对用户进行一次新的宣讲服务，而宣讲服务的成本也是极高的，因此从这个角度看，B端产品也需要控制新版本发布的频率。
3）减少对团队的消耗
为了降低产品新版本发布对用户使用产品的影响，团队成员一般都会选择在晚上发布产品的新版本，如果产品版本的发布过于频繁，对团队成员的身体也是一种损耗。另外，有的B端产品部署在局域网中，同时不允许开通防火墙，这样一来，产品每次更新升级都需要团队成员赶往现场操作，对于这类产品，B端产品供应商就更不可能频繁发布新的产品版本了。

运营

1.种子用户难获取

C端产品在获取种子用户的阶段常用的推广手段都无法复用到B端产品领域中，原因主要有以下两点：
客户信心难建立：信任是客户使用产品最重要的基础。对于B端产品来说，如果客户对产品没有建立足够的信任，是不会轻易尝试使用产品的，因为尝试就意味着投入、意味着数据沉淀，这些对客户来说都具有很高的成本。所以如果B端产品在还没有形成口碑或有标杆客户背书的情况下，是很难让第一批客户建立信心的，因此就难以获取种子用户。
客户使用动机纯粹：在C端产品领域中，有很多“产品经理一日游”型的产品。差不多每隔几个月就会在产品经理圈子里爆出一个“宠儿”，但由于缺乏实际的内在吸引力，这些产品往往只会昙花一现。在B端产品领域中，如果没有实际的业务需求，很少有客户会以体验的心态使用产品，因此B端产品种子用户的获取就更艰难。不过也不必悲观，对于B端客户来说，有需求才需要。这一特点在获取种子用户阶段也许是种障碍，但一旦赢得了客户的青睐，这一特点就会成为堡垒。
【PS：种子用户，天使用户，冷启动。】

2.用完即走

“好的产品是用完即走的”，在C端产品领域中，有认同的，有反对的。其实，这句话用来形容B端产品是非常贴切的。B端产品的用户每次使用产品时，都带着明确的目的和任务，当任务完成时，使用的动机就消失了，自然就“用完即走”了。
另外，B端产品用户的使用动机不受产品运营策略的影响，无论你采用何种运营策略，推送多少信息，使用各种方法提高用户的活跃度都是无济于事的，B端产品用户的使用频率、使用动机都不会有任何变化，因为他们是基于组织诉求才使用产品的，所以，B端产品的运营人员不应该投入较多精力和资源在唤起沉默用户、提高用户活跃度方面，而是要把更多的精力投入到开拓新客户和维护老客户中。
【PS：工作重心明确，唤起沉默用户、提高用户活跃度；开拓新客户、维护老客户；】

3.用户忠诚度高/替换成本

对于C端产品，如果用户的产品体验不好，就会立即将产品放弃，转而尝试使用其他产品甚至是竞品，对产品问题的忍耐度较低，而B端产品用户的忠诚度则比C端产品用户的忠诚度高得多。
俞军老师的产品公式：产品价值=（新体验-旧体验）-替换成本
只有当产品价值大于0时，用户才有可能使用该产品。而在B端产品领域中，阻碍用户深度使用竞品最主要的原因，就是“替换成本”太高，这主要体现在以下几个方面。

• 学习成本高：一般来说，B端产品的使用学习起来都会比较困难。当用户熟悉一个产品后，如果没有极强的推动力，哪怕新产品的产品体验更好，B端用户也不愿再花时间和精力学习新产品的使用方法。复杂产品的培训对客户而言更是一个巨大的成本。
• 数据沉淀：B端产品使用时间越长，其沉淀的与组织相关的数据越多，如果用户想使用其他产品，就意味着历史数据全部丢失或需要耗费大量人力、时间同步历史数据。经常会遇到数据映射问题、数据丢失问题，所以有的客户即使有换新产品的心思，也不一定有换的能力。
• 信任感：长时间的使用、磨合已经让客户对旧的产品产生了较高的信任感。即便是出现一个有大厂背景做背书的新产品，用户也无法快速建立对其的信任，因此在替换旧产品时会更加谨慎。
• 用户习惯：用户长时间形成的使用习惯也是替换成本的一部分。用户习惯的威力不仅体现在产品的替换成本上，还体现在当用户出现工作变动时，会把习惯带到新的工作地点，进而起到开拓新客户的作用。比如小明从公司A跳槽到公司B，如果公司B也想采购某个业务系统，小明自然会基于曾经的使用习惯和对产品的认识极力推荐曾在公司A使用过的产品。

危机意识：有时候并不是因为你的产品真的那么好，用户忠诚度才这么高的，而是因为用户的替换成本太高。所以B端产品的产品经理一定要有危机意识，及时发现客户不满意的地方，并重视老客户的关系维护。如果一个使用自家产品很久的客户决定换别人家的产品了，只能说明客户对产品失望了。
【PS：数据迁移，数据初始化，数据治理。】

4.零和博弈

零和博弈的意思是在市场博弈的各方，在激烈竞争的背景下，一方的收益必然意味着另一方的损失，博弈各方的收益和损失相加总和永远为“零”。简单解释就是在B端产品市场中，你的竞争对手每多一个客户就意味着你少一个客户。B端客户在一个业务领域中只会选择一个产品，因为一个B端产品通常就能满足客户的需求。
在C端产品市场中，用户经常会同时使用多个同类产品，比如用户会因为版权问题而同时使用多款音乐播放器。所以同类C端产品的活跃用户总数往往比统计区域内的总人口高很多。这样的市场我们称为“非零和市场”。
【PS：零和博弈。一个现象：客户采购选型时会担心某一家供应端独大。】

5.慢热且平稳

B端产品的客户量的增长曲线一直以一个比较平稳的速度增长，且在相当长的一段时间内增长速率变化不大。不会出现像C端产品那样的指数级增长。挣得全是辛苦钱，很难有“一夜成名天下知”的快感。

原因：
1）获取客户渠道有限
C端产品的用户量能产生爆炸性增长最主要的方式不是靠各个渠道的广告投放，而是通过社交关系链的裂变，利用用户的自发分享拓展产品的新用户。而B端产品由于其本身的特性，很难激起客户主动分享的意愿，即使客户有分享的意愿，也很难找到合适的分享时机，所以B端产品更多的只能通过传统渠道慢慢积累客户。
【PS：病毒式增长。渠道、客情关系的重要性。定制化，挣的是辛苦钱。】
2）决策理性
大多数的B端产品需要付费使用，且有的产品收费很高，因此客户在决定是否使用产品前会经过充分的对比分析，如果涉及的采购金额较大，还会采用竞标的方式来决定最后选用哪款产品。另外，由于需要付费，产品采购的决策链条一般较长，这进一步增强了B端产品客户决策的理性，因此也基本去除了大量体验型、从众型的客户。所以，如果你选择做B端产品经理，就要拥有“肯坐冷板凳”的心态，好好打磨产品。不过，也正是由于B端产品的客户决策理性，所以我们的客户比较稳定，不会出现C端产品领域中的那种过山车式的用户数据波动，对团队来说也算是一种“稳稳的幸福”。
【PS：控标参数，招投标知识。】

商业

商业模式成熟

【PS：互联网商业模式：广告，融资补贴烧钱。风险很大：要积累庞大的用户量，辛辛苦苦培养的用户和市场可能给对手做了嫁衣。】
B端产品的商业模式成熟、健康。羊毛出在羊身上，谁使用，谁付费，每一个客户都是实打实的收入，客户的忠诚度也很高，所以B端产品都有持续的自我造血能力，能够依靠自身收入存活，加上互联网产品边际成本非常低，不需要非常庞大的客户数量就能养活一个团队，因此B端产品的生命力远比C端产品的生命力要强。
【PS：软件产品的边际成本。市场集中度，头部玩家，垄断。】

弱马太性

由于互联网本身的特点，在C端产品市场中有极强的马太效应。在同一领域内，往往头部的一两款产品就占据整个市场90%以上的份额。在B端产品市场中，马太效应的威力要小得多。比如，2018年中国前四大ERP厂商依次为用友、金蝶、浪潮和鼎捷，四家企业的市场份额合计也只有60%。
【PS：市场集中度，头部玩家，垄断。】
弱马太的原因：
转移成本高：在用户/客户转移成本越低的行业中，就越容易出现“赢家通吃”的局面，马太效应就越强。
规模效应影响弱：规模效应是指产品规模越大，会促进其进一步提高市场占有率，进而形成良性循环。比如外卖和打车。在B端产品中，每个客户都是完全独立的，不同客户相互之间不产生任何联系和影响，因此B端产品不受规模效应的影响。

用户侧、产品侧、业务侧看差异

来自《B端思维：产品经理的自我修养》
B端产品为企业客户实现稳定而强大的功能服务，“稳定性高，逻辑严密，数据准确性高”是它的强特征；C端产品为广大用户提供有趣而新奇的功能服务，“体验极致，迭代快速”是它的强特征。

B端产品的基本特征

用户侧
（1）目标用户：B端产品的目标用户是企业中有决策权的管理者，而不是员工。
（2）用户角色：B端产品的用户角色丰富，产品根据用户角色划分功能权限与数据权限，角色根据划分到的权限执行相应的业务操作。
（3）用户决策：B端产品的购买非一人可以决定，而是需要部门、团队决策，与企业的目标和预算都密切相关。
（4）用户体验：B端产品是提供给企业使用的，企业更注重产品带来的效益和效率。因此，企业更关心产品功能的强大。
（5）用户黏度：B端产品的购买费用高，而且更换产品导致企业数据转移和打通的成本也高。一般企业在选定了某款产品后，在较长的时期内不会替换，用户黏度相对较高。
产品侧
（1）产品思维：B端产品的形态和内容来源于业务场景，而且很多业务是具有行业属性的。因此，其产品思维更偏向于理性和解决具体问题。
（2）开发周期：B端产品的逻辑复杂，各种调研和需求的收集期也很长，开发中更是会遇到各种情况，因此开发周期往往以月、季度、年为单位。
（3）产品形式：B端产品的形式一般为桌面端或浏览器端，近年来逐渐向移动端转移，但主流依然是Web端，以表格页、表单页、详情页、监控页等形式展现。
（4）产品成功要素：B端产品的成功来源于让其服务的企业获得价值和成功，让客户更赚钱、更省钱、效率更高等。
（5）产品侧重点：B端产品的侧重点在提升操作效率、建立大而全的功能、提升产品的稳定性和性能等。
（6）传播渠道：B端产品的传播需要建立一支经验丰富的销售团队进行地推，依赖销售长期维护客户关系，对于客户增长来说很难规模化，需要时间逐渐积累渠道和客户。
（7）行业划分：以行业为维度，在行业的基础上进行具体的分类，这样有助于对B端产品产生清晰的认知，有利于产品设计及销售推广。
（8）产品逻辑：B端产品的设计逻辑来源于行业属性、带有行业特性的业务和角色的工作环境，相比C端产品，其逻辑更加复杂和烦琐。
（9）产品稳定性：B端产品对系统稳定性的要求很高，因为一旦出现问题，都不是小事。例如，运维人员在排查问题时看到系统报错了，却无法追溯，找不到出现错误的目标对象，那么将发生不可估量的问题。
（10）设计风格：B端产品以安全和专业为主，因此产品风格多以简洁和清爽为主，不在视觉设计上做过多投入，一般遵循W3C的无障碍视觉设计原则。
（11）产品交互：B端产品不需要太浮夸和个性化的交互，而是以用户习惯的操作方式为主进行产品设计，保证用户能快速操作完目标对象。
业务侧
（1）需求发现：B端产品的需求来源于行业、客户的战略，以及企业现有的业务流程，所以很多需求都是已经相对确定的。产品经理需要准确、深入地理解客户的诉求，多和客户交流，对需求进行收集和梳理，根据业务经验进行产品设计，把控整个产品流程。
（2）盈利模式：B端产品的盈利模式有三种。第一，本地部署的软件客户直接购买软件使用权，后续软件需要升级或二次开发，还需付费。第二，对于SaaS化软件，客户按照租赁的方式使用，一般按年收费，或者按用户数量收费。第三，按照客户使用模块或服务的情况进行收费。
（3）市场竞争：B端产品与国家政策、合规、准入机制有关，市场竞争为半开放状态。
（4）复杂度：B端产品的业务复杂，在业务规模上需要判断各种角色的情况，而在业务完整度上则需要考虑参与进来的角色可能会遇到的情况，避免他们在产品使用过程中出问题。

C端产品的基本特征

用户侧
（1）目标用户：C端产品的目标用户是普通老百姓，只要会上网的用户都是C端的目标对象。
（2）用户角色：C端产品的目标用户就是C端产品的使用者，但是教育类产品相对特殊，其目标用户是家长，使用角色是孩子。
（3）用户决策：C端用户的决策较感性，大部分为个人决策。只要觉得产品有意思，或者产品已经属于群体性产品，用户都会使用。
（4）用户体验：C端产品很注重用户体验，小到一张图片的排版优化、一句文案的描述方式，大到一个支付流程的设计，都是产品设计者要仔细考虑的事情。C端产品体验的好坏，直接影响用户是否会长期在此产品上投入精力和时间。
（5）用户黏度：C端产品的用户黏度较低，只要用户觉得产品哪里不合适，使用体验不好，就会换成其他产品使用。而且，一般同类产品会有好几个在被同时使用，如新闻类产品，用户的一个手机上同时安装有网易新闻、今日头条、腾讯新闻。
产品侧
（1）产品思维：C端产品的功能都很简单，设计者常常植入游戏化思维以提升产品的趣味性。同时，C端产品注重和用户的情感交流，讲究情感共鸣。
（2）开发周期：C端产品的开发周期较短，通常使用敏捷开发方式，快速确定需求，快速将需求开发出来，及时上线，通过运营侧的数据反馈改进现有产品，满足用户需求。
（3）产品形式：C端产品的形式较多样，有网页、小程序、App等形式。目前的C端市场基本被App和小程序占领。
（4）产品成功要素：C端产品的成功来源于用户在使用产品时的叫好。或许是交互流畅，或许是品种齐全，或许是界面好看。总之，让用户有“哇”的感觉，那这个C端产品就成功了一半。
（5）产品侧重点：C端产品的侧重点在用户体验，好的用户体验可以在一定程度上留住用户。
（6）传播渠道：C端产品的传播一般通过社交圈进行，熟人分享和推荐、“大V”站台等方式可以帮助产品迅速扩大用户基数；也可以通过各种优惠活动让用户快速对产品产生使用欲望，如滴滴补贴、拼多多补贴等。
（7）行业划分：C端产品基本不按照行业划分，而是按用户需求不同，分为工具类、内容类、社交类、平台类、游戏类、电商类等。
（8）产品逻辑：对于C端产品来说，直接面向的终端用户非常注重产品好不好用。因此，C端产品要努力提升用户体验，深入挖掘用户的心智模型，了解用户的日常生活痛点和诉求，包括使用习惯、兴趣爱好、付费习惯、购物习惯等，设计出符合用户习惯的有价值的产品。
（9）产品稳定性：C端产品也要注意产品的稳定性，尽量不出Bug，但更注重快速迭代以满足用户需求和提升用户体验。
（10）设计风格：C端产品注重设计风格，不仅是产品本身的诉求，也是用户的诉求。试问在选择无成本的情况下，谁会使用一个界面很难看的产品呢？所以，C端产品的设计风格是提升用户体验很重要的部分。网易严选比较素雅，而淘宝则比较热闹，但这两种风格都是设计师下了很大功夫研究和设计的。
（11）产品交互：C端产品注重交互，提供直接且有趣的交互体检是设计师们要挖掘和探索的。例如，当触摸屏来临时，C端产品的交互更加丰富和多元化了。
业务侧
（1）需求发现：C端产品的用户量大，用户层次不同，需求较分散，就需要产品经理在挖掘需求时进行提炼和探寻本质。在掌握用户数据的情况下，通过数据分析用户真实的需求。
（2）盈利模式：C端产品基本是免费使用的，那么C端产品如何赢利呢？主要有五种模式：广告收入、实物/虚拟商品售卖、平台佣金、增值服务及金融服务。
（3）市场竞争：由于C端产品是免费使用的，所以市场竞争为完全开放的状态，且竞争异常激烈。我们从滴滴与快滴的竞争、美团与饿了么的竞争、摩拜单车与小黄车的竞争就可略知一二。
（4）复杂度：C端产品的场景较简单，逻辑也相对简单，流程是标准化的，所以产品的复杂度相对于B端还是属于不太复杂的。