《腾讯产品法》读书心得

一、整体评价

书名：《腾讯产品法》

推荐指数：4颗星

整体书评：总体说来不错，推荐阅读，涉及内容很全，从产品思维——需求分析——设计产品——项目推动——产品相关工作（技术、运营、数据分析和营销）介绍——公司及产品战略。正因为如此，能看出这是一本适合二年级产品读的书。

出彩的地方在于都有案例跟随说明支撑每个论点，比如对抽象思维的解释，举了比喻和角度切换的两个栗子。有些例子也能汲取经验，比如通过微信朋友圈分组设置权限的技术架构设计来讲如何拆解任务及通过对比确定最优方案等。

稍微不足的地方是有些例子讲的不够透彻，感觉就像激起了你的好奇和共鸣，但就戛然而止了。还有，就是知识点有点散。

其中最大的一点是讲产品思维部分（思维方式还是很重要的），尤其是抽象思维中的比喻方法，大概意思就是通过找到两种事物共同点，把复杂的难以理解的原理比喻成生活中熟悉的事物，目的还是为了理解事情的本质。比如把抽屉式导航设计的两种模式比喻成三室一厅和联排房子（如下图）、产品比喻成蓄水池，运营的工作就是引进新的水并保证已有存量不流失等；就我自己的应用而言，抽象的区块链比喻成成语接龙、已订业务类比成订单列表页等；还有一个也挺有意思的思考方式——把坐飞机时随着高度提升，视野不断扩展的思考方式用来做产品的聚合和分类——把性质相近的元素合并到一类，再随着观察视角的升高，产品的骨骼就会逐步显露出来。

二、本书结构及举例理解

                                       

三、干货整理（能激起共鸣的部分）

第一节 本质思维：第一性原理

1.已定业务就是，根本不是用户语言

>> 如果我们仔细复盘问题的原因，就会发现，人们执着于错误做法的核心依据是：别人都是这么做的，过去都是这么做的

第三节 抽象思维：大圣的火眼金睛

1. 如何理解具象（即表象）和抽象间的区别，进而有意识地提升自己看产品的眼力呢？

有一个特别的建议。当你搭乘飞机旅行的时候，请挑一个靠窗边的座位，在起飞过程中俯瞰大地并细心留意这一过程中的变化：原本特别清晰的屋顶、田地，会在飞机攀升的过程中不断变小、变模糊。不同屋顶、不同田地间清晰的边界线也会慢慢地消失，逐渐融为一体。随着你观察视角的不断升高，这种相近事物之间的“合并”会进行得越来越快。抽象看问题的方法就和这个升高视角的过程极其相似。

打开地图工具，把缩放比例调到不同的级别上，你也能获得类似的体验。当将地图比例尺调为1∶2000万时，城市看起来只是一个点，但在采用1∶10万的比例尺时，城市是一个有着清晰边界线的区域。

也许你会觉得这个类比似乎没什么用，毕竟产品可不是一张简单的地图。别急，换个角度想想。在地图上，我们依据什么来区分不同的城市和区域呢？对，是它们所处的位置。我们会把位置相近的地方划到一起，会说东边这一块是哪儿，西边这一块又是哪儿。这样，随着观察视角的升高，那些相近的位置就合并成了同一个点。

在产品中其实也一样，只不过我们的依据变了，从“位置”变成了“性质”。如果我们把性质相近的元素合并到一类，随着观察视角的升高，产品的骨骼就会逐步显露出来。因此，抽象的过程实际上就是个先分类、再提升视角的过程。

2.分类加排序

如果我们把性质相近的元素合并到一类，随着观察视角的升高，产品的骨骼就会逐步显露出来。因此，抽象的过程实际上就是个先分类、再提升视角的过程。

3.前段和后台

产品抽象后都是“柜台+货仓

4.赞同

其实抽象能力说穿了就是寻找事物间共性的能力。所以如果想要有意识地训练自己的抽象能力，不妨多使用比喻。我们平时在“打比方”的时候，做的就是和抽象思考类似的事情：提取两个事物性质相同的内核，再给它们画上等号，揉到一块儿。

5.其实抽象能力说穿了就是寻找事物间共性的能力。所以如果想要有意识地训练自己的抽象能力，不妨多使用比喻。我们平时在“打比方”的时候，做的就是和抽象思考类似的事情：提取两个事物性质相同的内核，再给它们画上等号，揉到一块儿。

第四节 系统思维：镜中变色龙

1.如何让“现实”向着我们“理想”中的状况推进，在动态变化的现实中，我们需要修炼自己的系统思维，看懂反馈。

