决胜B端：产品经理升级之路

杨堃

概述篇 走近互联网B端

• 识别市场机会，诊断业务问题，通过软件产品帮助企业增加收入、提高效率、降低成本、控制风险
• 在便捷生活的背后，是越来越多的B端系统在支撑着业务的运转，B端产品经理的需求量也越来越大

第01章 互联网产品领域探秘

• 产品经理和项目经理有啥区别？到底在干啥？”
• 不同方向产品经理的技能诉求、职业发展路径差别非常大

1.1 产品经理岗位的发展历程

• 公司的职能团队只负责各自的工作内容，并不能从公司整体的视角分析市场与客户需求，组织、实施完整的产品运作计划并占领市场，而这个创新的岗位要负责产品的全流程管理。
• 最早的产品经理要做的就是，聚焦公司售卖的产品和服务，帮助公司分析市场，识别需求，负责产品的设计、包装、宣传、推广和持续改进，提升公司销售额和利润。
• 流量为王时代的产品经理
• 需要懂技术、懂商业、强执行力的人才，来负责软件产品的设计、运营、迭代和流量变现。在这个背景下，互联网产品经理应运而生。
• 如何在一块小小的屏幕内设计体验良好的App，是互联网产品经理们要探索的新方向。
• 互联网公司的核心竞争力不仅体现在流量获取和变现能力上，同时也更多地体现在业务模式创新、流程创新、精细化运营和效率提升上，这都对业务型产品经理提出了更高的要求。
• 他们是一群聪明、创新、自驱、有激情、懂技术的人，通过软件与互联网帮助企业实现业务创新、变现，提升企业经营管理效率。

1.2 互联网行业的产品方向

• 根据产品的属性和目标，业界习惯将互联网产品分为C端产品、B端产品、数据与策略产品、商业变现产品和AI产品
• 一名产品经理入行后，要在某个方向持续学习、发展、沉淀，成为某个领域的产品专家，这样才能保证很强的职场竞争力。
• B端产品也叫2B（to Business）产品，使用对象是企业或组织。B端产品帮助企业或组织通过协同办公，解决某类经营管理问题，承担着为企业或组织提高收入、提升效率、降低成本、控制风险的重任。
• AI产品的核心是数据、算法和应用场景的结合。

1.3 互联网公司的盈利模式

• 常见互联网公司的盈利模式可以概括为四类，分别是广告变现、增值服务、佣金提成、买卖差价
• 广告变现模式下的互联网企业，既需要创新的C端产品保证流量，又需要稳定的商业产品持续变现，还需要强大的CRM、呼叫中心等B端产品支持业务运作。
• 第三方支付公司对沉淀在平台中的流动资金进行投资管理，产生利息收入；数据公司通过售卖数据产生收入。
• 表1-1 不同盈利模式对不同产品方向的诉求

第02章 B端产品概述

• 随着互联网线上红利的消失，越来越多的互联网企业尝试开展线下业务，寻找新的业务突破点和增长点。

2.1 互联网行业的发展趋势

• 无论以平台形式还是自营形式介入线下模式，复杂的业务运作流程与庞大的线下业务团队管理都将是不可避免的，而这必须依靠B端产品助力。

2.2 从事B端产品方向的优势

• B端产品经理是懂技术、产品、业务的复合型人才，是企业在任何浪潮中都不可或缺的人才。
• 美团代表重业务模式（有大量的线下团队需要管理）的互联网公司，今日头条代表线上运作的轻模式（线上广告业务，不考虑销售团队）互联网公司
• 作为一名B端产品经理，如果想在某个细分领域深耕，需要做到如下几点。 ● 掌握该领域的所有方法论和专业知识。 ● 对该领域的业务运营特点和难点有深刻的认知和总结。 ● 对市面上所有该领域的商业化软件产品如数家珍，优缺点了然于心。 ● 了解市场上所有类似业务模式公司的业务特点、产品特点。 ● 认识行业内的相关专家，形成圈子，经常聚会探讨行业的案例和变化。 ● 理解公司的业务现状、痛点，知道如何将行业最佳实践结合公司特点进行规划落地。

