1.书籍信息

封面
书名	《不枯燥的B端产品实战课》
作者	周翔
状态	已读完
简介	本书是一本面向初级、中级互联网B端产品经理的实战指南。全书共分为3篇9章，其中第1～3章为认知篇，主要介绍B 端产品的基础知识及B端产品经理的能力模型；第4～8章为定制化篇，是全书的主干内容，介绍B端产品在定制化阶段从零到一的调研、分析、设计过程，同时结合笔者的自身经验，分享了如何高效、愉快、顺畅地与业务方进行合作；第9章为商业化篇，主要介绍B端产品从定制化阶段迈向商业化阶段时如何进行分析及改造。本书内容生动有趣，不枯燥。

2.书摘

23个笔记
认知篇

工具属性是B端产品最核心的属性，是让组织管理思想有效执行的重要保证，是让组织管理意志真正落实的有效推动力，而数字化是它的形式和优势。C端产品可以分成十几种类别，涉及社交、工具、新闻、娱乐等领域，而B端产品的分类只有一种——工具，即为了解决特定领域的问题，帮助人们更好地完成工作的辅助工具。
2.1 用户层面

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

，B端产品用户的使用动机不受产品运营策略的影响，无论你采用何种运营策略，推送多少信息，使用各种方法提高用户的活跃度都是无济于事的，B端产品用户的使用频率、使用动机都不会有任何变化，因为他们是基于组织诉求才使用产品的，所以，B端产品的运营人员不应该投入较多精力和资源在唤起沉默用户、提高用户活跃度方面，而是要把更多的精力投入到开拓新客户和维护老客户中。


在C端产品市场中，用户经常会同时使用多个同类产品。例如当你想听歌时，常常会因为版权问题而同时使用多款音乐播放器；当你想看视频时，你的手机上也极有可能既安装了爱奇艺，也安装了腾讯视频。所以同类C端产品的活跃用户总数往往比统计区域内的总人口高很多。这样的市场我们称为“非零和市场”。而B端客户在一个业务领域中只会选择一个产品，因为一个B端产品通常就能满足客户的需求。
2.6 商业层面

有意思的比喻
在C端产品市场中，有的产品的盈利模式是羊毛出在猪身上：先利用免费服务积累用户量，然后根据产品特点从第三方企业身上赚取收益，如最常见的广告收入。但是，这种模式风险很大，不仅需要积累庞大的用户量才会对第三方有吸引力，而且即使有商家愿意投放广告，获取的收益也要足够高才能让产品、公司持续发展下去。


相比较而言，B端产品的商业模式则成熟、健康得多。羊毛都出在羊身上，谁使用，谁付费，每一个客户都是实打实的收入，客户的忠诚度也很高，所以B端产品都有持续的自我造血能力，能够依靠自身收入存活，加上互联网产品边际成本非常低，不需要非常庞大的客户数量就能养活一个团队，因此B端产品的生命力远比C端产品的生命力要强。
5.2 战略分析与规划

产品愿景呀
1）业务维度 业务维度是产品经理根据产品为业务方所带来的价值确定的产品定位。在这一维度中，产品经理主要分析产品目标用户、目标用户的痛点、业务目标、产品类型和产品价值，而这些信息在前面的调研阶段我们都已经了解清楚了，所以现在只需要用一套精炼的话术将这些信息总结出来即可。 这里我们可以借助电梯演讲的方式，对我们现在做的HRM系统进行分析，得到它在业务维度中的定位。 为了【人事部门同事】（目标用户） 他们能够【更高效便捷地管理公司人事事务】（业务目标） 这款HRM系统作为【人员数字化管理工具】（产品类型）


1）业务维度 业务维度是产品经理根据产品为业务方所带来的价值确定的产品定位。在这一维度中，产品经理主要分析产品目标用户、目标用户的痛点、业务目标、产品类型和产品价值，而这些信息在前面的调研阶段我们都已经了解清楚了，所以现在只需要用一套精炼的话术将这些信息总结出来即可。 这里我们可以借助电梯演讲的方式，对我们现在做的HRM系统进行分析，得到它在业务维度中的定位。  为了【人事部门同事】（目标用户）  他们能够【更高效便捷地管理公司人事事务】（业务目标）  这款HRM系统作为【人员数字化管理工具】（产品类型）