2.我们常说的产品框架设计本质上都是在设计反馈。不过设计反馈最终还是为了解决问题，为了从一团乱麻中找到最重要的那个线头。而只要找对了线头，也就是系统中的“关键解”“破局点”，往往就能实现四两拨千斤的效果。

3.把主流程和异常流程拆分开

第一类，被异常路径左右，抓不住重点。

互联网公司一般都会对需求设计进行组织内的评审，在评审会时，负责开发工作的工程师们往往会很负责地追问所有极端和异常的路径。

面对这种场合，刚开始担任产品经理的我难免会感觉自己像个身在古代、初出江湖的武士。由于功夫拙劣，又不知道暗器会从哪个方向发射过来，总是要集中全部注意力小心应付，一个个勉强地见招拆招，才能避免一不小心被扎成马蜂窝。几轮下来后，当然自己也知道该长点心，下一次梳理会尽可能地考虑周全。

第五节 演化思维：自下而上的设计

1.一个产品能否在现实中“存活”下去，取决于它处的时代背景、产业环境、竞争对手、用户群体特征等众多因素，都影响着产品存活的可能。路不止一条。设计者最关键的任务是“找出那条可以存活下去的路”。因此，互联网市场变化极快，互联网产品就成了最讲究“迭代”的产品。

2.这个绝对正确，想起老公几次创业，就是失败了就换个方向，推到完全重来，那之前的错误都是不值得的

>> 创业时，做一个产品失败后马上再换一个目标，瞄准另一个需求去做新产品，这种方式可不是试错和调整。试错的目的是把同一目标下的错误路径识别出来，进而逐渐逼近对的目标，而频繁更换目标则是一开始没能想清楚，完全是两回事。

第二章

第三节 需求场景分析：角色、场景、方案

1.配图

我们通常会针对优先级最高的场景来设计产品的核心动线。

2.用户体验地图起点为出发行动的点，不是打开APP，需要写具体是由什么场景触发，比如听歌识曲功能体验地图，应该是从用户突然想起一个旋律开始的。

第六节 方案出错，90%是问题错了

1.“问题—拆解—方案—结论”四步法则。其具体操作步骤是：第一步，定义问题。通过弄清“问题背后的目标是什么”进而弄清“真正的问题是什么”；如果目标定义得不准确，就会使一个原本可以被回答的问题变得无法解答。第二步，拆解问题。将复合问题拆解成可以被回答的元问题；元问题的判断标准是能够直接导出相应的解决方案；拆解过程遵循M ECE法则[插图]；第三步，导出方案。根据元问题，一一导出解决方案；第四步，评估得出结论。比较解决方案之间的优劣，做出取舍、得出最终结论。上面四个重要步骤中，又数第一步最重要。可以说，90%的方案错误都是因为没找到真正的问题，或是在执行中遗忘、偏离了真正的问题。

2.不能转化么

>> 体验过且未流失的用户（流失用户可根据未使用时长定义）

3.细心的读者一定可以发现，在导出方案的过程中，其实并没有针对行程中“舒适度”或“社交意愿”等因素导出方案，也没有考虑如何才能减少“等待同行人的时间”，因为这些因素非常依赖于司机和乘客的主观行动，相对不可控

第七节 拆解问题的三种方法

1.全面归纳了三种可供参考的思考方向。第一种，将全流程拆解成各自独立的子环节。第二种，将内部问题拆解到外部去。第三种，将异常流程和主流程拆解开来。

第八节 架构设计：技术方案的十字路口

1. 以微信朋友圈的架构设计为例。丁香园CEO冯大辉曾发布过一条微信产品经理面试题，题目是：朋友圈的基本数据结构设计是怎样的？为何它既能做到完美阅读权限设置，又能兼顾性能？这个问题的定义很清晰，我们可以直接按四步法则把问题拆解为五个问题： Q1：哪些是与性能无关的数据问题？先排除。Q2：微信如何处理关系链中的权限？Q3：从用户刷新朋友圈到所有信息流数据显示到用户手机客户端上，这一过程存在哪些不同的设计方案？Q4：分析这些方案的优劣点，以及它们对产品性能有什么影响。Q5：微信如何做出取舍，确定最终实现方案？ 先来看Q1，比较简单。像文字、图片、时间、位置等数据类型是单独存储的，它们和权限、性能无关。不管是哪种类型，适用的规则都是相同的。再看Q2，微信采用了“标签分组”的方式进行关系链的权限管理。在产品形态上，从表面看是双向关系，底层的数据存储却是单向的，即每个用户各自存储一套自己的通讯录数据。所以，当有人把你从他的通讯录中删除时，你是不知道的，因为你自己的通讯录数据没被修改，这个人还会保留在你的通讯录中。Q3，从用户刷新朋友圈到信息流数据显示出来，这一过程的主要设计方案（细节不论）有：同步内容剔除法，最简单粗暴的A设计方案：[插图]A设计方案图：同步内容剔除用户刷新朋友圈时，先读取用户所有朋友的消息数据，然后进行筛选过滤，把不应该展示的数据给依次剔除掉。比如没有查看权限的消息、已经屏蔽了的用户消息。采用异步内容分配法的B设计方案，将大计算量在时间上进行重新分配：[插图]B设计方案图：异步内容分配当用户发送消息到服务器时，服务器立即依据好友关系中的“分组标签”，将消息分配给存在标签的用户。不过这时分配的消息是存在每个用户的