2.3 B端产品有哪些方向

• 2.3 B端产品有哪些方向
• 支持业务团队的业务平台方向、支持员工内部协同的办公协同方向，以及平台业务模式中支持供给方的商家管理方向
• 业务产品可以进一步细分出多条产品线，包括垂直业务线、基础服务产品线、交易平台产品线。
• 在软件体系搭建过程中，有必要将各个系统都需要的、功能重复的软件模块抽象出来，统一建设维护，所提供的服务叫作基础服务。

2.4 如何转型B端产品方向

• ● 优势  身处接触用户的一线，更加了解、理解用户。  思维灵活，创新意识强，敢于大胆尝试。  数据分析和处理能力强，善于以数据驱动决策。  具备互联网项目管理运作的经验。 ● 挑战  B端产品和C端产品差异大，很多知识需要从零开始学习。  需要花时间适应和业务方协作配合的模式。
• 产品经理要具备商业、用户体验、技术这三方面的经验
• 产品经理是一个需要沉淀和积累的工作，在一个方向沉下心，长期坚持，成为新分领域的专家，你的竞争力就会越来越强

设计篇 从业务诊断到形成方案

• 这其实是相当有挑战的，设计人员要完成业务梳理、流程设计、组织架构设计、数据建模、界面设计、权限设计等一系列工作，既要有对宏观的把控能力，又要有对细节的专注力。

第03章 B端产品建设概述

• 第03章 B端产品建设概述
• B端产品往往涉及复杂的业务关系和场景，该如何设计并实施一套B端产品呢？其实是有规律可循的，遵循标准的流程逐步开展工作，可以提升效率、少走弯路

3.1 B端产品的总体建设流程

• ● 核心业务流程：梳理整个业务主干流程，并确定其中哪些环节需要由该产品实现线上化。● 产品定位：明确该产品有哪些子系统，分别支持哪些业务流程和业务版块。● 应用架构：考虑该产品和公司现有系统的融合关系。● 功能模块：基于对业务的理解，抽象出该产品的具体功能模块。● 演进蓝图：根据业务优先级与发展策略，制订实现各功能模块的计划和节奏。
• 数据建模，也叫业务建模或领域建模，是细节方案设计中最重要的环节，是保证产品设计严谨可行的关键工作。

3.2 B端产品与C端产品建设流程的区别

• B端产品与C端产品建设流程的区别
• 在建设B端和C端产品时，大的原则是类似的，都是先做加法，即充分讨论、穷举所有需求和可能性；然后再做减法，选出最核心的需求点；最后设计具体方案并将其落地，用最短的时间和最低的成本支持业务启动。

3.3 案例：M电商公司的渠道分销产品设计

• 3.3 案例：M电商公司的渠道分销产品设计
• 在2～3个月的时间内搭建一套分销业务平台，至少支撑分销业务在未来2年内的高速发展，有效地提升效率、控制经营风险。
• 层级子母账号[插图]管理和组织机构管理
• 当我们接手一件比较复杂的工作时，制订明确的工作计划是一种良好的工作习惯。

第04章 B端产品的业务调研

• 对于B端产品来说，通过业务调研，能够从经营思路、管理模式等多个维度全面透彻地梳理业务，总结业务面临的问题，是掌握业务情况的有效手段。

4.1 B端业务调研的流程

• 针对高管，可以了解业务战略定位、战略目标等信息；针对经理或负责人，可以了解业务的管理思路、经营思路等信息；对于一线业务人员，可以获取作业过程、操作细节等信息。

4.2 B端业务调研的目的和分析框架

• 一般来讲，业务调研有两个重要目的，一是梳理业务现状，二是总结业务问题。

4.3 B端业务调研的方法