有道理
公司维度 公司维度是公司管理层根据产品对公司的价值所确定的产品定位。这里的主语笔者用的是“公司管理层”，因为这需要站在整个公司层面统筹分析，而以产品经理当前的认知和所掌握的信息可能不足以支撑我们做到这一点，所以需要产品经理与公司领导一起分析确定，而且是以管理层的意见为主。
5.3 需求要素分析与管理

我们主要从需求内容、需求角色、需求价值、需求场景、需求强度和需求频次六个要素进行分析。
5.4 需求优先级分析

第一象限：既重要又紧急的需求，优先级为1。  第四象限：不重要但紧急的需求，优先级为2。  第二象限：重要但不紧急的需求，优先级为3。  第三象限：不重要且不紧急的需求，优先级为4。


根据需求与产品核心的紧密程度，我们可以将需求分为核心需求、支撑需求、次要需求三类。  核心需求，是指对产品核心有直接影响、与产品核心关系最紧密的需求。  支撑需求，是指为了更好地实现核心需求而衍生出的支撑性需求，因为与核心需求存在一定依赖关系，所以也比较重要。  次要需求，是指为丰富产品内容、提升产品体验等的辅助性或其他非功能性需求，如UI样式需求、易用性需求、部分性能需求等。
6.1 流程驱动设计

4）分类按不同分类维度，流程可分为多种类型。[插图] 主次维度。按流程的主次程度进行划分，流程可以分为核心流程、次要流程、异常流程。[插图] 功用维度。按流程的功用进行划分，流程可以分为业务流程、功能流程、操作流程、页面流程、数据流程、状态流程。


作为产品经理，我们需要重点掌握基础流程图和跨职能流程图的绘制规则和方法


，产品经理掌握了这种方法，足以应对大多数产品设计。不过这种方式对复杂的、涉及多领域的产品则显得不太好用了，原因有以下几个。1）复杂流程易混乱从前面举例的业务流程中，大家可以发现一条业务流程全部节点并不多，也不复杂，各种判断逻辑较少，但如果将这个方法应用到整个电商后台，是极其困难的，因为无论是商品管理、仓储管理、物流管理还是订单管理，每部分的流程都非常冗长复杂，如果要从头到尾完整地梳理其业务流程，不仅对产品经理来说是个巨大挑战，而且经常会出现遗漏。另外，即使产品经理将业务流程梳理出来，最终得到的流程图的可读性也极差，让人一眼望去头皮发麻。笔者曾与同事用这个方法设计了一个比较复杂的产品，梳理了一个非常庞大的流程图，最后仅打开流程图文件都得耗时几分钟。这个问题也不是简单地拆分子流程就可以解决的，因为我们设计的功能流程要想指导实际的产品设计，节点粒度就要足够细，甚至细到“点击某个按钮”，所以在复杂的业务流程中即使拆分了一些子流程，主流程依然会很复杂，依旧容易混乱。2）模型不匹配流程驱动设计是一种线性思维的设计方法，用开发人员的话说，这是一种“面向过程”的设计方式，而了解过后台开发的人员知道，现在的开发语言主要是一种“面向对象”的开发方式。这种差异就会导致产品经理基于流程设计的产品模型与开发人员所需要的开发模型不匹配的问题。这时架构师或后台核心开发人员就要基于自己的理解重新设计开发模型，但在产品设计初期，我们无法保证开发人员对业务的理解足够准确和深入，而如果理解偏差较大，开发模型设的计就会出错，后面要想修改将是伤筋动骨的。当真的出现问题时，我们也许可以甩锅给数据库设计者，但大家作为一个团队，都需要为最后的结果负责，所以为了避免这种问题，我们最好能够理解开发人员的“面向对象”的开发方式，并为其提供准确、匹配的模型。3）耦合度高在设计B端产品架构时，有个非常重要的原则叫作“高内聚、低耦合”。这是软件工程里的概念，主要应用于面向对象的程序设计中，如果是设计C端产品，产品经理完全不需要理会这个原则，这是开发人员在写代码时才需要遵从的原则，但在B端产品设计中，由于业务复杂，架构师或后台开发同学很难准确、合理地基于这一原则设计后台架构，而业务方又不可能懂得这一原则，所以B端产品经理作为中间桥梁，就需要在进行产品设计时就遵从这一原则，让产品从业务角度做到“高内聚、低耦合”，这样才能让架构师或后台人员更准确合理地设计后台架构。