Timeline中的。这个Timeline我们可以理解为每个用户单独拥有的一个准备数据池。然后接收方用户在刷新朋友圈时，直接拉取自己那份Timeline中的数据，客户端做一次屏蔽过滤操作，把用户屏蔽掉的消息剔除就可以展示出来了。

B方案的差异版C方案：与B不同的处理方式是：把屏蔽人消息过滤放在最初消息发布时来做，而不是接收端最后来过滤。

Q4：下面来比较一下A、B、C三种方案在性能方面存在的差异。

我们知道，微信拥有海量用户，每个用户在任一时刻都可能执行“刷新朋友圈”的动作，这一个小小的动作有着极高的并发量。

按照方案A，用户每次刷新朋友圈，客户端都要跑到消息池里去找通讯录朋友们的消息，还要对找到的每条消息执行逻辑判断。这种执行效率显然是不能被接受的。

而按照方案C，在消息发布时如果就考虑屏蔽的人，那就意味着要去读取每个有权限阅读的人的屏蔽人清单，再根据每个人的清单决定是不是放到这个人的Timeline中，这种操作显然会增加计算量，降低方案效率。事实上，我们可以通过一个方法来验证C方案不是微信的选择：当用户把一位好友屏蔽时，不会看到对方的任何消息，但如果用户在此时取消屏蔽，则立即能够在朋友圈中看到这位好友发布的所有消息（包括在屏蔽时间内消息）。

不过B方案也并非十全十美。运用B方案意味着朋友圈的消息不能编辑，只能删除。因为权限控制是在发布消息时就确定的，如果增加编辑功能，一旦用户在编辑时调整了阅读权限，就需要将之前写入用户Timeline中的数据给删掉重写一遍，成本比较高。不过这一点缺陷在产品侧看来不仅可以接受，还进一步约束和简化了朋友圈的操作。这就是产品需求与技术实现达成的一种共赢。

所以Q5的答案来了，我们会认为方案B才是微信最终选择的架构方案。

第九节 交互与视觉

1.缺图

改版前问题分析图

2.get，先穷举再分类

>> 元素分类，得到最佳聚合方案图

>> [插图]

3.选择多意味着用户要去花时间成本去思考

4.微信朋友圈点击和长按发布内容不同的思考：吓得我翻了一下我的朋友圈，可能微信PM早料到人们更愿意发文字+图的状态，所以点击是发图文，长按是发纯文字，点击的成本远低于长按的操作成本。按照一般的产品设计，是点击给出选项，让用户去选择发文字还是图文，嗯，多了一步确实会流失。给伟大的微信PM点赞。拆解任务，嗯嗯。

5.不过设计时还是要回归产品本身的特质，具体问题具体分析。比如，微信的语音会话按钮选择“按住”说话的交互，而Instagram里拍摄视频的按钮则选择“按一下”拍摄而非“按住”。其中的关键区别就在于，人们拍摄视频的操作对象是视频画面，注意力焦点全都集中在手机画面上，对进程意识强烈，非常清楚什么时候该执行结束操作；而语音会话时则不然，很少人自始至终盯着手机进度讲话的，这时利用动作的限制因素就显得特别重要。

6.重要的永远是关系。不只是“人与产品”的关系，设计还应体现“人—产品—社会—环境”之间的关系。

7.颜色就是最直观的分类工具，大面积运用色块可以有效提升用户识别度。想象一下携程和去哪儿网首页如果没用色块区分，仅仅使用文字和icon组合，用户要找到自己需要的服务将有多么费劲？

8.心理学上有个概念叫Familiarity bias（熟悉度偏见），说的是人们倾向于相信自己熟悉的东西。可以利用用户的熟悉感来做产品，就会降低用户排斥感；