• B端业务调研的常用方法包括深度访谈、轮岗实习、调研问卷、数据分析、行业研究。
• 如果研究CRM，可以试用Sales Force、销售易等；如果研究电商ERP，可以试用管家婆、商派等；如果研究报表可视化，可以试用Oracle BIEE、IBM Cognos、Tableau、百度指数等。

4.4 B端产品与C端产品业务调研的区别

• 业务调研，在B端产品领域一般就叫业务调研，在C端产品领域叫用户研究，因为C端产品面向的是终端用户，需要更多地从用户体验的角度进行调研分析，一般由用户研究团队负责，不一定由产品经理执行。

4.5 案例：M公司分销业务调研总结

• M公司分销业务调研总结
• 业务调研可以分为两种情况：一种是对新业务（打算开展，尚未开展）的业务调研，调研重点在于市场分析、行业分析、竞品分析等；第二种是对于已有业务（已经在开展）的业务调研，调研重点在于梳理当前的现状和问题。
• 我们通过数据分析，整理当前的关键业务指标和全年的业务目标，作为了解业务运作情况和预期的一个重要补充资料
• 我们将业务主流程优化确定为高优诉求，将小众功能、风控功能列为低优诉求，经过探讨和业务人员达成一致，产品一期将聚焦高优诉求的实现。

第05章 B端产品的整体方案设计

• B端产品的整体方案设计需要遵循自顶向下的设计思路，可以依次设计核心业务流程、产品定位、应用架构、功能模块、演进蓝图，从抽象到具体，逐步勾勒出B端产品的轮廓。

5.1 核心业务流程

• 从核心业务流程切入产品设计，是开展整个设计工作的非常好的起点。核心业务流程代表业务的主干脉络，需要思考业务的各个参与方、涉及的系统。
• 通过对核心流程的梳理，以及明确其中哪些环节需要线上化支持，分销系统的轮廓初现。

5.2 产品定位

• 产品定位要说清楚产品针对谁提供什么支持。

5.3 应用架构设计

• 在设计一套新系统时，必须考虑如何和公司现有系统架构融合，不同系统的模块之间如何衔接。
• 图5-3 支持分销系统的公司整体应用架构图

5.4 功能模块设计

• 这个系统应用于哪些业务场景？用户可能在系统中做的操作有哪些？通过思考这些问题来抽象出需要具备的功能模块。产品经理设计的功能模块代表了其对业务本质诉求的理解和提炼，蕴含了他对业务、系统未来发展的期望。

5.5 演进蓝图设计

• 有一个原则可以参考：凡是可以手工处理和解决的问题，都暂时不做系统支持
• 在互联网产品圈中很流行的用户体验五要素及其提出的五个设计层次（表现层、框架层、结构层、范围层、战略层），也是一种自顶向下、由粗到细的设计思路

第06章 B端产品的细节方案设计

• B端产品的细节方案设计包括业务数据建模、页面流转设计、界面设计、权限设计等，这些都是产品经理的必修课，即便没有经历从0到1的设计过程，也会在日常的迭代工作中经常接触。

6.1 业务数据建模

• B端产品进行细节设计的常见流程是，首先构建业务数据模型，然后基于流程确定页面流转图，再着手每个页面的具体设计，同时提前规划好系统用户角色，最后完成权限设计。
• 业务数据建模的过程就是将业务对象及其之间的关系抽象出来的过程，ER图呈现了业务数据建模的结果。
• 因为工程师不需要处理一棵层级复杂的树形结构，也就不需要编写大量的递归算法，这大大降低了开发难度。
• 业务数据建模能力体现的是设计人员对客观世界的抽象描述能力，只有对业务本质理解透彻，再结合积累的软件设计经验，才能抽象并构建出合理的业务数据模型。

6.2 流程和角色

• 流程合理、角色清晰是系统正确设计的前提和保障。遵循自顶向下的设计思路，我们首先设计主干流程，在这个过程中可以进一步明确系统角色及业务岗位的安排，然后基于主干流程图设计页面流转图，最终完成页面细节设计。
• 在流程梳理的过程中，必须谨慎思考各个环节在逻辑上的先后顺序与依赖关系
• 图6-7 创建维护客户与下单操作的流程图
• 通过跨职能分系统流程图，可以清晰地看出谁（操作角色）在哪儿（哪个系统）做什么（完成什么工作）
• 从本质上讲，一套软件系统就是对不同数据对象的增删改查操作的集合，这个特点在业务系统中更加显著。