4）协同成本高一般来说，业务越复杂，开发团队就会越庞大，管理、协同成本也会越高。为了方便管理，公司就会按业务模块划分一个个小的开发团队，各自负责产品相应的部分，这样虽然提升了管理效率，但也造成了新的问题。[插图] 增加了不同团队间的沟通成本。由于很多信息无法及时获悉，导致不同团队针对同一名词的定义不同，沟通时就会出错，也就是大的团队内部难以形成统一用语的原因。另外，业务方与开发团队间也容易出现因定义不一致导致的沟通问题。[插图] 不同团队协同内容、方式、边界不清晰，难以按标准划分，容易疏忽遗漏。某个模棱两可的功能，A团队以为是B团队负责，B团队以为是A团队负责，最后谁都没做，当各个团队成果拼接在一起时才发现，遗漏了各种辅助功能，产品也就无法按时交付。[插图] 各个小团队无法形成对产品全貌的认识。各个团队确定自己要做的子模块后，会进一步将任务细分到团队各成员，这时由于流程太过复杂，团队成员就只能看到自己负责的那部分任务，无法清楚地知道产品的最终目标，从而导致各个成员无法形成对产品的完整认识，从而难以理解自己所负责任务的价值及重要性。为了解决上述流程驱动设计中的四大问题，我们需要找到一个能够化繁为简、设计的产品模型与开发模型匹配，同时又能降低业务模块耦合度、统一团队沟通用语的方法——领域驱动设计。
6.3 领域驱动设计

领域驱动设计最重要的价值之一是帮助我们把庞杂的业务领域有序地划分为一个个相互独立，同时又相互关联的子域。当这些子域确定后，我们还无法拿出具体的产品方案，所以从这一步开始，我们就可以在各个子域内按流程驱动设计的方法进行了。
6.4 两种设计方法的关系

无论哪种设计方式，都有其利弊。图6-32表示的是随着系统复杂程度增加，团队分别利用两种设计方式设计产品。所需开发时间的变化趋势。从这个图中可以看出，当产品复杂度较低时，流程驱动设计所需时间更短；随着产品复杂度逐渐提升，当产品复杂度到达一定程度时，流程驱动设计所需的时间会呈指数上升，而领域驱动设计所需的时间则始终比较平稳，所以从这一点看，流程驱动设计更适合简单的小型产品，而领域驱动设计更适合复杂的产品


领域驱动设计的最后一步大家可以发现，这两种设计方式其实存在一定的包含关系。对于复杂系统而言，我们需要先采用领域驱动设计划分子域，当将复杂领域化繁为简后，在子域内就能采用流程驱动设计的方式了。而且，即使是业务比较简单的产品，我们依然可以先采用领域驱动设计的方式把实体及其相互间的关系分析清楚，这样就可以解决流程驱动设计中与开发模型不匹配的问题，只是不需要再划分子域了。
7.1 工作台

在展示这些数据时，需要注意以下两点。[插图] 数据安全。我们在考虑哪些数据是全局数据时，一方面要满足用户需求，另一方面要考虑数据保密性，有的数据由于比较机密，不适合大范围公开，所以即使用户想知道，也不适合展示。[插图] 数据范围。对于不同层级的管理者及人员，他们关心的数据指标虽然一样，但其关心的数据范围却不一样。例如，图7-1展示的数据指标中，某个门店系统的用户主要关心自己门店的数据，所以我们设计的系统要根据查看人员所属门店展示对应门店的值。
第8章 爱恨交织的业务方

在B端产品的定制化阶段中，有这样一群人：他们是客户，也是用户；他们是专家，也是门外汉；他们坚持己见，又任性善变；他们急不可耐，又慢慢悠悠；他们既要熊掌，也要鱼；他们让你意志消沉，又给你力量；他们是魔鬼，也是天使；他们就是我们的业务
微信读书

3.读后感 & 点评

看完这本书能够学到：

• 对B端产品的整个生命周期
• B端和C端的一些差异
• B端产品经理的能力模型
• B端产品设计的方法：流程驱动设计 、领域驱动设计
• B端的商业化路线
• 一些常用的设计方法（工作台 列表等）

推荐阅读第六章：产品设计 ， 尤其是里面的领域驱动设计部分

看之前只是抱着了解B端产品的想法，没想到会讲领域驱动设计，还挺惊喜的
这部分从产品的视角讲领域驱动设计中的东西，有别于我平常看的开发角度的书和资料，非常有助于我从不同角度看领域驱动设计，在推动产品一起参加领域建模设计活动很有用

4.相关资料

《不枯燥的B端产品实战课》周翔 | 微信读书