大家好，我是穆宁。
今天我向大家介绍下我在《看本质—从上帝视角看世界的100张图解》专栏开启的一个连载项目。
主要面向于B端产品领域，致力于帮助大家能够从全局视角，深刻理解B端行业、市场、业务、产品、用户等多方位视角下的toB产品概念。
《B端产品100问：从0到1了解toB行业的底层逻辑》连载正式开启！
本内容适合阅读的人群
1.对toB产品感兴趣的在校大学生；
2.已经在toB领域工作1-3年的小白；
3.toB领域工作多年的资深产品经理；
4.想要从toC领域转型到toB领域的产品经理；
本内容的基本大纲
1.概念篇——澄清相关toB领域基本概念；
toB产品入门，掌握最基础的toB产品相关概念与理论，建立基础的个人知识库；
2.标准篇——toB产品设计要求及工作标尺；
toB产品中阶，掌握从业务调研、方案设计到解决方案执行过程中的所有工作规范，参考下方图片；
3.系统篇——通过业务实践构建B端系统方法；
toB产品高阶，通过具体实操案例讲解toB产品从概念期、引入期、运营期、成熟期的全部流程与操盘方法，从产品、运营、市场、到销售、售后；
内容来源于网络，侵删；
本内容可以带给你的帮助与收获
1.帮助想要投身B端行业的小白夯实基础，建立认知；
2.帮助“野路子”B端产品从业者建立系统方法论与分析思路；
3.为资深B端产品经理提供一些信息输入，得到启发或查漏补缺；
4.B端产品行业爱好者收藏，学习所用；
100问内容完结后，还将策划新的选题内容。
目前，B端产品100问：从0到1看懂toB行业底层逻辑专栏已更新过半，以下为Q1-Q47内容：
B端产品100问：从0到1看懂toB行业底层逻辑——概念篇（Q1-Q8）
Q1:B端产品的定义是什么？
B端产品是使用对象为组织或企业，用于解决某类经营管理问题的产品或工具。主要从五个方面解决企业需求：
规模上，提升销售收入规模，将企业成本中心转为利润中心。
成本上，降低企业管理与运营成本。品质上，保证企业产品服务品质与能力，效率上，提高管理与运营效率。风控上，解决或满足企业、行业风控需求。
Q2:B端产品的业务模式是什么？
主要分为四类。
平台型业务：向客户售卖平台的资源，如电商、社区等平台；
产品型业务：向客户售卖相对标准的产品，如企业管理软件；
服务型产品：向客户售卖定制化的服务，如SaaS工具产品等；
解决方案型业务：提供定制化的客户业务模式，如智慧城市平台等；
Q3:B端产品的类型有哪些？
主要有四类：
垂直业务型产品：如CRM、ERP、SCM等（解释见后文）；
行业属性型产品：电商、O2O类产品如微盟；教育类产品如小鹅通；医疗类产品如药师帮；
协同办公型产品：在线文档（腾讯文档）；即使通信（钉钉）；研发管理（泛微）；
运营管理型产品：运营后台（如淘宝千牛平台）；管理后台（如饿了么商家管理后台）；
Q4:B端产品通用框架是什么：
面向企业而言，B端产品从下游到上游分别是垂直业务先、办公协同、基础服务。详情见图。
Q5:B端与C端产品的区别是什么？
用户层面，toC产品面向用户是个体，toB产品面向的是某一类群体；
体验层面，toC产品侧重用户体验，toB产品侧重效能提升；
驱动力方面，toC产品是数据驱动，toB产品是运营驱动；
收益方面，toC产品收益容易量化，toB产品较难；
延伸阅读见下：
转自网络，侵删
Q6:B端产品如何找到自身竞品？
关键词搜索：通过百度搜索相关竞品关键词得到竞品信息；
行业峰会：通过参加行业峰会或展会获取竞品动态信息；
科技媒体：通过浏览主流科技媒体获取最新竞品讯息；
企业信息查询：通过天眼查“竞品分析”功能查看竞品信息；
Q7:B端产品的核心指标有哪些？
经常性收入：MRR，未来持续可获得的收入；
客户终生价值：LTV，客户生命周期的财务价值；
获客成本：CAC，指获取单个新客户所需要的成本；
平均客户收入：ARPA，指每个客户每周期产生的平均收入；
流失：指在特定时间段内停止订阅服务的客户；
Q8:B端产品的设计流程是什么？
分为整体设计与详细设计。
整体设计：
1.核心业务流程
代表业务的主干脉络，需要思考业务的各个参与方、涉及的系统。
2.产品定位
是对产品概要性的总结和陈述，简明扼要地描述产品对业务的支持范围或总体的功能目标。需要说清楚产品针对谁提供什么支持。
3.应用架构设计
应用架构是指公司所有产品和系统的整体结构和布局
4.功能模块设计
功能模块图需要体现出系统的一二级导航菜单结构。在设计时常出现模块层次混乱、新增功能随意摆放等问题，因此要采用自顶而下的分析思路，拆解设计，分析每个独/立系统各自应该具备哪些功能或模块，以及每个系统与公司整体架构的融/合关系。
5.演进蓝图设计
通过功能模块图可以明确业务和系统的规划脉络。但是需要根据业务排列优先级，设计演进蓝图：确定产品的功能规划与实现节奏。
详细设计：
1.业务数据建模：ER图呈现业务建模的结果；
2.页面细节设计：先设计主干流程，再设计页面流转图；
3.界面设计：线框图原型表达页面的设计要求；
4.报表设计：掌握事实，发现问题，分析原因，产生对策；
5.权限设计：设计人员对整体业务体系中岗位和流程的理解；
6.文档编写与管理：BRD,MRD,PRD；
7.UML和常用图表：ER图，跨部门流程图（泳道图），状态机图；
B端产品100问：从0到1看懂toB行业底层逻辑——概念篇（Q9-Q18）
Q9:B端产品的特点是什么？
B端产品的特点主要分为五部分：
1.商业利益：相比C端产品免费模式为主，B端产品更重视商业利益，并通过健康合理的商业模式追求可持续的商业利益。
2.业务模式：B端产品非常重视业务模式，业务模式需要不断创新，如从定制化开发到SaaS,再到目前的无代码开发平台等模式，都是对新业务边界的探索。
3.设计难度：B端产品与C端产品不同，缺乏成熟的方法论与实战经验可以借鉴，很多时候需要摸着石头过河，用产品理念去碰撞用户通过时间和经验积累方法论。
4.理解成本：B端产品往往面向垂直行业及垂直客户，必须对面对的行业及客户足够了解，深入洞察行业特点及典型业务场景，理解成本较高
5.功能逻辑：功能逻辑是B端产品的核心，功能逻辑的背后是面向不同功能模块的用户——场景——需求，以及业务流程与数据流组成的系统架构。
Q10:B端产品的定位是什么？
1.面向生产的工具：企业需要借用产品及工具提升生产效率；
2.完整的生产能力：生产链条中的每个的环节都很重要，缺一不可；
3.产品化和线上化：线下流程线上数字化，通用化产品能力提升效率；
4.全流程服务：建立服务意识，提供售前/客服/实施/技术支持；
Q11:B端产品的需求来源有哪些？
需求来源1：
业务部门
来源细化：销售、市场、客服、运营
优点：源于一线，有代表性；即时反馈，时效性强；
缺点：传达过程会有曲解；业务会将解决方案强加过来；
需求来源2：
产品用户：
来源细化：一线员工；企业管理者
优点：准确的需求挖掘来源；可以通过调研方法进行深入分析；
缺点：需求挖掘过程耗费时间精力；存在个体差异，容易以偏概全；
需求来源3：
竞品：
来源细化：直接竞品、间接竞品
优点：竞品已经对需求进行了判断；可以直接借鉴竞品方案；
缺点：竞品的方案不完全适配本品；较难领会竞品的底层设计思路；
Q12:B端产品发展的三个阶段有哪些：
产品可用：集中精力把最核心的价值流程走通，满足客户需求及业务场景
产品可卖：合理评估成本，完成市场竞争度调研与分析，明确品牌定位与产品定价方案
规模化：组件销售团队，面向不同细分领域客户提供全流程深度解决方案
Q13:B端产品设计的三个思维方式是什么？
组件化思维：强调功能、产品架构、设计的可复用性，提高效率，减少研发成本
业务思维：遇到问题时，优先站在业务角度进行思考
MVP思维：B端产品周期长，流程多，逻辑复杂，MVP至少要满足某一个核心的业务需求
Q14:B端产品的商业模式/计费模式是什么？
买断式收费：传统软件的模式，实施困难
按周期收费：SaaS产品的模式，按使用周期付费
消耗模式：先充值，再消费
分润模式：将销售额或者租金与硬件服务商或合作方进行分成
Q15:B端产品运营体系包含哪些？
对内：
流程管理、用户分析、行业研究、运营支持...
对外：
营销策略、客户服务、培训支撑、客户成功....
（后续问题会针对具体模块展开，敬请期待）
Q16:B端产品运营包含几种角色？
售前：
1咨询师：话术培训；问题解答；初筛客户
2客户经理：私域运营；产品演示
3技术团队：专业问题解答
任务：产品推介
售中：
客户经理：需求对接、场景分析、（个性化）方案制定
任务：需求对接结果交付
售后：
客户成功经理：产品使用指导、问题解答、产品更新宣贯
技术团队：问题跟踪及解答
任务：咨询答复
B端产品100问：从0到1看清toB行业底层逻辑（标准篇：17-27）
Q17:什么是UML图？
概念：
UML （Unified Modeling Language）是一种通用的可视化的建模语言，可以用来描述、可视化、构造和文档化软件密集型系统的各种工件。
UML组成：
UML由构造块，规则和公共机制这三部分组成。构造块：对模型中最具有代表性的成分的抽象规则：描述了一个结构良好的模型看起来应该像什么公共机制：4种贯穿整个语言且一致应用的公共机制。
UML模型分层：
用例视图—场景视角
逻辑视图— 逻辑视角
进程（过程）视图— 过程视角
实现（开发）视图—开发视角
部署（物理、配置）视图—物理视角
Q18:如何对系统进行UML建模？
需求模型：
静态模型（用例图）
动态模型（活动图）
对象模型：
静态模型（类图、对象图、包图）
动态模型（合作图、顺序图、状态图）
体系架构模型：
软件体系结构模型
硬件体系结构模型（构件图、配置图）
Q19:UML建模规则是什么？
名字：任何一个UML成员都必须包含一个名字
作用域：UML成员所定义的内容起作用的上下文环境
可见性：UML成员能被其它成员引用的方式
完整性：UML成员之间互相联接的合法性和一致性
运行属性（execution）：UML成员在运行时的特性
Q20:UML常见图有几种？
Q21:不同UML图的作用有哪些？
Q22：UML图的常见要素有哪些？
参与者：系统外部与系统交互的人或事物，可以是人、部门或系统
用例：参与者为完成某个目标的一系列活动
边界：将系统内外分开，参与者在外面，用例在里面
关系：描述类结构之间的关系，一般情况下分为关联、包含、扩展、实现
Q23:绘制UML图的流程是什么？
分析业务场景，找出人、事、物、目标
分析业务流程，细化目标，得出业务用例图
由业务用例图推导出系统用例图
Q24:不同用例图适用于哪些产品研发阶段？
Q25:需求分析阶段如何利用UML图建模？
Q26:基本设计阶段如何利用UML图建模？
Q27:详细设计阶段如何利用UML图建模？
从0到1看懂toB行业底层逻辑——概念/架构篇（Q28-Q37）
Q28:什么是产品架构？
将业务结构化抽象，并以功能和信息的形式体现。展开说是将具体的业务功能按照一定规则组装成业务模块，将不同业务模块按照一定规则进行划分和归拢，并用图形或者文字把各模块之间的关系表达出来的逻辑模型。
Q29:为什么要设计产品/业务架构？
产品经理角度来看：帮助产品经理梳理清楚每个业务模块/功能间的边界，以及它们之间的关系，明确产品方向，划分产品边界，指导产品路径。
公司角度来看：将无序、散乱的业务抽象成中心化、标准化的有序服务，将系统的共性抽象成通用服务。改善高频需求重复占用资源问题，提升系统功能复用性。改善旧系统耦合性强问题，利用SOA理论及架构，提升系统功能延展性。
Q30:好的产品/业务架构有哪些特点？
清晰的系统目标：能体现公司的业务目标及管理目标。
助力商业模式：能体现公司的业务目标及管理目标。
架构边界清晰：清晰的功能边界，架构分层明确。
组件职责单一：功能经过抽象，做到标准化、互相独立，组件职责单一。
组件弱耦合度：在系统设计时十分忌讳“强依赖”。
组件具备扩展性：架构开发预留开放接口，具备迭代优化的能力。
抽象能力强：能帮助产品适配更多的领域，支持纵向演进及横向业务的覆盖范围。
落地性强：开发难度适中，可验证方案较多，落地能力强。
Q31:产品/业务架构包含哪些要素和内容？
产品架构要素主要包含两个视角，一个视角是业务视角，另一个视角是架构视角。
业务视角主要体现在业务调研过程中，通过访谈获取到核心目标，了解关键角色和关键业务，在后续设计时，就明确了哪些模块是必须要详细设计的，哪些模块可以做简化设计。
架构视角则是在业务调研之后，我们需要在进行实际的产品架构设计之前梳理出我们需要了解产品架构所包含的要素，用于理解与呈现。
业务视角是对实际业务的抽象，架构视角是对业务视角的进一步抽象及可视化。
业务视角：
整体组织架构：全局视角俯瞰整个项目结构时必须了解的部分；
权限角色架构：角色权限及范围帮助我们了解角色权限的颗粒度；
关键业务要素：业务中用户产生业务操作的对象以及交互关系；
业务流：系统覆盖范围内的所有业务的流转流程；
数据流：系统中不同平台交互所产生的数据流转流程；
操作流：某权限用户为实现业务诉求而在系统中某平台产生的操作流程；
架构视角：
模块：不同功能汇聚成模块，模块的划分需要遵循规则，根据角色、场景、交互操作等去进行功能块的聚合。
域：不同模块可以进一步聚合形成域，域是模块根据某个场景聚拢而形成的，域可以支撑某一个场景下的一系列操作，输出一个闭环的能力。
层：是某几个域和模块的组合，层实现了向下整合或向上支撑的统一化的能力。逻辑关系指层、域、模块之间需要有清晰地逻辑关系，如输入输出、边界等等。
Q32:产品/业务架构图的两种类型？
常用的业务架构分层有2种：
上中下结构：资源层—数据层—平台层—业务层—用户层。
左中右结构：上游产业—业务模型—下游产业。
Q33:产品架构图的绘制流程？
一、确定业务方向
1. 定义业务场景
问题域的环节非常发散，这一步需要回归基础，把模糊的需求补充成一个在商业模式和用户体验上能够形成闭环的产品需求。
核心需求确定：我的产品核心解决的是哪批用户、哪个用户需求？
产品目标：如果以一个数字指标衡量我的产品，它应该是什么？
3.用户场景：核心需求基本的产品形态、用户使用的路径是怎样的？
2. 清晰业务流程
这一步需要根据核心产品需求和问题域的答案，画出简单的业务流程。
二、业务架构分析
业务分析：
主要分析出：客户的业务投入什么？产出了什么？参与的角色有那些？客户对于业务的商业诉求是什么？客户的核心业务是什么？最后使用流程图来描绘核心业务。
需求分析：
需求分析主要是分析客户提出的特定需求，对业务影响，比如新增业务、修改业务流程等。
这里的需求分析，不同于产品功能设计时的需求分析。
做产品架构时，需求分析更加偏向于分析客户需求和业务间的关系，进而调整我们的业务分析结论。
跨角色业务流程：
在完成业务分析后，我们得出了业务的参与角色和业务流程。这时候，就需要明确角色和业务的关系了。
描述角色和业务的关系，可以使用序列图/泳道图来分析。
系统梳理：
完成以上分析后，我们可开始梳理在该产品中会存在哪些子系统。分析时，需要结合业务流程、需求分析和角色参与关系，划分各业务系统。以及子系统有哪些角色参与，体现的哪块子业务。划分子系统的原则是优先把同一角色参与，流程中相近，业务相关联的整合到相同的系统。
三、业务架构设计
1）基础框架
对照业务流程，根据自己设想的产品机制、基本产品形态和用户的使用路径，列出需要的页面&功能&模块等前后端逻辑。
将刚刚得到的多个流程图中所有功能类似或者范围有包含关系的机制/功能放在一起，以模块化的形式形成一张简单的矩阵图。
将明显是同一个产品范围、同一组产品功能的模块放在同一层级，得到一个基础的产品框架。
2）分层
分层是一个功能维度上的概念，可以按照服务的对象不同，分为用户层、业务层、数据层。
用户层：将所有面向用户的功能集合在一个层级，需要考虑不同的用户群体所享受的服务存在差异。
业务层：将所有的业务处理规则和逻辑，集成在业务层，业务层对用户层有逻辑支撑，业务层在不同的场景下集成的规则和能力都是不同的，向上输出也不尽相同。
数据层：将所有的数据沉淀，数据处理集成在了数据层，数据层提供基础的跟数据相关的增删改查服务，这些服务供业务层调用，在不同的场景下沉淀不同格式的数据。
3）分域
域一般情况下可以考虑按照业务职能进行划分，也可以根据业务线或业务主体进行划分，最常见的比如滴滴租车域、专车域、顺风车域等，这种划分的本质也是逐步在扩充我们业务边界，也是产品生态的不断扩容。
域也可以按照系统的关系来进行划分的，支撑域、集成域、消费域这类划分方式，这种方式划分域能够把能力聚合在一起向外提供统一服务。而集成域更像是一种解决方案的聚合。
4）分功能
分功能是指在同一个域中，将独立的功能划分出来，该功能可以代表一个业务入口。
简单理解就是将一个模块体系中的功能，比较具有代表性的，客户比较关注的，拎出来。
在画业务架构前，有必要对整个业务体系进行全量的思考，将所有涉及到的应用、功能、系统、能力、平台全部要罗列出来。
然后进行提炼、归纳、分类，按照常用的分类模板，或是自建模板进行大体框架的构思。
5）识别核心业务时标对象及状态流转
在拆解核心场景时，一定会涉及到业务单据，将其记录下来，若单据有跟随时间、事件、动作发生状态转移，则需要绘制出它的状态图。
6）理清业务对象之间的关系
识别出来业务对象后，通过箭头或虚线表达出他们之间的关系，以让开发同学一目了然。
四、画出架构蓝图
使用合适的工具，基于上面的分析进行合理的绘制即可。
Q34:业务架构对企业应该起到什么作用？
业务架构是一个具有通用目的的学科，适用于许多不同场景。它本身并不是一个目标，更像是一种实现交付业务场景的手段，例如：
制定和沟通战略业务目标的影响
跨业务部门对齐战略和计划
实现商业模式目标
评估监管和政策变化的影响
提高客户和第三方的参与度和体验
框定、范围、阐明和重用业务需求
确定企业投资的范围
定义IT目标架构
实现战略业务转型
Q35:针对不同需求如何切换产品架构的思考？
不同类别的需求，对应着不同的架构思考，分别为：
小需求，用产品模块内可配置思考方法；
先站在整个系统架构来看这一个又一个的小需求，把需求归类到属于它的模块，然后尽量的用一个功能模块来满足多个类似的需求。一个Ｂ端资深的产品经理，在面对一个一个小需求时，懂的在整体中来理解部分。
中等需求，用高内聚、低耦合思考方法；
高内聚的意思是指，产品结构中单个模块内各个元素联系紧密，也就是一个模块内的代码只完成一个任务。
低耦合的意思是指，产品结构内不同模块间的联系弱，关系简单，修改一个模块则不会影响另一个模块。
产品通过低耦合、高内聚的思想来设计，会给产品未来带来更好的可扩展性和灵活性，避免了后期产品的难以迭代，需要重构。
大需求，重启产品线思考方法；
公司有了新需求，且这个需求已经远远超过了产品从0到1的架构边界。这个需求是不是真需求？这个需求有没有价值？能不能规模化发展？等等都是一个未知。
这时最好的解决方案就是重新启动一个独立的新产品来解决这个问题，千万不要把新需求聚合在老产品里，让产品越来越不好用，影响了老业务的发展，得不偿失。
Q36:如何提升产品架构图的扩展性？
产品架构想要具备扩展性，就需要考虑将产品的模块按照其在架构中可能涉及到的变化频率分为三个类别：
核心层：作为不可变或低频可变的内容，用于设计产品最核心，最具竞争力的部分。大部分产品架构中数据层都是核心层，核心层提供的能力是最内聚的，是产品的底座。
组合层：是指将一些垂直的场景内聚到域当中，域内的能力是相对集中的，通过跨域的组合搭建不同的商业场景，组合层的能力决定了产品的灵活性。
定制层：定制层主要指差异化的部分，差异化的部分是可以进行定制的，定制出来的功能模块需要组合层的支撑，组合层提供的能力越多，那么定制层的定制能力则越强，扩展性就越好。
具备了这三个部分的能力的产品架构，已经具备相当不错的可扩展的能力了，主要体现在大部分业务的特性化诉求，都是可以通过定制层来满足的，少部分具备一定抽象能力的诉求，可以在组合层中来支持。只有当出现大的技术变革或业务方向发生调整之后，核心层才会发生改变。
Q37:绘制产品架构图的工具有哪些？
processon：
ProcessOn是一个方便易用、免费高效的在线作图工具。之所以会推荐这个工具主要因为：
一是因为它是一个在线的工具，具有了跨平台的特性。二是因为其在线存储，文件备份比较方便。三是操作简单，它基本吸取了visio之类常用绘图软件的操作特点。四是因为结合网络社交的特性，不同图表的作者可以轻松地在平台分享各自作品，用户也可以方便地对公开的作品进行搜索，同时还支持多人协作的功能。
当然，这个工具还存在或大或小的不稳定因素，如丢失数据，菜单功能卡住，图标相对比较少等。
axure：
Axure RP是一个专业的快速原型设计工具，除了产品经理之外，还有很多领域的从业者使用该软件。Axure RP不仅仅可以设计产品原型，也可以绘制产品线结构图、用例图、逻辑流程图等等，甚至很多产品经理直接使用Axure RP表述产品需求文档。
visio：
微软推出的一款流程图制作工具，也是目前产品经理最常用的一款流程图工具。通过Visio可以方便、快速地把业务流程、系统实现流程画出来。它本身有很多的组件库，可以很方便的完成各类流程图、结构图和网络图的制作。Visio的另一个特色功能在于它有非常丰富的自带模板。
Powerpoint：
Powerpoint是我们日常使用几乎最多的办公工具，其强大的形状库与素材库可以满足产品经理绘制流程图、产品架构图等基础需求，且输出较为方便，学习成本也较低。如果工期紧张需要快速绘制时，PPT其实是个不错的选择，但如果有更专业架构图绘制工具，可能就要对比衡量一下了。
摹客：
摹客是一款专业的原型设计工具，支持对产品架构图的绘制，但并不是主打功能。优点在于可以随时切换查看产品原型与业务流程图，较好的实现产品逻辑的可视化校验。
draw.io：
draw.io 是一款免费的在线图表编辑工具，代码完全开源，可以用来编辑工作流，BPM, org charts, UML, ER 图，网络拓朴图等。不论是在线编辑还是定制化开发，都是一款非常强大的工具，非常推荐。
从0到1看懂toB行业底层逻辑——概念/架构篇（Q38-Q47）
38.为什么saas产品的增长模式非常重要？
增长是头等大事 ：以60%的增速达到1亿美金ARR的公司市值是以20%～60%的增速达到1亿美金ARR公司的五倍。
增长可以预测成功 ：60%增速的公司ARR突破10亿美金的概率是普通增速公司的8倍。
增长难以为继：维持60%增速达到1亿美金ARR的公司中，只有15%的公司可以继续维持这个增速达到10亿美金。
增长比利润更重要 ：超过1000家的SaaS公司ARR达到了1.5亿美金，但只有50家达到了10亿美金，而超过50亿美金的公司则仅剩下9家。
39. SaaS产品常见核心指标
CAC（客户获取成本）：CAC需要遵从完整性原则，需要将归属于获取新客户的所有费用都需要包括进来，销售中的打折，返点等。
MRR/ARR（经常性收入）：经常性收入（Recurring Revenue）是未来持续可获得的收入，通过统计MRR/ARR可以清晰地呈现业绩状况和收入变化。
LTV（客户生命周期价值）：代表客户生命周期的财务价值，即单个客户在整个使用期间内所支付的费用。LTV：客户生命周期价值=ARR或者MRR*客户生命周期。
平均客户收入（客单价）：ARPA（Average Revenue Per Account）指每个账户（客户）每月或每年产生的平均收入。ARPA＝MRR÷账户/客户总数t。
流失率：流失（Churn）客户指在特定时间段内停止订阅服务的客户。流失率有客户流失率及收入流失率两个指标。客户流失率＝流失的客户数t÷客户总数t×100%
40. SaaS产品的主要增长模式
SLG(Sales-led Growth销售带动增长)是大部分企业最常使用的增长模式，再后来PLG(Product-led Growth产品带动增长)受到追捧，除此之外还有MLG(Marketing-led Growth营销带动式增长)等其他模式：
Convertlab CEO王铮曾提出：
对于0-2万客单价产品的企业最适合PLG(Product-led Growth)的增长模式，通过产品和服务带动企业的增长。
对于2-30万客单价产品的企业，适合MLG(Marketing-led Growth)的增长模式，用市场来驱动企业的增长。
对于30万以上客单价产品的企业，适合SLG(Sales-led Growth)的增长模式，以销售带动企业的增长。
图片转自Convertlab 王琤演讲稿
41.什么是销售驱动型增长（SLG：Sales-led Growth）？
销售驱动增长主要指在一个典型的客户购买旅程中，客户通过市场渠道联系销售看demo，销售一步步跟进直到产品实施。产品只有在销售决策完成后才能开始发放到用户手中开始使用。
销售驱动增长的主要缺点：
销售周期冗长，获客价高，人力成本高。以销售驱动的ToB购买流程非常的复杂。整个销售过程需要不断的与客户的多个部门建立关系，并尝试着影响他们的购买决策。
产品复杂且体验差。客户通常会一项项的对比竞标产品的功能，并倾向于选择购买功能更多更全的产品。因此，ToB产品团队更倾向于开发更多的产品功能，导致了产品由于盲目追求功能数量而导致日渐臃肿，忽略实际需求，产品体验越来越差。
42.什么是产品驱动型增长（PLG：Product-led Growth）？
PLG 是一种商业策略。开发逻辑、设计理念、品牌营销、客户销售、续购增购都由用户手中的产品浓缩，并通过出色的用户体验传递给用户：产品棱镜。
这需要公司层面多团队的合作（工程师、销售、市场等）把产品当做最大的可持续、可规模化的增长渠道。
这种商业策略有着如下逻辑前提：终端用户价值的崛起已经成为企业服务领域决定性的力量。PLG 商业策略根本上是寻求一种 C 端低成本驱动增长的规模化获客体系。其底层逻辑是：把产品自身作为增长载体，前期通过免费版或者免费试用的方式，让产品自己“说服”客户，推动获客、留存、拓展的飞轮运转。
一旦形成产品口碑闭环，公司将摆脱市场、销售和客户成功的人力和流程限制，由此获得高速增长，同时拥有低于平均水平的 CAC（获客成本）回报。
PLG 产品棱镜中，User Experience（用户体验）起到了增长发动机的作用。
团队将更加聚焦于提升产品本身的价值：由于购买决策取决于终端用户是否能够快速感知产品价值，ToB的产品团队将更加注重对产品的打磨，包括提升用户体验与产品易用性、优化新客上手流程、推出能真正解决终端用户的核心功能。
降低获客成本：由于PLG的整个流程大多由终端用户自助式完成，前期基本无需销售和客服的介入，因此可以大大降低获客成本。这些传统流程中花费在销售、市场和客服的资源可以重新分配在更高价值的领域。
C端方法论可迁移至产品驱动增长模型中: 许多C端的方法论可以应用在产品驱动增长的环境下。比如，C端常见的用户增长方法与分析方法可以用来推进PLG中的终端用户的增长。团队可以尝试着去采用用户社区、线下活动等方式来让更多的终端用户关注并使用产品。
43.什么是市场驱动增长（MLG：Market-led Growth）？
营销主导的增长，意味着依靠通过网站上的内容、社交媒体营销或广告的内容营销来获取新客户。
在以营销为主导的增长中，关键是尽早吸引你的客户并让他们记住你的服务。营销主导增长的目标是让人们了解公司的产品，让他们访问公司的网站，提供独特的内容并向他们展示你们提供的价值。
如果想要更多客户以营销为主导的增长，你的目标是创建能够引导你的产品的独特内容。
为此，首先要考虑你的潜在客户有什么问题。他们在网页中中输入什么来寻找解决方案？他们使用什么关键字？然后，根据他们的需求，创建有价值的内容，帮助人们并展示你公司的服务价值。
44.什么是体验驱动增长（XLG：eXperience-Led Growth）？
目前业界还首次提出了体验驱动增长（XLG，eXperience-Led Growth）概念，相较于目前行业热议的三种增长模式（PLG 产品驱动增长、MLG市场驱动增长、SLG 销售驱动增长），体验驱动增长会涉及企业更多的组织部门，是对整个企业的战略调整，甚至会重塑企业的商业模式，带来第二条增长曲线。
45.什么是客服驱动增长（CS-LG：Customer Service-Led Growth）？
客户服务是贯穿整个客户生命周期中的连接和互动触点，以往的客服，定位于一个依靠知识库，对客户的问题，提供标准的解答。现在，智能客服已经代表了客户的全周期参与和长期的客户关系。客服这一业务角色，也从后台走向前台。
高质量的客服，能为企业带来巨大的经济效益。比如，从发现线索，到建立私域流量，再到帮助客户选择和达成交易，最后到复购和交叉销售，都可以靠智能客服完成。
46.什么是社区驱动增长（CLG：Community-led Growth）？
CLG面向的是积极支持用户之间的互动，并提供超越产品边界的社区价值来发展业务"朋友"。用社区驱动增长（CLG, Community-led Growth)助力PLG和SLG，用KOL和典型客户的口碑驱动SaaS产品的增长。
CLG专注于为saas产品社区创造一个安全的空间，让他们聚集在一起、分享价值、建立关系，并最好地利用他们的产品/服务来解决问题或帮助实现目标：进入市场的方式，中心是通过利用社区进行销售。
像 Figma、Lululemon、Salesforce、Sephora 和 Twilio 这样的公司——从开发者平台和 CRM 到消费者品牌——将社区放在他们战略的首位。这类产品的特点是为他们的客户在社区中聚集在一起创造空间。虽然确实需要投资，但社区是公司发展的乘数。
47.什么是事件驱动增长（ELG：Event-led Growth）？
事件驱动saas产品增长的模式目前适用性还有待考证，主要对于合规类、安全类SaaS产品，产品增长与国家发布的重要合规条款、要求、标准等，以及社会安全、国家安全、网络安全、设备安全等重要政策导向与业务需求相关。
对于强政策相关性saas类产品，事件驱动增长模式(ELG)也值得关注。
从0到1看懂toB行业底层逻辑
（Q1-Q47）图解汇总
以上就是B端产品100问：从0到1了解toB行业的底层逻辑的全部内容了，希望大家喜欢。