6.3 界面设计

• 在团队分工明确、人力储备充足的情况下，在开发一套全新的B端业务系统时，界面设计的流程一般如下：1．产品经理绘制线框图原型，表达软件中每个页面的设计需求。2．UE设计师协助产品经理完善交互体验，并制作交互原型。3．UI设计师基于交互原型进行美工设计，生成切图文件。4．前端工程师拿到切图文件，进行前端开发，包括实现交互、动效等。
• 反馈原则（Visibility of system status） 系统应该在合理的时间、用正确的方式，向用户提示或反馈目前系统在做什么、发生了什么。
• 用户经常会不小心操作错误，需要有一个简单的功能，让程序迅速恢复到错误发生之前的状态。
• 防错原则（Error prevention）系统要避免错误发生，这好过出错后再给提示。
• 容错原则（Help users recognize, diagnose, and recover from errors） 错误信息应该用通俗易懂的语言说明，而不是只向用户提示错误代码；提示错误信息时要给出解决建议。
• 我们可以对列表页进行高度抽象，因为在所有列表页上实现的不外乎增删改查操作。观察成熟的列表页，可以发现其上面的元素主要包括检索条件区域、结果列表区域、分页器（控制页码的小组件）等有限的类型，因此只要实现一套高度灵活的前端控件，能够自定义配置所有内容，就可以实现列表页的灵活定制。虽然实现这样一套灵活控件的周期比较长，但是长远来看非常必要。
• 第一个设计瑕疵是一个交互体验的问题——没有全选按钮。
• 网上有很多免费试用的系统可供学习，比如Google Analytics、百度统计、管家婆云ERP、Udesk、Sales Force等。
• 什么叫标准的控件呢？Visio或Axure里提供的可以绘制的控件就是标准控件。不必创造这些标准控件以外的控件！

6.4 报表设计

• 业务报表的核心价值是掌握事实、发现问题、分析原因、产生对策。
• 更常用的方案是使用成熟的报表引擎，这是一种现成的报表软件产品解决方案。后端工程师准备好数据[插图]后，产品经理只需要指定数据源，写好SQL语句，定义好报表样式和基本交互方式（例如搜索选项、分页器等），报表引擎就可以完成接下来的数据呈现工作了。
• 本节中的图表都是从商业报表引擎软件Smart BI和Fine Report提供的demo中截取的，这些成熟的报表引擎软件提供了强大的可配置定制化功能，可以实现你能想到的几乎所有数据呈现形式。
• 这种比较复杂的报表形态背后的数据源，一般是一套数据仓库，而不是业务系统的原始数据库，因为数据仓库的架构更适合做复杂的数据加工处理工作。
• http://demo.finereport.comhttp://demo.smartbi.com.cn除此以外，强烈推荐大家研究学习BI软件Tableau，Tableau是目前顶尖的数据可视化软件，功能强大，灵活易用，并且可以和公司系统进行快速结合部署，是学习数据可视化的极佳材料。
• 韩家玮教授的经典著作《数据挖掘概念与技术》

6.5 数据埋点

• 对于B端产品来讲，数据埋点是考核产品使用程度的一个重要依据，也是业务用户行为分析、产品分析、产品改善的重要参考数据来源。
• 这些在网站中注入分析工具提供的代码片段，以便网站分析工具能够准确捕捉用户行为的工作，就叫数据埋点。
• 埋点格式，是指在埋点过程中需要记录的扩展字段

6.6 权限设计