9.说得好，我往往就会纠结于几个小的点，反复改原型设计

当我们沉迷于原型图的细节，不断修改打磨时，不妨停下来问问自己：它们真有那么重要？同样的时间成本，我可不可以用来做点更重要的事，能在产品前几个层级拿分的事？骨骼没有验证之前，绝不能一头栽进雕琢细节的工作里。

10.细枝末节的优雅无法代表一个产品的格调，真正的优雅体现在产品解决问题的方案上。

第四章

第一节 开发迭代

1.确实变更需求会存在，但不能以此为借口为自己出错找理由

>> 由于“最佳解决方案”出现时机并不总是可控，需求变更的发生往往不可避免。假如项目管理者把需求变更视为恶瘤，欲除之而后快，最终扼杀的往往是“产品更好的可能”。这时，将需要变更的需求按优先级排列管理起来，根据项目开发进度阶段性满足，将是更为明智的选择。

第二节 抓住运营的本质

1.赞同，产品可以抄袭，运营积累的数据和流量是复制不来

>> 长期来看，产品运营能力本质上才是一个产品的护城河。

2.如果池子里的水满了呢？是不是产品就进入衰退期了？

>> 产品运营工作的核心模型在业内其实已有一个基本的、形象化的共识——蓄水池。

3.嗯嗯

>> 产品运营的核心工作就是聚焦产品的开源节流。具体到操作层面，开源就等于我们熟悉的拉新和促活跃，而节流则对应着防止用户流失（留存）和挽回用户流失（回流）。

4.

>> [插图]AARRR行为深度VS感情深度对比图

5.通常电商类产品会用客单价和复购率作为衡量付费行为的指标，前者代表消费力，后者代表消费频次和可持续性。

第三节 数据分析的误区

1.只观察版本变量对用户的影响，具体做法可以选择新旧两个版本发布初期（比如发布后七天）的新用户来进行对比分析。这些用户都是首次接触产品，只有接触的版本不同，这样对比各项指标得到的结论就能更接近用户对产品的真实反馈。

2.所以我们在分析产品数据时——尤其是电商类、游戏类、增值服务类等产品类型，一定要对产品的用户群进行分级。只要涉及“平均”指标的数据，都尽量到同级别用户里去做统计。

3.看平均数首先要看分布，其一指不同人群比如不同分类用户的平均值，比如电商里面高活跃用户和沉默用户平均计算一个复购率，明显不科学，其二，看分布态势，正态分布可代表平均状态，长尾分布就不行。看占比要看总数

>> 谈平均不谈分布，谈比例不谈总量，都是耍流氓。

4.有点意思，解决方案就是分类统计，不能一概而论

>> ——这就是统计中著名的辛普森悖论（Simpson's Paradox），它是比例的另一种误区。辛普森悖论由英国统计学家E.H.辛普森（E.H.Simpson）于1951年提出，描述的是某个条件下的两组数据，分别讨论时都会满足某种性质，可是一旦合并考虑，却可能导致完全相反的结论。

第四节 产品营销=内容+渠道

1.new 技能get

>> 质量系数=用户活跃参与×40%+用户留存×20%+获取收入×30%+用户推荐×10%

数量系数=用户获取×40%+用户活跃参与×30%+用户留存×30%

根据这个公式，我们就能判断出有一些平台我们是不是该舍弃掉，又或者根据根据它们的特性做出适当的调整：当它处于低质量高数量的时候，我们就应该调整渠道策略和投放的要求，当它处于高质量低数量的时候，我们就应该扩大渠道引入数量。

2.用户根本不会为一件原本免费提供的产品买单，在他们看来，QQ注册收费是一种敲诈的行为。

3.寻找第一头羊，

>> 拿下第一个用户，要求产品经理人吃透人性。以游戏产品为例，玩家们玩游戏追求的是什么体验？什么体验称得上好玩？我们归纳出一些词汇，比如快乐、成就、荣耀等等。

4.好的产品自己会说话，渠道不同内容调性不同。现在不仅产品是渠道，每个人也都是渠道

>> 产品即渠道，渠道即内容

第二节 构建壁垒

1.这个有点牵强附会了吧

>> 放在各种环境中都适合，是已经完成了而且被验证成功的方案。而且，这个方案所定位的市场用户也和你计划的一样。这时候，你需要再做一个完全不一样的方案去创新吗？这不叫创新，这叫浪费成本。

2.波特提出的五种力量，分别为：同行业内现有竞争者的竞争能力、潜在竞争者进入的能力、替代品的替代能力、供应商的讨价还价能力、购买者的讨价还价能力。