• 功能权限，指各个角色可以操作的界面、按钮等，例如管理员可以进行新增、删除、修改等操作；运营人员在同样的页面上只能使用各种筛选条件查看数据，无法做更改。
• 我们通常用权限表来描述权限、角色的配置关系，这张表在产品设计阶段就需要准备好。
• 表6-4 分销运营管理后台功能权限配置表
• 图6-45 分销业务的组织机构树
• 通过组织机构树来管理数据权限，是业务系统设计中的常见做法，大家务必理解其设计原理和设计思想。

6.7 文档编写与管理

• 还要强调一点，产品经理不必急于写PRD，而要完成模型设计、流程设计、界面设计、权限设计等工作后，再编写PRD。否则，如果方案还没有理清就开始编写文档，会思绪混乱，不断返工。
• 遵循良好的文档管理规则，能够让工作井井有条，利于掌握项目进度，提升效率；反之，如果不遵循这些规则，会造成工作混乱、失控、出错，甚至影响整体项目推进
• 在互联网公司，产品经理和研发工程师习惯将每一个版本的文档都上传到Wiki系统中，实现文档的线上化存储，这是一种非常好的工作习惯。

6.8 UML和常用图表

• 产品经理常用的UML图包括ER图（UML中的类图）、跨部门流程图（使用频率最高）、状态机图；可能用到的UML图包括活动图、用例图
• 活动图和流程图最大的区别是，活动图可以描述并发工作的执行过程，而标准流程图的节点必须是顺序执行的，只有判断节点才能引出两条分支。

7.2 产品经理是否要懂技术

• 和C端产品相比，B端产品更重视业务逻辑的抽象过程，产品设计方案和技术方案的相关性更强，甚至有时候产品设计方案本身就是技术方案，例如SDK产品、基础服务产品、消息中间件产品等的设计方案。

7.3 产品经理是否要关注技术方案

• 技术方案和产品方案相互影响：有些技术选型问题会直接影响产品方案设计，或者产品方案直接决定了技术方案，此时产品经理要和技术负责人讨论清楚。

7.4 B端产品经理的技术知识要求

• Charles Petzold的伟大著作《编码——隐秘在计算机软硬件背后的语言》
• 接口之间的调用模式分为同步调用模式和异步调用模式两种
• 合理的做法是对第一版系统业务逻辑层的核心功能进行服务化处理，即针对“注册账号”“禁用账号”“重置密码”“更新数据”等每一个目标很清晰的功能，将它们抽象成接口，以便于给任何系统提供支持。
• 至此你应该感受到了软件工程“搭积木”的设计特点，一个个服务接口就像积木块，通过对这些积木块的重复组合利用，可以搭建组装出各种新的功能和服务。我们常说软件工程就是在造轮子（服务接口和系统模块），对于功能相同的轮子，大家共用一套就足够了，没有必要针对每个系统重复制造功能相同的轮子。
• 在技术体系中，有两个非常重要的概念在支撑着接口化、服务化的设计理念的落地，即SOA（Service Oriented Architecture，面向服务的架构体系）和微服务
• 常见的关系型数据库包括IBM的DB2、微软的SQL Server、甲骨文的Oracle，以及被甲骨文收购并开源的My SQL，每一种关系型数据库产品都有自己的SQL规范，但核心的语法规范是相同的。
• 如果你能够理解ER图代表的数据建模思路、以上数据库表结构是如何将数据模型落地的，以及表结构中的数据所体现出的树形结构（图7-15），那么说明你已经理解了业务系统设计中核心且复杂的内容。
• 针对SQL的学习，推荐以下两个学习资源。● www.sqlteaching.com：该网站是目前我接触过的最好的SQL学习资源。

管理篇 让产品落地并不断生长

• 产品经理很像一个大管家，不仅要负责产品功能设计，还要统筹协调各种资源，确保一系列工作都能同步开展，最终拿到希望的结果，产生业务价值。

8.1 为什么需要项目管理

• 优秀的项目管理是互联网公司在复杂环境下保证软件开发按计划推进、落地的关键，也是保障规模团队的产品研发效率和质量的核心要素。

8.2 互联网项目管理的工作重点

• 工作重点主要包括设计并优化项目管理制度和负责大中型项目的立项实施
• 需要专业的项目管理团队结合公司的业务特点和企业文化，对业界最佳实践做调整，制订符合公司特色的项目管理制度，这也是项目管理制度建设的难点和要点。
• 合理的规范制度应该既能约束产品研发团队的行为，也能保护产品研发团队的权益。

8.3 如何对B端产品做好项目管理与实施工作

• 容易发生跨端（跨系统）现象
• 如何协调并推动跨端协作
• 所以，通俗点儿说，强执行力和推动力就是指能够记着事儿，不忘事儿，上着发条追进度，盯过程，要结果。
• ● 项目风险：一般会用红色加粗文字罗列遇到的项目风险和可能的解决方案，可以@相关人员强调某些要求。对近期已经解除的风险，可以保留描述，但用删除线划掉。
• 在项目管理中，合理拆解并细化工作，制订良好的项目执行机制，再加上足够的责任心，就可以对项目进度有较好的控制和掌握。
• 总之，在项目管理中，合理拆解并细化工作，制订良好的项目执行机制，再加上足够的责任心，就可以对项目进度有较好的控制和掌握。

第09章 B端产品的运营管理

• B端产品经理、产品运营人员、业务运营人员三者的工作职责往往有很多交叉和重叠，这就可能导致冲突，影响工作效率

9.1 B端的产品运营岗

• ● Saa S方向，该方向的运营岗位偏销售、BD职能，属于销售管理和客户开发的范畴，不在我们的讨论范围内。● 双边市场的供给端运营方向，例如商家运营、店铺运营，这种运营岗位的工作内容和C端运营相似，我们不在此赘述。● 针对内部业务系统的产品运营方向，本章讨论的B端产品运营主要是针对这个方向的。
• B端产品运营岗位的工作内容主要包括产品功能推广培训、问题解答处理、需求采集过滤、项目效果分析、业务诊断分析几个方面，我们来分别介绍。
• 工作目标不同：B端产品运营通过挖掘B端产品能力，帮助业务线提升管理效能、改善核心指标（不同业务线的考核指标不同，例如，销售线可能是销售额，采购线可能是采购成本，配送线可能是配送效率）；C端产品运营帮助C端产品提升核心指标，常常包括用户量、活跃度、转化率和收入等。

9.2 B端的业务运营岗

• 在一个典型的、成熟的公司组织架构中，类似财务、法务、人力这些支持部门，常常被归类为职能部门或中后台部门，主要目的是保证企业的行政运转；而销售部、仓配部、采购部、客服部等部门，需要围绕核心业务开展工作，直接承担企业经营的业务目标，被称为业务部门。

9.3 产品经理、产品运营人员、业务运营人员如何高效协作

• 组织架构决定了汇报关系，进而决定了绩效考核方式。汇报关系、绩效考核方式会影响人做事的动机、行事的方式，以及个人和团队的利益。
• 产品部和业务部平级，产品经理和产品运营人员统一归产品部管理。
• 有利于从企业利益出发考虑问题：虽然业务线产品经理要为业务服务，但因为产品部是独立团队，所以产品经理有权利和义务在某些时刻跳出业务线，从客户利益或公司整体利益出发，对业务部说“不”，必要时将问题升级到CEO级别去处理。
• 互联网公司取得成功的诀窍之一就是，频繁地调整组织结构，尝试各种安排，在各种调整中很可能实现破局，或者产生“鲶鱼效应”。

10.1 B端产品的需求管理

• ● 这个需求背后的真正问题是什么？● 这个问题是否有简单快速的解法？● 这个问题的影响面有多大？如果只是个案，是否值得投入精力去研究解决？● 如果是共性问题，优先级和紧急程度如何？
• 不论是合并管理还是分开管理，主要目的都是实现清晰准确的需求管理、迭代计划管理，并做到项目进度透明。
• 状态用来描述需求的生命周期，状态值可以包括如下选项：待跟进、需求调研、PRD编写、待PRD评审、待技术评审、待排期、待开发、开发编码、待测试、测试验证、待验收、待上线、已上线、挂起、拒绝。

10.2 B端产品的迭代管理

• 广义上的迭代管理是指软件的持续优化、升级计划；狭义的迭代管理是敏捷开发中的一种模式。
• 结合业务发展周期，我们将系统建设归纳为四个阶段，分别是初创阶段、瓶颈阶段、重构阶段、稳定阶段。
• 跨端项目协同非常复杂，研发节奏互相依赖
• 产品经理要理解瀑布模式和敏捷模式的背景和特点，要辩证地看待它们，这样才能找到两者结合的最佳方案。我们先来了解这两种模式。
• 本质上讲，敏捷模式是容纳并拥抱新时期快速变化的市场环境和商业特征的一种理念。

第11章 B端产品的数据分析

• 互联网人必须具备以数据驱动业务决策的意识和习惯

11.1 数据分析的流程

• B端产品从决策、设计到落地、运营，整个流程都需要全面的数据支持和数据驱动。
• 数据分析的方法论很多，从本质上讲，可以将数据分析的过程抽象为四个步骤（如图11-1所示），分别是明确主题、提出假设、验证假设、产生结论，其中提出假设、验证假设是数据分析工作中最复杂的部分，需要反复进行，才能得到正确的结论。
• 一套BI软件产品的重要功能之一，就是实现类似Excel数据透视表的功能，可以让分析人员从各个维度探查数据。而数据仓库（Data Warehouse）要做的事情，就是对各种明细数据提前按照各种维度加工计算好，等待BI的多维度探查和展示。

11.2 数据分析的要点

• 做好数据分析工作需要三个核心要素，分别是方法工具、业务知识、细心耐心，三者缺一不可。
• 数据分析方法论：基于不同的分析诉求，有很多成熟且经典的数据分析方法论，例如分析C端产品的获客增长模型AARRR、分析客户消费行为特征的RFM模型、分析留存率的COHORT模型，这些方法论中蕴含了成熟的分析思路和手段，是针对各种确定的分析场景的最佳实践。
• 统计学方面：《深入浅出统计学》

11.3 数据分析报告

• 数据分析报告的常见结构和逻辑论证的结构相似，一般按照“总分总”的形式编写，包括提出论点、进行论证、陈述总结三部分
• 刘万祥的著作《Excel图表之道》

进阶篇 支撑企业运转的整套产品体系

• 所谓企业级应用架构，是指企业的所有软件系统设计、集成的方式。

12.1 什么是企业级应用架构

• 企业级应用架构正是指企业的各个软件系统有机集成在一起的方式

12.2 学习企业级应用架构的益处

• 学习企业级应用架构的益处
• 在学习企业级应用架构的过程中，产品经理必然要理解企业的组织架构、职能部门的设计；理解企业在不同阶段、不同的业务情况下，部门之间的权责分工、组织架构的演进等，从而对企业是如何运作的形成清晰的理解。
• 理解应用架构的设计是随着业务发展的，是循序渐进地演变的，不是一蹴而就的。
• 尝试从企业、行业、产业的视角考虑，尤其是从企业整体经营发展的角度去思考、设计方案，能有效地锻炼并培养自己的大局观。

12.3 案例：M集团的应用架构演变之路

• 学习、理解企业级应用架构最有效的方式，莫过于沿着一个企业从小到大的发展脉络，研究应用架构是如何演进、发展，最终形成一套成熟的体系架构的。

13.1 小微型企业的应用架构

• 实际上，所有的软件系统从本质上讲都是对数据的增删改查操作的集合，可以说，如果使用得当，Excel也可以做出一套小型的软件系统。
• 比较典型的ERP软件产品厂商有SAP、Oracle、用友、金蝶。
• 请注意，这里已经产生了应用架构设计的概念，公众号、ERP和CRM，这其中的每个系统都是为了解决某一大类的业务问题而存在的，各自有清晰的定位、分工和目标用户；每个系统内置若干模块，每个模块都是为了该大类业务问题下的某一小类问题而设计的。几个系统相对独立又互相关联。

13.2 中型企业的应用架构

• 本节所讲的中型企业是指，员工数量在百人左右、具备现代企业经营所需的所有职能单元（如人力、财务、法务部门）、组织制度规范的企业。
• 当企业规模达到一定复杂程度以后，必须有一整套软件系统来支撑其经营运转，否则管理会失控、混乱。
• 为了有效地管理团队，并且让内部流程更加顺畅，钟先生邀请专业的IT咨询公司帮助重新梳理了公司的业务目标、组织架构、运营流程，通过引入OA、HRM以及重构ERP等手段，对不合理的制度、低效的流程进行了改造，如下
• 软件本身并不能解决企业的问题，还需要配套的架构、流程、制度，以及人员认识的提升，才能发挥软件的功效。
• 所谓OCRM，是指供销售人员使用的CRM系统，主要负责客户资料管理和销售过程管理。
• 13.2.4 拓展：CRM体系
• 比较成熟的CRM厂商和产品有Sales Force、Oracle、Microsoft、销售易、纷享销客等。

第14章 多元化业务带来的应用架构演变

• 将基础功能模块抽象出来，构建一套基础支撑体系——这也是近几年广受关注的中台建设思路。

14.1 集团企业的应用架构

• 解决信息孤岛问题的经典方法就是进行主数据管理（MDM），主数据管理通过应用架构的拓扑结构设计，配合相应的管理手段，帮助企业存储、识别唯一的关键数据，避免企业内部关键数据的冗余和不一致问题。常见的主数据有客户主数据、供应商主数据、商品主数据等。

14.2 加强基础服务建设，为新业务赋能

• 应用架构体系发展到一定程度后，各个系统都要用到的模块会被抽象出来，改造为公用的基础模块。
• 架构设计既要支持业务在短期内快速发展，又要保证架构主体正确，适应未来的变化和扩展需要。
• Passport系统和客户数据库是两个完全不同的概念，因为客户账号和客户数据是完全不同的：

14.3 集团强化中台能力建设

• 集团希望总部能够成为各业务线的大后方，提供各种支援工作；将各业务线调整为自负盈亏的独立业务单元，对它们充分授权，以便它们能够聚焦业务发展，快速响应市场变化。
• 对通用的、重复的东西进行抽象、合并、下沉，对外统一提供支持和服务。
• 抽象出公共服务后的应用架构图
• 设立平台产品部，负责集团所有公共服务，如Msg、Auth、Pay、Passport、MDM等产品的建设工作，为所有下游业务系统提供基础产品能力支持。
• 理解企业组织架构设计、管理模式设计和产品研发设计的总体思路，才能在应用架构设计、产品方案设计上做出合理的选择，并成功地推进落地

15.1 抽象出通用的企业级应用架构

• 在这张架构图中，我们划分了数据底层、基础服务、业务应用、C端应用等模块。
• [插图]图15-1 通用的企业级应用架构图

15.2 不同发展阶段的互联网企业的应用架构畅想

• [插图]图15-2 初创企业的应用架构畅想
• 图15-3 成长型企业的应用架构畅想

15.3 企业级应用架构设计的建议

• 企业级应用架构设计的建议
• 系统要实现松耦合、高内聚

15.4 浅谈企业架构（EA）

• 在EA模型中，企业架构分为四个主题，分别为业务架构、数据架构、应用架构、技术架构

后记

• 产品经理需要具备经营管理、企业运作、计算机科学、软件工程、项目管理、数据分析、交互设计等各方面的知识
• 作为B端产品经理，应该把帮助企业解决问题作为核心目标。一方面，产品经理要善于利用软件产品解决问题，发挥软件产品的价值和优势；另一方面，也要认识到软件产品的局限性，能够跳出产品的范畴，从业务管理的视角去思考、分析问题，寻找解法。只有这样，产品经理才能不断突破自我，实现提升。