# 第 5 章 验证产品概念 确定产品概念是提出一系列假设的过程，验证产品概念是逐一检验这些假设的过程，包括对获客相关的假设、留存相关的假设、变现相关的假设，等等。产品概念是否切实可行，取决于支撑产品概念的这些假设是否成立，我们需要通过一个又一个的项目来得出验证结果，要用科学的方法“把事情做对”。 ### 5.1 步入项目循环 什么是项目？项目是为完成某一独特的产品或服务所做的临时性努力。这个定义里有两个关键词，首先是“独特”，意思是每个项目的结果都是不重复的，如果重复产出某种产品或服务，那叫流水线；然后是“临时性”，我们当然不希望项目无休止地进行下去，最好能有明确的开始日期和结束日期。在互联网行业，每个产品版本通常对应一个项目，项目的独特性体现为每个版本的产品需求都不一样，项目的临时性体现为产品团队要在预定的时间范围内完成这个版本的设计、开发、测试和运营。当然，一个营销或运营活动也可以对应一个项目。 #### **项目管理的必要性** 就像没有压力管理，压力也是存在的，项目是客观存在的，即便没有项目管理，“为完成某一独特的产品就像没有压力管理，压力也是存在的或服务所做的临时性努力”也是存在的。如果没有项目管理，我们无法回答一些很重要的问题，比如：完成这个项目需要多少人、多少资金、多少时间？或者，以产品团队现有的人力，完成这个项目需要多少时间？ 人类从原始社会就开始分工协作，男性外出狩猎，女性采集果实茎叶。到了马克思写《资本论》的时候，分工已经细化到“制针手工工场的针条要经过 72 个甚至 92 个专门的局部工人之手”。产品团队中有产品经理、交互设计师、视觉设计师、后端工程师、前端工程师、测试工程师、运营经理等岗位，从实际工作来看，产品团队并不是工业流水线，不是上游环节做完交给下游就不用管了，产品团队中的岗位之间存在复杂的网状关系，而且经常需要反复沟通。 比如视觉设计师把设计稿拿给产品经理确认，中间可能要修改几个来回，得到一个“发誓再也不会改了”的版本后交给前端开发工程师和测试人员。前端开发工程师在开发过程中发现有些设计不太合理，找产品经理和设计师商量修改，得到“这次真的再也不改了”的版本。开发实现后，产品经理、视觉设计师和测试人员又要确认产品和设计稿有无区别。如果不能在这个复杂的网状结构里梳理出一个清晰的协作模式，产品团队中就没有人能回答“完成这个项目需要多少时间”，更不要说确保项目能够按时完成了。 那么，这个网状结构中人与人的连接数和团队规模是什么关系呢？答案是 *f*(*x*)=*C*(*x*,2)=*x(x-*1*)/*2，如下图所示。

团队成员数和成员连接数的关系

10 人团队中的连接数是 45，20 人团队中的连接数是 190。团队的协作效率取决于所有连接的连通率和带宽，随着团队成员增多，出现连不通（水火不容）和低带宽（鸡同鸭讲）的可能性就越大，团队的协作效率就越难保障（团队中个体的感受可能是参与感降低），所以，敏捷开发通常建议一个团队的规模不要超过 9 个人。 {% hint style="warning" %} 思考题：为什么一些互联网公司宁愿付高薪让员工 996，也不愿意通过扩招分摊工作量？ {% endhint %} 可是很多产品团队并不是只有几个人，而是有几十人、几百人，他们的连接数不就“爆炸”了？通常的解决方案是保持每个最小单位的团队只有几个人，限制最小单位内部的连接数，同时把这个单位看成一个整体选出代表和其他单位进行连接，限制最小单位和最小单位之间的连接数。比如最小单位 9 个人，一共有 9 个最小单位，每个最小单位选出 1 人进入第 2 层级进行跨单位的沟通，正好又组成了一个 9 人单位。这时整个团队的规模为 81 人，连接数是 360，而不划分最小单位的话 81 人的连接数是 3240。81 人还不够的话，可以增加层级，扩容到 729 人甚至 6561 人、59049 人（9^n）。 这样做的好处是大幅降低了连接数，代价是整个组织结构的效率严重依赖各层级代表的效率，一个代表连不通或低带宽就会影响与其相连的一群人的效率，越高层级的代表影响范围最大。所以，每增加 1 个层级，整个大团队就会面临全新的管理挑战，即便资本杠杆允许无限加人，也不是每个产品团队都能顺利实现 3 层团队结构和 4 层团队结构。 {% hint style="warning" %} 思考题：服务 14 亿用户和服务 3 亿用户的难度一样吗？ {% endhint %} > **大团队的协作现状** > > 我自己已经很久没有在大厂工作了，为了搞清楚大团队和小团队在协作中的区别，我采访了一些大厂的朋友，他们提到一个很有意思的词——“即兴演讲能力”。通过这个词，我们可以一叶知秋。 > > 虽然一个最小单位的团队人数不多，但一个大产品会有很多这样的团队，而且会有多个层级的领导，产品经理这样的岗位不可能只在自己所属的小团队内部进行沟通，而是要跟大量相关人员沟通，在大团队中工作需要维护的人际连接是小团队的数倍。每一条连接都有信息流动，维护这么多连接，不光自己的时间不够用，其他人的时间也很紧张，这就要求产品经理在更短的时间内完成每一次的信息交换，把握住一切可以交换信息的场景，随时随地来上一场“即兴演讲”。 > > 与独自思考的效率相比，人类在相互沟通时的效率很低，当沟通占用了一天中越来越多的时间，可以用来做其他事情的时间自然就变少了——要么是独自工作的时间变少，要么是照顾家庭的时间变少，要么是休闲娱乐的时间变少，要么是睡觉的时间变少。 如果产品团队只有一个人，产品是我，开发是我，测试也是我，我还需要项目管理吗？也是需要的，即便一人成团，也要回答“完成这个项目需要多少时间、多少资金”，这就需要在项目启动的时候做好评估，提前规划好每天做什么工作，这就是项目管理的工作之一。即便没有协作的瓶颈，也要管理好每天的时间才能确保项目按时完成，这也是项目管理的工作之一。 为什么“验证产品概念”不直接验证支撑产品概念的假设，而是先用了这么多篇幅讲项目和项目管理？我见过许多没有代码仓库就不写代码的程序员，也见过许多没有人做会议纪要就不开会的管理者，这些都是有助于提升效率的好习惯。当我们有了一个产品概念和一个产品团队，我们当然希望产品团队能火力全开地验证产品概念，而不是三天打鱼两天晒网不知道什么时候才能做完第一个项目，所以，没有项目管理就不做项目也是一个好习惯。 #### **项目周期的刚性** 团队相对个人是一种杠杆，如果团队的效率没有超过甚至不及个人（不要以为这很荒诞），就变成了无效杠杆或负杠杆，项目管理通过项目流程来尽量避免这种情况发生。为了“火力全开”地实现目标，项目流程是一个循环往复的过程，比如我们要做一个“饮水易”应用，产品经理在第 1 周（循环的周期不一定以周为单位，这里只是一个示例）完成 0.1 版本的产品需求文档之后，第 2 周就会开始撰写 0.2 版本的产品需求文档，而不是等 0.1 版本发布、运营后在第 5 周才开始撰写 0.2 版本的产品需求文档，如下图所示。开发、测试、运营的工作安排和产品类似，大家都处于接近饱和的状态。
第 1 周第 2 周第 3 周第 4 周第 5 周第 6 周
0.1 版本产品设计产品开发测试发布运营
0.2 版本产品设计产品开发测试发布运营
0.3 版本产品设计产品开发测试发布运营
*甘特图* 我们可以设想一下，如果项目流程中的某个环节发生了延误，会发生什么？首先，会导致之后环节的人员空等，比如产品设计延误了两天提交设计方案，产品开发就要空等两天。其次，可能会导致项目延期，比如开发、测试、运营都顺延两天，项目就会延期两天，这就会导致后续的项目周期被压缩或者需要顺延。这些都是我们不愿意看到的情况，所以项目管理非常强调项目周期的刚性。项目经理就像坐在龙舟船头的鼓手，项目周期就像稳定的鼓点节奏，产品团队的其他成员都是跟着鼓点划桨的桨手。没有这个鼓手，龙舟会变轻，但是不会变快。 刚性是一个相对的概念，不是说项目周期定下来就不能变，就像龙舟的鼓手可以改变鼓点节奏，项目的周期也是可以变的。比如产品早期的项目周期以天为单位，后面逐步过渡到以周为单位，还可能进一步过渡到以月为单位。项目周期要和产品的发展阶段相匹配——产品需要更快的迭代，项目周期就变短；产品需要一个版本实现更多需求，项目周期就变长，这是有计划的变化，变化中依然有相对的刚性。 为了保障项目周期的刚性，让团队保持稳定的节奏不开天窗，我们需要：合理的项目目标、准确的估时和可控的需求变更。 合理的项目目标是我们把项目管理的内容放在产品设计之前介绍的另一个原因：项目周期是预先制订好的，一个项目周期或者说一个版本可以实现多少产品需求是被这个周期所约束的，而不是先出产品需求再定项目周期，否则可能会导致每个项目所需的时间差别很大，很多团队成员面临无所事事的空等。如果一个需求需要的实现时间很长，比如更换全新的产品架构，需要 5 个项目周期的时间，可以把它拆成 10 个项目来做，每个项目一半的时间做这个需求的 1/5，剩下一半的时间做其他需求。 产品经理没办法独自完成对产品需求所需的开发、测试、运营时间的估时，这需要每个岗位各自评估。为了避免一个项目周期内的工作不饱和，产品经理通常会在做每个版本的产品设计时多放进去一些需求，在估时阶段暂时砍掉部分需求。估时考验的是每个岗位对项目目标的认知，大家对项目想要达成的目标认识越到位，就越清楚需要用什么方法达成，估时就越准确，从而产品版本的发布就越准时，项目周期就越稳定。 还是以“饮水易”为例，0.1 版本在第 2 周进入了开发阶段，其间如果产品需求频繁变更，开发所需要的时间就容易延长，有可能会影响到 0.1 版本的测试时间、发布时间，而我们不希望项目周期的刚性被破坏。在开发团队估时的环节，开发工程师对产品需求的了解是非常充分的，考虑技术方案的时间也比较充裕；进入开发阶段后，开发工程师的主要工作变成了开发，通常没有充足的时间了解需求变更，给出的技术方案可能也考虑不周，这会带来项目质量不达标的风险。要做到需求变更可控，产品经理需要在正式提交产品需求文档之前尽量考虑周全，如果在提交之后遇到非变不可的情况最好能一次变更到位。 #### **超越项目目标** 当我们实现了“火力全开”后，就会冒出更贪婪的想法：能不能超越项目目标呢？比如加快版本迭代的节奏从而缩短项目周期，或者一个项目周期里实现更多的产品需求。在约束了版本周期、项目目标和资金这几个项目变量之后，剩下的变量就只有团队本身了。团队和项目管理的关系是基数和系数的关系，比如产品团队的生产力是10，项目管理所产生的团队效率系数是 65%，团队的实际生产力就是 10×65% = 6.5。项目管理可以将团队效率系数从 *x*% 持续提升到 99%，但决定团队实际生产力天花板的还是团队生产力本身。 团队配置不合理是比较容易发现的问题。如果一个团队里有 4 个前端开发工程师、6 个测试工程师，只有 1 个后端开发工程师，后端开发很可能会成为团队生产力的瓶颈，前端开发和测试则可能存在人力浪费。当然，每个人的工作能力不同，有些技术牛人的确能够以一当千，如何配置合理需要在项目实践中摸索。 信息技术专家詹姆斯·马丁（James Martin）在 1991 年提出 SWAT 团队的概念，即 Specialists With Advanced Tools，“牛人牛工具”。如果团队内的每个成员都是各自领域内的专家，都有自我驱动力，工作中积极思考、及时提交、快速衔接，再配合上成熟高效的工具，团队生产力的基数必然爆表。可现实情况大多是“普通人烂工具”，比如同样是做推荐系统，牛人牛工具有推荐领域的专家，有研究生标注员给每个内容打上精确的标签，有验证成功的算法，有完备的数据平台，有高效的 A/B 测试平台；普通人烂工具一穷二白，还没有专职的项目经理提升团队的整体效率。 “天下武功，唯快不破”，行业认知会限定产品的高度，动作快慢则决定能不能抢占先机。有些大公司用牛人当前薪酬的 1.5 倍（打包价，包括工资、奖金、股票等）挖人，就是希望通过资本杠杆来快速试错，组建 SWAT 团队。挖过来的人如果工作表现符合预期，说明之前的公司低估了他的价值，入职后照常升职加薪。如果工作表现不及预期，接下来很长一段时间就不会给他调薪了，他不接受自然会主动离开，公司不用额外补偿；接受的话就继续工作，时间足够长了之后综合用人成本也就回归真实价值了。 **团队发展五阶段** 俗话说得好，三个臭皮匠顶个诸葛亮。普通人烂工具也不用灰心丧气，牛人凑在一起不一定能形成默契，普通人烂工具如果能有效协作，也能挖掘出超出自己想象的生产力。美国心理学家布鲁斯·塔克曼（Bruce Tuckman）提出了著名的团队发展阶段模型，指出团队发展分为四个阶段：形成期（forming）、风暴期（storming）、规范期（norming）和成熟期（performing）。后来塔克曼又添加了解散期（adjourning），使之成为团队发展五阶段模型。我根据自己对多个团队的观察，在塔克曼的团队发展五阶段模型内重新绘制了一条团队绩效曲线，如下图所示。

团队绩效曲线

我们简单来看一下这五个阶段。 形成期的典型问题是表面上一团和气，每个人都觉得管好自己就好，团队里没人愿意当“坏人”（“好人”“坏人”这种简单二分其实有点幼儿园思维），导致限制团队生产力的问题没人敢提也没人解决。这可能影响产品的迭代速度，丢失市场份额，最后大家都没了工作，却没有一片雪花觉得自己应该对雪崩负责。 进入风暴期后大家终于憋不住开始相互指责了，但问题是只有争吵和甩锅，没有责任划分和行为规范。产品经理觉得开发工程师不够主动，总是推卸责任，弱网可用（在网络连接不稳定、网速很慢的情况下产品依然能提供服务）的问题需要产品经理研究清楚写成产品需求文档才做，而产品经理对弱网的了解显然没有开发工程师多；版本发布后产品质量总是出现问题，需要连续发布多个修复版本，影响了更新节奏，但开发工程师却说是测试的问题。 如果开发工程师觉得产品经理提的需求不靠谱，实现后不会带来增长，就应该告诉产品经理，请产品经理讲清楚增长的逻辑，明确每个需求的增长目标；产品需求实现之后产品经理没有把线上数据同步出来，开发工程师感受不到自己工作的价值，这时候就应该要求产品经理做好数据同步；如果产品经理觉得弱网问题应该由更懂技术的开发工程师自己提出目标，作为技术需求加入版本，就需要和开发工程师协商彼此的职责界限。当大家达成共识，团队内建立起明确的规则，就进入了更高效的规范期。 如果团队中有人拒绝接受共识，不服从规则，变成了整个团队进入规范期的拦路虎，团队负责人就需要计算一下清理拦路虎的代价了，有没有人可以替代他的工作，把他清理出团队需要多少成本？还是任由他阻碍产品的发展、破坏团队的利益？ 当团队成员彼此坦诚、彼此信赖，整个团队越来越默契，团队就进入了成熟期。随着产品或项目的结束，团队会进入解散期，相濡以沫不如相忘于江湖。 团队生产力问题和产品增长问题是类似的，需要团队所有成员一起寻找瓶颈，突破瓶颈，调整团队构成，不断完善项目流程和沟通方式。这不是项目经理一个人的工作，如果团队成员只是被动“配合”项目经理的工作，团队生产力是提升不了多少的。 {% hint style="info" %} 当产品团队中没有项目经理这个岗位时，项目管理的工作可能会落到产品经理肩上，但这不是一个好主意。不管项目成员有多专业，估时的时候被抠细节讨价还价，项目执行的时候被人盯进度，这类事情总会让人感觉不舒服（人性使然），会消耗彼此的关系，而产品经理开展工作又很依赖于关系，这就是无法调和的矛盾。此外，产品经理也不一定能做好自我管理，全职项目经理可以催着产品经理完成产品需求文档，管理好产品经理的需求变更，避免产品经理成为团队的效率瓶颈。同理，运营经理、增长经理、开发主管也不适合兼任项目经理。 {% endhint %} ### 5.2 假设 有一句半玩笑半认真的流行语不知道大家有没有听过，“这不科学”，这里的 “科学”代表着可行、严谨、高效等。我们怎么科学地做项目？是不是有了项目管理就科学了？怎么做才够科学这个问题在 400 年前就有答案了。弗朗西斯·培根在他的著作《新工具》中给出了自己的“科学研究方法”，即强调明确研究目标，开展针对性的实验，归纳总结实验中得到的经验，检查和核对由经验得出的理论是否适用于更广的范围。后来逐渐发展形成了“假设—实验—评估”（hypothesis, experiment, evaluation）科学方法过程—— 首先明确假设，然后设计相应的实验进行验证，最后评估实验结果看假设是否得到了验证。 这难道不是常识吗？还真不是。很多项目实施过程中会出现类似“我喜欢蓝色所以改成蓝色”这样的需求，这并不是在验证用户喜欢什么，而是在满足个人喜好。项目发布后不评估项目效果，直接开始下一个项目的情况也很常见。所以，做产品也应该套用“假设—实验—评估”这套科学界认可的过程，让做产品变得更“科学”。做产品的过程中所追求的“科学”主要是工程上的效率，而不是通过彻底搞清楚事物的规律。在实际工作中，基于自己所设想的“假说”取得了好的实验成果就可以了，通常不会更进一步验证这些“假说”的可证伪性把它们变成科学理论。 在做内容（包括广告）分发的时候，通常会给每个内容先分配一定的展示量，收集到用户对内容的反馈后挑选反馈最好的内容加大它的展示量，这是威廉·汤普森在 1933 年提出的方法，名为汤普森采样。从科学的角度来看，为什么小展示量时表现好的内容在放大展示量后表现也会好并没有得到证明，直到汤普森采样问世 80 年后的 2013 年，微软印度研究院的 Shipra Agrawal 才给出了这个问题的数学证明。但是从工程的角度来看，汤普森采样是管用的，用户喜欢的内容得到了更多的分发，显著提升了分发效率，这个方法是不是科学理论并不耽误产品团队使用它。 为了保持目录的简洁并突显产品经理的工作内容，我们用“假设—实验—评估”循环来对应项目循环，其中假设对应项目中的假设管理和产品设计，实验对应项目中的开发、测试和运营，评估对应项目发布后的评估。 #### **管理假设列表** 我们在本章一开始就提过，确定产品概念是提出一系列假设的过程，这些假设会累积成一个假设列表，验证产品概念的过程是对照着假设列表检验这些假设的过程。其实当我们确定一个产品概念后，除了想到支撑概念的基础假设，还会很兴奋地畅想产品发展过程中的种种可能，记录下来一大堆面向未来的假设。从公司的平均寿命和获得 B 轮融资的比例来看，我们关于产品概念的假设有很大概率是不成立的。那么问题来了，你是希望用几周的时间加 1 万元资金来验证假设得到一个结果，还是希望用一年的时间加 100 万元资金来得到一个结果？ 谷歌 X 实验室负责人阿斯特罗·泰勒（Astro Teller）经常分享下面的寓言故事。 设想一下，假设你需要教一只猴子站在台子上背诵莎士比亚的作品。你要如何在训练猴子和建台子之间分配时间和资金？ 正确的答案当然是不要在建台子的问题上花费任何心思。但毫无疑问，至少有一部分人会急着上马开始搭建华丽的台子。为什么？因为你并不知道什么时候老板会突然现身，要求你汇报项目最新进展——你希望自己随时能够展示点儿什么，而不是只有一堆“教猴子说话真的很难”的理由。 这个故事道出了提高假设验证效率的一个重要原则，先把确定性高的假设踢出假设列表。故事里的需求包含两个假设，一是猴子站在台子上，二是猴子背诵莎士比亚的作品（比方说是《哈姆雷特》）。这个需求能不能被满足，取决于这两个假设能不能同时成立（逻辑与），也就是说只要有一个假设不成立，这件事就可以放弃了。我们在马戏团或者电视里见过猴子站在台子上，这是猴子可以做到的事情，这个假设的确定性很高；我们没见过猴子说话，更别说背《哈姆雷特》了，这可能是猴子做不到的事情，这个假设的不确定性很高。整个产品概念是否成立，主要取决于不确定性高的假设是否成立，所以在找到会说话的猴子之前，我们不应该在建台子的问题上花费任何心思。 在大刀阔斧地精简假设列表之后，我们还可以通过排序来继续提升验证效率。把验证时间短、成本低的高不确定性假设排在列表前面，把验证时间长、成本高的高不确定性假设排在后面。排序完成之后，如果前面一两个假设很快得出了不成立的结论，我们就可以得出产品概念无法成立的结论，那么假设列表里剩下的费时费钱的假设就可以烟消云散了。 {% hint style="info" %} 并不是所有失败都是成功之母，科学的不致命的试错才是成功之母。 {% endhint %} 还是以视障者公益交友平台为例，这个产品概念需要验证的假设是用户规模、获客和留存。其中，留存多多少少需要开发点儿东西出来才能验证，而开发就需要招人，这就是很大的成本（2020 年一线城市综合用人成本可以按人均每月 2 万元估算，解除劳动合同还要赔付一笔钱）；而获客则找到视障者集中的产品投放广告或者软文就可以验证了。 既然验证获客时间更短、成本更低，那就把它排在前面。自己动手制作一个无障碍交友平台介绍网页（这个网页要符合无障碍的规范），让访客留下性别、年龄、联系方式等信息，以便产品发布的时候收到通知；找到视障者社区，尝试用发帖和广告的形式推广这个网页，就可以得到广告千次展示价格、广告点击率、转化率（愿意留联系方式的比例）、种子用户数（留下联系方式的人数）、种子用户画像等关键信息，从这些信息就可以大体判断获客杠杆是否有效以及用户规模是否符合预期。 既然我们想把验证时间短、成本低的高不确定性假设排在前面，那么排序的过程也就是为每个假设设计验证方案、估算验证时间和验证成本的过程。如果能给验证时间长的假设设计出更短时间的验证方案，或者能给验证成本高的假设设计出更低成本的验证方案，它的排序就可以提前。互联网行业将这种耗时短、成本低的验证方案称为最小可行产品（Minimum Viable Product，MVP）。 #### **最小可行产品** 电影行业的最小可行产品非常成熟：想到一个故事后先找些人聊，看看大家是否感兴趣；能通过这一关就把故事写成剧本，看电影公司愿不愿意投资，剧本修改之后拿到了投资；进入故事板（storyboard）阶段，可以理解为把剧本画成了漫画，看看画面能否把故事讲好；然后是动态分镜（animatic），找配音演员配音，和故事板的画面合成在一起，变成有声音的幻灯片电影，可以让人更直接地感受电影效果；现在 3D 技术很成熟，一些电影多了一个预渲染（previsualization）阶段，用粗糙的 3D 动画替换故事板的画面，做成简版动画，画面更接近成片效果；这一关也没问题了，正式开机拍摄。

《曼达洛人》的故事板

《曼达洛人》的预渲染

这个过程验证了一系列假设： * 故事是否有趣？ * 影像化之后的故事是否有趣？ * 加入配音后的影像是不是一部有趣的电影？ * 动态画面能否让故事更有趣？ 光听最小可行产品这个名字，可能会想当然地认为要做出一个最小可行产品，其实它是“最小可行系列产品”。一系列最小可行产品按照综合成本（包括时间成本和资金成本）从低到高排列，其中每个最小可行产品都能用来验证最终成品。简单粗暴地把电影分成四幕依次拍完，就不是最小可行产品：一是每一幕的综合成本并不低（和剧本、故事板相比），把一部电影拆开来拍会增加对场地和人员的时间占用，总成本也会更高；二是看 1/4 部电影并不能了解整个故事，达不到验证假设的目的。下图展示了虚假的最小可行产品和有效的最小可行产品。

虚假的最小可行产品和有效的最小可行产品

电影《冰雪奇缘》的预算是 1.5 亿美元，在最初的剧本里冰雪女王本来是反派，创作组在讨论中突发奇想，把她设定为主角安娜的姐姐。如果这个改动是在电影开拍后发生的，你能想象要额外增加多少预算和时间来做修改吗？同样是工业化生产的游戏行业，300 人团队开发了 4 年的《塞尔达传说：旷野之息》在正式制作之前，先抽调小团队制作了一个 2D 版本来验证游戏玩法。

《塞尔达传说：旷野之息》制作特辑里展示的 2D 版本

互联网行业之所以需要持续强调最小可行产品，核心问题在于它属于行业认知，没有多少公开的信息可以借鉴。我们能够了解电影行业的最小可行产品，是因为这个行业共享一系列标准的最小可行产品，不同的电影基本都经历类似的制作流程。然而即便我们知道电影有动态分镜，作为普通观众也看不到电影的动态分镜，也不知道动态分镜的测试标准是什么，达到什么效果后可以进入最小可行产品的下一阶段。同样，作为普通用户，我们也看不到某个产品的全系列最小可行产品，因为有些最小可行产品只在产品团队内部测试，有些最小可行产品只对一小部分用户进行灰度测试。 我们很难充分了解 Supercell 制作游戏时的最小可行产品系列包括多少个最小可行产品、各是什么样子、每个最小可行产品的评价标准是什么，我们也很难充分了解“App 工厂”字节跳动的最小可行产品细节。这是它们降低试错成本、提升竞争力的行业认知，没有理由对外分享。就算我们了解其他产品的最小可行产品的设计思路，当我们创造一个新的产品形态时，大概率还是要为它量身定制最小可行产品（任天堂新出的编程教学游戏《附带导航！一做就上手第一次的游戏程序设计》有 7 个游戏教程，每个游戏教程都有量身定制的最小可行系列产品），并不能直接照搬其他产品的思路。 基于上述原因，互联网产品经理中有很大一部分没有经历过工业化生产的洗礼，有些人能理解低成本验证的价值，有些人则觉得产品没做到自己满意的水平拿不出手。我们大都没有超能力去改变别人的想法，因此，大家在选择工作伙伴的时候需要注意一下这一点。 {% hint style="info" %} 验证产品概念并不需要产品可以运行。为设想中的产品做一个能展现其价值的宣传视频，发给朋友看收集反馈，投放到广告网络里面收集点击率，就可以达到早期验证的效果。 {% endhint %} 如果我们想验证的假设已经有人实现了，其实可以把它们看作免费的最小可行产品。比如，苹果就可以从“越狱市场”的应用中寻找成功案例，《堡垒之夜》研究《 Dota 2》的战斗通行证就可以验证自己的不少假设。当然，我们的产品也很可能会变成巨头们的最小可行产品。但研究别人的产品不能完全代替自己的最小可行产品。《堡垒之夜》发布后的第一个赛季只验证游戏玩法和赛季制的可行性，第二个赛季才开始验证战斗通行证与变现杠杆。如果玩家对游戏玩法本身或赛季制不买账，自然就不必再做战斗通行证了。 #### **避免过早优化** “验证产品概念”这六个字，从字面意义上理解似乎是验证最小可行产品，最小可行产品的确包括了大部分高不确定性的假设，但在产品的整个生命周期中，“假设—验证—赢得市场份额”是循环往复持续不断的。验证产品概念并不是一次性的工作，我们不能说在验证了获客假设之后它就结束了，也不能说在验证了留存假设、变现假设之后它就结束了，只要还有新的假设冒出来就需要被检验，“验证产品概念”就不会停止。在“假设—验证—赢得市场份额”这个循环中，如果产品经理对假设列表的精简和排序出现了失误，比如偏离了突破增长瓶颈的假设，就会掉进过早优化的陷阱。 在寻找会说话的猴子和建台子之间选择先建台子就是过早优化，在讲产品经理的非权力性领导力的时候提到的“自建广告系统”和“10 万用户同时在线”也是过早优化。过早优化就好比浮云之上建大厦，大概率会变成伪工作。把时间和资金花在过早优化上，对产品当前的竞争力只会产生负面影响。 要避免过早优化，就要看清关乎产品概念成立与否的高不确定性假设有哪些，就要发现产品当前的瓶颈是什么。相比产品还没有开发上线时的假设列表，已经上线并且正源源不断产生数据的产品更复杂，发现瓶颈是个挺困难的工作。多数情况下，即使团队外的人明确指出瓶颈，产品团队也可能会拒绝接受，因为当产品经理不具备相应的行业认知时没办法相信外人指出的瓶颈，即便勉强相信也找不到解决方案。 > **假设你穿越到 400 年前** > > 人类在地球上生活了几百万年，现代医学直到 400 年前才开始发展。在现代医学诞生之前，人类的很多疾病无法确诊和得到有效医治，因为那时候我们不具备解剖学、细胞学、遗传学等医学及相关学科知识，自然也没有青霉素、X 光机、呼吸机等药物和设备。如果 400 年前有外星人或穿越者告诉当时的医生，你们的国王感染了一种致命的细菌，再不用抗生素就没救了，医生能治好国王的病吗？ 当产品团队的认知跟不上产品的发展时，过早优化必然会出现。微信曾经在 4.5 版本做过相当小众的实时对讲机功能，打磨得超级精致。和 5.0 版本的微信支付相比，这个功能显然是过早优化。前面我们讲过，产品衰退的标志并不是市场份额下降，而是失去获客、留存、变现的创新能力，其本质是产品团队行业认知的停滞导致无法发现或突破瓶颈。

微信的实时对讲机

过早优化并不只出现在产品层面。开发团队如果对性能做超前优化或者优化性能已经够用的模块，是过早优化；运营团队如果在时机还不成熟的时候发起大型活动，是过早优化；营销团队如果在投资回报率还没有跑正的情况下就盲目烧钱，也是过早优化。 **功能渗透留存矩阵** 对于过早优化也不用过度焦虑。皮克斯创始人艾德文·卡特姆（Edwin Catmull）说，我们可以努力系统性地避免自满和发现隐蔽的问题。坨厂在思考“系统性”的时候，找到的一个方法是功能渗透留存矩阵，如下图所示。

功能渗透留存矩阵

*功能留存率 = 当前周期使用该功能的用户数 / 上个周期使用该功能的用户数* *功能渗透率 = 当前周期使用该功能的用户数 / 当前周期整个产品的活跃用户数* 我们在功能渗透留存矩阵中把产品的核心体验（比如获客齿轮和留存齿轮的咬合点，留存齿轮和变现齿轮的咬合点）标记为红色，那么红色的点处于什么位置就很关键了。产品一无疑是能留存用户的产品，核心体验的渗透率和留存率都非常高；产品二则是一个租用流量的产品，核心体验不太能留得住用户。 如果最靠近右上角的功能并不是产品的核心体验，比如图文信息流产品新增了视频内容，比如团购产品新增了外卖服务，那就说明我们的产品可能面临转型，需要拥抱渗透率和留存率更高的使用场景。 将产品的核心体验持续向右上角推进，是产品团队最重要的工作，整个团队的注意力和资源都应该聚焦在这件事上。推进这项工作很难，我们可能提出了很多假设，验证了很多假设，但它们的位置都没有发生变化。时间一长，整个团队会承受巨大的挫败感和无力感，甚至不敢再去直接面对它们。古希腊哲学家伊壁鸠鲁告诉我们，不是所有快乐都值得选择，也不是所有痛苦都应该避免。不去面对最需要解决的问题，转头去摆弄支线功能，可能会得到一些非核心数据的增长，但并不能改变整个产品的走势。当我们反复思考困难的问题，尝试解决它，总会慢慢找到办法，比如通过竞争情报获得业界标杆的数据，量化提升空间，提振团队信心，又比如请教或招募行业大牛。 腾讯联合创始人张志东曾经说过：“当我们经受住极大的压力，在重重危机和困难之中，经过不懈的努力，终于找到可行的解决之道的时候，那种豁然开朗的感觉，难以言传，是未经历极限挑战的人所不能理解的，只有用心投入的人，才能体会这种工作的快乐。” 回到功能渗透留存矩阵，靠近左上角的功能渗透很强劲，但用户没有留存，那到底是用户不了解这个功能的价值，还是这个功能不是面向用户的高频需求呢？我们可以花些时间验证这两个假设。靠近右下角的功能留存率很不错，但渗透率不足，属于有潜力的支线功能，可以花点儿时间抢救一下。渗透率不足可能是功能藏得太深，没有有效获客，也可能获客的曝光已经很充分了，但转化率太低。如果是藏得太深的话，通常可以认为改善获客就能向上推动；如果是转化率太低的话，可以认为有些用户经常使用，但大部分用户从不使用，那么该功能的入口对大部分用户是无效的。进一步，是入口做得太晦涩，让人看不懂，不敢点击，还是这个功能本身太小众？有了这些假设后，就可以走流程了——精简，排序，逐一验证。 靠近左下角的功能就有点让人“不忍直视”了，它们代表的都是伪工作。但凡在获客和留存两个杠杆中认真考虑过一个，也不至于把它们做出来。不管是移除还是抢救，伪工作都会再次占用开发资源。这时候你就会理解，少即是多。从稳健性角度来讲，产品越简单，就越容易实现稳健性，比如算盘就很难崩溃，而复杂得多的手机更容易死机。 我建议项目经理和开发工程师要求产品经理在产品需求文档中预估每个需求的渗透率、留存率和变现规模（如果涉及变现的话），在功能渗透留存矩阵里标记每个需求的位置。产品发布后，拿实际的渗透率、留存率、变现规模和预估做比较，如果相差较大，要分析清楚其中的原因。产品经理不能总给大家留下一种“拿着伪需求要求开发工程师估时，估错了还得加班赶进度” 的印象，要估就大家一起估，特别是要从工作的源头开始估。开发工程师对于需求的估时应该越估越准，产品经理对于需求增长效果的评估也应该越来越准。预估越准确，团队就可以更有效地剔除伪工作，并预防增长效果不明确的临时需求插进排期，一直做投入产出比最高的事情。 最后还想强调一点，虽然我们可以把注意力聚焦在一些关键功能上，但切勿陷入“功能视角”。产品是一个有机的整体，一个功能咬合另一个功能，一个系统咬合另一个系统，留存咬合获客，变现咬合留存，“系统视角”是做好产品的必要条件。比如我们想提升信息流列表的内容质量，如何找到优质的内容创作者，如何判断内容的质量，每个内容消费者对内容质量的判断标准是否相同，在有限的展示数量中如何平衡内容消费和内容质量，恶意评论会不会打击内容创造者的创作热情等，都是需要考虑的问题；一个更易用的编辑器并不能一次性解决这些问题。 #### **用户体验三要素** 产品设计是整个项目中的第一项工作，虽然我们还没有开始撰写产品需求文档，但是，我们已经完成了产品设计的绝大部分工作——确定产品概念、对假设列表进行精简和排序、设计最小可行系列产品。在撰写产品需求文档之前，我们还需要从用户体验的角度为产品设计增加一点点细节。 用户体验最关键的 3 点是：核心体验、核心体验、核心体验。不是开玩笑，优质的核心体验是产品能够成功占领市场的必要条件，非核心体验则远没有这么重要。比如飞机，作为一种交通工具，它时不时颠簸并且噪声巨大，但速度是它的核心体验，一快遮百丑。我们没有无限的资源把产品方方面面的体验都做到完美，或者我们能做到完美但成本会飙升到用户无法负担而产品概念也不再是最初设想的概念（比如产品概念从大型客机变成了私人飞机），所以用户体验设计也要借用最小可行产品的思路，覆盖好核心体验就可以了，不要做零分甚至负分的“打磨”。 > 如果把创建产品比喻成造房子，交互设计和视觉设计类似装修，信息架构类似建筑图纸，产品概念、产品形态和产品定位则决定了产品的核心体验类似房子的地段，黄金地段的普通房子价值远超偏僻地段的艺术品房子。 一个产品的核心体验是什么呢？可能是获客齿轮和留存齿轮的咬合点，比如飞机的速度和时效，趣头条的“师徒系统”；也可能是留存齿轮和变现齿轮的咬合点，比如机舱一般分为经济舱、商务舱和头等舱，内容产品要有海量内容和高效的分发同时还要嵌入广告，社交产品要能让人找到聊得来的朋友顺便卖会员服务，外卖产品要有丰富的菜品和快速的配送还要控制成本实现盈利。 做好核心体验，可以从别让我等、别让我想、别让我烦这 3 个要素着手，站在前人验证成功的设计上，降低用户体验设计的不确定性。 **别让我等** 每个人的生命都是有限的，耐心也是有限的，减少等待时间是全人类的刚需。手机的 4G 信号如果够强，网速对于目前大多数应用是够用的。但人群密集的话，4G 信号就变弱了，访问网络内容就会变慢。不知道 5G 普及后，能否进一步解决这个问题。 假设用户正试图打开你的产品，那么你的产品最好能在 10 秒之内呈现内容，否则用户通常会放弃或者中断一个大任务的执行。许多研究表明，让用户满意的产品打开时间通常在 2 秒以内。当用户点击了一个按钮，你的产品有 1 秒的时间来展现他所期望的内容。1 秒是两个人之间对话舒适间隔的最大值，为了让“对话”舒适地继续下去，在这个时间点上你一定要告诉用户接下来点击什么，不然用户会觉得冷场而离开。如果用户输入了一串字符或者移动了某个组件，这时候留给你的产品跟用户进行手眼互动反馈的时间是 0.1 秒。实际上，人类对连续动画的感知大概是 0.065 秒，超出这个时间就会觉得操作卡顿。一些抽样调查显示，用户倾向于认为打开速度较快的产品质量更高、更可信，也更有趣。所以，绝对速度一定要及格，在及格的基础上，像视网膜屏幕那样越逼近人类感知极限越好。 2018 年 2 月，谷歌用神经网络估算出不同加载时长对网站跳出率的影响，如下图所示。

不同加载时长对网站跳出率的影响

如果觉得用户中途离开还不够“刺激”，我们可以再聊聊时间就是金钱。自助开店平台 Mobify 在 2016 年分享过一组数据，它的首页加载时间每减少 100 毫秒，基于会话的转化率就会增加 1.11%，年收入增长近 38 万美元；结账页面加载时间每减少 100 毫秒，基于会话的转化率就会增加 1.55%，年收入增长近 53 万美元。 > **越优化数据越差？** > > 2009 年，YouTube 程序员克里斯·扎卡赖亚斯（Chris Zacharias）接到一个需求：把 1.2 MB 的视频播放页面精简到 100 KB 以下（1 MB=1024 KB），他给这个项目取名为“羽毛”（Feather）。在废了九牛二虎之力后，这个看似不可能的任务完成了，视频播放页面变成了 98 KB。但是经过一周的数据采集，一个“摧毁克里斯世界观”的结果出现了，视频加载时间变长了！正当克里斯准备放弃羽毛项目的时候，他的同事找到了答案：地理分布。 > > 按照地理细分来看，东南亚、南非、南美等地区的流量有了不成比例的增长，这些地区基于羽毛项目的加载时间在 2 分钟以上，正是这些新增用户拉高了全球平均视频加载时间。为什么呢？从页面大小来推测加载时间的话，原先这些地区的用户打开网页 20 分钟后视频才开始加载，用户根本等不了这么久，还没等视频开始加载就关闭了页面，是羽毛项目第一次让这些用户看到了 YouTube 视频。 > > *摘自克里斯的博客文章“Page Weight Matters”。* 糗事百科可以为速度问题提供一个反面案例：签到。签到是个支线功能，开发团队盘算：那就怎么简单怎么来吧，做成一个全屏网页好了。网速正常的时候还好，网络一旦出现卡顿，整个应用界面就只剩下全白，没有返回按钮，也没有其他任何东西。运气好的话它最终能加载完成，用户可以继续操作；运气不好的话会一直处于卡死状态，用户只能手动杀死应用进程再重新打开。运用同理心可知，不是每个用户都会杀进程。本来是个支线功能，现在却存在严重缺陷，影响到了核心体验，开发团队还要花额外的时间修复它。 {% hint style="info" %} 性能指标不一定需要产品经理来盯，坨厂由运维团队监控这些数据，发现问题后提交给产品团队，产品团队根据问题整理产品需求，需求实现后再由运维团队确认数据的变化。产品团队中有人负责关注性能指标就好，没人接手这个工作的话，产品经理就得接手。 {% endhint %} 除了努力提升绝对速度，我们还可以运用一些加载策略来改善用户对于速度的体验。比如顾客到餐厅吃饭，一入座服务员就会过来摆好碗筷，这个策略叫骨架（skeleton）。这就好比虽然还没有加载出来任何内容，但色块和线条可以给用户以内容预期。点单之后服务员送来一个沙漏，告诉用户上菜超时的话会有折扣，这个策略叫进度条，让用户对加载时间有所预期。做好一道菜就上一道菜，而不是等全部做好之后一起上，这个策略叫分步加载，比如先加载展示文字内容，随后加载展示图片和视频。YouTube 作为视频产品是反过来的，先加载视频再加载其他信息。顾客点了一个双拼比萨，服务员先送过来半个，说另外一半很快就好，这个策略叫懒加载，长视频内容通常会用到。一个视频文件很大，全部加载完再开始播放需要等太久，看个开头就不看了也很浪费流量，把它切成小段或变成流，就解决了这些问题。用户点了一个老火汤，制作时间需要几个小时，从下单到上菜却只用了一分钟，因为厨房早就预备好了，这个策略叫预加载。 {% hint style="warning" %} 思考题：你在短视频产品里切换视频的时候能感觉到加载过程吗？加载是何时开始的？ {% endhint %} 在绝对速度和加载策略之外，别让我等的另一个问题是反馈速度。今天移动应用的主流交互方式是手指触摸屏幕。相比十年前的键盘和鼠标，点击是否马上就有反馈，滚动是否跟手，这类反馈速度的问题得到了进一步的重视。 我们看一个现实世界中的例子。 > ——小王，这个版本上线后的数据分析发我一份。 > > ——好的，一分钟。（一分钟后）请查收。 > > ——小李，这个版本上线后的数据分析发我一份。 > > ——（一分钟后）请查收。 如果小王和小李这两个实习生只能转正一个，你想把名额给谁？ 再来看个大家很熟悉的例子。假设你这次不去餐厅吃饭，在家叫外卖。下单后餐厅人工确认外卖订单需要时间，骑手取餐、送餐也需要时间，但你在下单后会立即得到支付成功的反馈，然后自动跳转到外卖进度页面，这里可以看到订单的进展，在此过程中反馈一直是即时的。占位和进度条可以提供反馈，但它们出现的速度一定要快，才能让反馈变得及时，反馈一定要有最高的响应优先级。有些游戏会在场景变得复杂的时候自动调低画质来保证帧率，也是出于优先级的考虑，画面糊几秒和卡顿几秒，前者相对更好接受一些。另外，清晰明确地展示反馈效果可以避免用户错过反馈陷入等待的焦虑。十多年前糗事百科模仿 OS X 图标点击效果做了按钮反馈动画，点击后能明显看到点击被执行了。现在这种反馈形式已经成了点赞按钮的标配。

2006 年糗事百科的投票“+1”动画截图

**别让我想** 1971 年，诺兰·布什内尔（Nolan K. Bushnell）开发了第一款商业视频游戏《电脑空间》（*Computer Space*）。它是大型机上的《太空争霸战》（*Spacewar!*）的改进版，可是因为太新奇，超越了时代的步伐，反倒吓跑了顾客，最终游戏机柜只销售了 1500 台。

《电脑空间》游戏机柜

给布什内尔带来灵感的是一句话：“谁低估美国人的智力，谁就会发财。”1972 年布什内尔注册了全球第一家电子游戏公司雅达利（Atari），这次他决心设计一个无须动脑筋的简易游戏机，就连小孩子和酒吧醉汉也能一玩就懂。他雇用安派克斯（Ampex）公司的老同事艾伦·奥尔康（Allan Alcorn）开发的第一款游戏叫《乓》（*Pong*），是一个简单的电子乒乓球游戏。

《乓》街机游戏机柜（Rob Boudon, CC BY 2.0, via Wikimedia Commons）

鉴于《电脑空间》的打击，布什内尔决心谨慎行事，先从最小可行产品开始。他用电路板、硬币箱和一台旧电视组装出了一台《乓》的原型机。1972 年 9 月，布什内尔和奥尔康将这台原型机安放到了本地的一家酒吧，看是否有人来玩。一天不到，酒吧老板就打电话向他抱怨游戏机坏了。经过简单的检查，布什内尔发现游戏机并没有坏，而是一加仑（约 3.79 升）大小的钱盒已吃满了硬币，造成了“堵塞”，一个全新的电子游戏机时代就此拉开了序幕。 别让我想的关键是简单，足够简单才不会调用脑的前额叶皮层，人类不喜欢动用这个区域进行高能耗的思考。所以产品要从内而外的简单，概念、形态、定位、信息架构、技术、交互、视觉都要简单，才容易被用户理解和使用。从《乓》和《电脑空间》的游戏画面就能看出来，《乓》的概念显然简单了很多。如果不改变产品概念，只是给《电脑空间》重新设计简单的交互和视觉效果，它还是一个复杂的游戏。 同样是解决沟通的需求，即时通信为什么代替电子邮件成了主流？是因为即时通信的速度更快吗？虽然即时通信的名字里有即时两个字，但电子邮件的速度并不慢，要知道，微信的收发消息模型跟电子邮件模型的底层实现技术是一样的。一个关键要素是即时通信的产品形态比电子邮件简单，电子邮件中的消息以邮件标题为索引，即时通信中的消息以联系人为索引，显然，以人为索引更符合人与人日常沟通的习惯。另外，即时通信产品的干系人更简单，每个即时通信产品都是一个相对封闭的网络，想做语音功能就能做语音，想做支付功能就能做支付；而电子邮件是开放的网络，新的协议不一定会被多种多样的邮件客户端支持，这就增加了创新落地的成本。 脑白金和小米都是定位简单清晰的产品，脑白金是节日礼物，小米性价比高（这个定位正在努力传给红米）。历史更悠久的成功案例是戴比尔斯，打造了 20 世纪最经典的广告语之一“钻石恒久远，一颗永流传”（A Diamond is Forever）。钻石只是宝石的一种，它能流行是通过挖掘钻石“硬度高”这个特性撬动了爱情和婚姻的获客杠杆，还巧妙地压制了二手交易。 我们再来看看百度、360 搜索和搜狗。百度的口号是“百度一下，你就知道”，8 个汉字，非常简单，一看就和搜索相关。360 搜索的口号是“360 搜索，SO 靠谱”，360 搜索显然高估了懂英语的用户比例，SO 靠谱还是个谐音梗，要想一下才能想到“搜靠谱”。搜狗呢，“搜狗搜索引擎，上网从搜狗开始”，“搜索”这两个字很多用户懂，但“搜索引擎”这 4 个字是个产品术语，用户要理解可能需要思考，后半句“上网从搜狗开始”，没有突出搜索的定位，倒是有点儿 hao123 的感觉。前后加起来 13 个汉字，有耐心看完也不容易记忆。需要说明的是，产品口号不等于产品定位，只是产品定位的一个表象。

三大搜索引擎的口号

这里再稍微展开一点，不光文字要用简单常用的文字，图形化信息也要和主流图形保持一致。比如大家都用放大镜表示搜索，你非要用望远镜，用户就需要想一想才能明白。甚至有些图形现在已经变得有点奇怪了，比如保存图标是一个软盘，现在的年轻人哪里见过实体软盘，还好，如今的产品大多支持自动保存，不太需要这个图标了。 {% hint style="warning" %} 思考题：明碁为什么改名为明基？ {% endhint %} 微信和 QQ 在建群方面曾经是有区别的，微信往对话里增加人就变成了群，老年人都会用（据说每个人的微信里都有一个“一家人”群）；QQ 往对话里增加人会变成多人聊天，多人聊天和群的功能不同，QQ 群只能从建群入口创建。现在 QQ 群已经改成和微信群一样的逻辑了，取消了多人聊天。同样的概念，同样的产品形态，只做群，还是做群再做多人聊天，这是一个信息架构问题，结果是简单的信息架构胜出了。 需要强调的是，技术的简单不是技术方案本身简单，而是技术让用户用起来简单：比如电容触摸屏和多点触控，就比电阻屏加手写笔要简单；整合了指纹识别的按键TouchID 就比 Home 键加密码简单；云同步就比 U 盘和电子邮件简单。 微信群的信息架构虽然比 QQ 简单，交互却比 QQ 复杂。因为没有数字群号码，微信群提供了群二维码，这就多出来一连串 QQ 没有的交互，用户无法直接记忆这个二维码后告诉其他人，但对方可以扫码进群，比输入数字群号码要简单。微信还有一个面向陌生人聚会场景的面对面建群交互。大家彼此不是好友，拉人建群要先加好友，更简单、更自然的交互方式是先进群再想加谁加谁。所以，交互的简单和技术的简单类似，要追求使用的简单。快手的双击点赞，B 站的一键三连，对用户来说都是简单有趣的交互设计，还成了品牌模因（meme）的一部分。

微信的面对面建群

{% hint style="warning" %} 思考题：微信为什么不把公众号放到发现页里？ {% endhint %} 产品经理毕竟不是视觉设计师，产品经理对视觉设计的参与主要体现在和视觉设计师商量想“抄”哪个产品以及审稿，对视觉设计的简单性有一定的判断力即可，记住便于扫描和可操作暗示（affordance）这两条就差不多了。便于扫描是指确保用户能够在每个页面中快速定位重点内容或可操作对象，不会在多个视觉元素中迷失视线焦点。设计师经常运用隔离效应来实现该目标。如果存在多个元素，有特点的元素容易被识别、记忆：比如页面中只有一个色块的时候，这个色块就最抓眼球；如果有两个色块，视觉的重点就分散了。如果有多个类似的元素，面积相同就没有重点，面积有大有小就容易突出重点。

突出视觉重点

可操作暗示是指可操作的对象要给用户可操作的感觉，比如下图所示的计算器，软件界面有和实体计算器类似的按钮，即便去掉按钮的立体感只剩下色块，我们还是可以感知它们是按钮，是可操作的。

实体计算器→拟物化设计的计算器→扁平化设计的计算器

iOS 7 之前的拟物化设计的可操作暗示很强，但拟物化设计也有滥用的问题，不可操作的元素或纯装饰性元素在视觉上也很突出，这是不必要的，还会妨碍扫描。另外，不同产品的拟物方向不同，有的模拟金属按钮，有的模拟木质按钮，给用户增加了非必要的学习成本。拟物化设计有非常突出的优点，也有无法忍受的缺点，又到了需要取舍的时候。 苹果公司于 2013 年推出 iOS 7，用扁平化设计终结了拟物化设计的滥用。注意，是终结了拟物化设计的滥用，并不是终结了拟物化设计。扁平化设计里的卡片、毛玻璃、视差、按钮、锁头图标，还是在模拟三维空间和现实生活中的物品，因为这些是用户生活中最熟悉的，只是这一次的模拟更抽象、更简洁了。现在大家既能享受拟物化带来的可操作暗示，又能享受扫描的便利，在不同的产品间切换也不会觉得突兀而需要重新学习，这就是设计的力量。

苹果地图

{% hint style="warning" %} 思考题：上图中的大横条（Home Indicator）和小横条（Handlebar）为什么能给用户可操作暗示？ {% endhint %} {% hint style="info" %} 一个小建议，不要花太多时间死抠视觉细节，因为视觉设计的进度而拖慢整个项目的进度更是不可取。我在高考前刷题的时候被一道物理题难住了，请教一个同学，他一看题目太难，跟我说：“物理只有 150 分。”（当时每科满分 150 分。）视觉在整个产品中占多大比例呢？你是否会花同等或更多时间死抠产品概念、形态、定位、信息架构？是在更本质、更底层的地方花时间收益大，还是在最表面的地方花时间收益大？产品经理审视觉稿，浏览下来没有大问题即可，我倒是鼓励设计师多花点时间和产品经理死抠产品定位和信息架构。 {% endhint %} **别让我烦** 别让我等和别让我想对获客和前期留存有显著影响，别让我烦则影响产品的长期留存。有两类问题会导致用户心烦，一类是低效，另一类是骚扰。 如果技术方案或交互方案对于用户来说不够简单、高效，用户的耐心会逐渐被消磨。比如输入密码解锁手机的案例，苹果首席执行官库克曾经透露，他每天拿起手机大约 200 次，如果每次都要输入 6 个数字进行解锁，是不是很烦？解决低效最好的办法就是自动化，把输入密码的环节直接干掉，拿起手机就自动解锁。 如果无法实现自动化或者考虑到自动化会失败，我们还可以简化流程。比如微信支付，去掉了确认按钮，从常见的输入 7 次（输入 6 位数字密码 +1 次确认 = 输入 7 次）变成了输入 6 次，输入环节的复杂度降低了 14%。

微信支付界面

用户在商业机构的网站稍作停留，网页通常会自动弹出客服气泡，询问用户有什么需要，这也是一种效率的提升。有些疑问直接和客服沟通，解决得更快。Instagram 有个类似的设计，用户在信息流中停留几秒，当前照片的评论框会自动出现，方便输入评论。

VIPKID 主页

还有一种低效是用户自己操作出错，需要重复进行操作。丰田公司对这个问题有一套解决方案，叫防呆（poka-yoke）。防呆有两个主要的出发点：一是尽量减少对员工的培训，实现快速上岗；二是尽量预先管理错误，进而提高良品率。这和互联网产品需要解决的问题类似，互联网产品没办法对用户培训太久，最多也就是走个新手引导流程，同时还希望用户的操作不出错，保持效率。 防呆的具体手段包括下面几种。 * **自动化**：已经讲过两次了，自动化后用户当然就不会出错了，再出错就是产品出错。 * 校验：利用形状、密码等进行校验，减少误操作。三相电源插头只能按照正确的方向插入，就是利用了形状校验。当用户对一些敏感数据进行操作的时候，特别是钱，输入密码确认就是一种校验。 * **隔离**：划分区域，禁止用户进入危险区域。iTunes 并不会告诉用户音乐文件和 CD 封面具体存放在硬盘的什么位置，故意将用户和这些文件隔离，用户只能通过 iTunes 对音乐进行“安全的”管理。该设计也强迫用户放弃对音乐文件、CD 封面图片文件等内容的关注，让用户的注意力聚焦于音乐本身，降低了用户的学习成本。 * **缓冲**：利用各种方法减免错误带来的伤害。自动保存用户正在编辑的内容，最好再提供历史版本回溯功能。用户想要取的名字被别人占用了，自动给用户提供一些备选项，减轻错误对用户的打击。高考的备用卷也是一种缓冲，在 2020 年安徽歙县的高考中就发挥了作用。 骚扰是指对用户进行干扰、折磨等冒犯行为，产品对用户的骚扰包括产品本身对用户的骚扰和产品干系人对用户的骚扰。 支付宝每天稳定地给我发 4 条推送，这可能是一种流失用户召回策略，但推送的信息并不是我需要的，却占据了我的屏幕空间，这就是一种骚扰。iOS 针对推送骚扰推出了关闭通知和消息折叠。无奈道高一尺魔高一丈，我想加入即刻的一个圈子，不开启通知权限就无法加入，如下图所示。

不开启通知权限就不能加入圈子

其实推送骚扰、广告骚扰、促销骚扰还不算最严重的骚扰，内容产品不能给用户提供感兴趣的内容，搜索引擎的搜索结果里没有用户想要的信息，电商平台的推荐列表里出现了冒犯用户的商品信息，外卖给用户送的餐洒了，这些核心体验问题是更值得重视的骚扰。 微信在减少产品对用户的骚扰方面做得非常好，发现页和钱包页的入口都可以关闭，这在防呆手段里叫“断根”，允许用户从根本上杜绝骚扰，获得内心的平静。

关闭各种入口后的微信

产品干系人对用户的骚扰主要有两类：用户对用户的骚扰和骑手、司机等服务人员对用户的骚扰。后者相对来说容易处理一些，首先服务人员的数量有限；其次，平台有相应的管理手段。用户觉得某个骑手服务态度不好，可以拉黑他，这个骑手就看不到用户后续的订单了，用户也不用因为一个骑手就放弃已经习惯的产品。 用户对用户的骚扰是个大课题。产品的活跃用户规模越大，会去骚扰其他用户的用户往往就越多，而且他们一般不在乎自己的账号，被平台制裁了就想办法再注册一个账号。理想的网络环境是大家心平气和地讨论问题，现实的网络环境像很多人坐在自己的车里路怒症发作，每说一句话都是大声嚷嚷和拼命按喇叭。为什么狼人杀搬到网上就没有线下那么好玩了，因为当一个玩家不认真参与的时候不用担心其他玩家会过来“抽他”。 同样是滴滴出行的产品，顺风车的恶性事件就比快车、专车严重，原因在于顺风车司机的属性更接近普通用户。滴滴最初不但没有预防潜在违法行为，还把顺风车这个出行产品描绘成社交场景，给骚扰提供了杠杆。 > “就像咖啡馆、酒吧一样，私家车也能成为一个半公开、半私密的社交空间。这是一个非常有未来、非常 sexy（性感）的场景，我们从一开始就想得非常清楚，一定要往这个方向打。” > > 黄洁莉，前滴滴出行顺风车事业部总经理 2018 年 5 月 5 日，一名空姐在郑州乘坐滴滴顺风车时遇害。同年 8 月 24 日，浙江温州乐清的一个女孩在乘坐滴滴顺风车时遇害。3 日后，滴滴宣布在全国范围内下线顺风车业务。 滴滴顺风车用户的不幸遭遇揭示了一种更基本的需求——别让我死（人身安全）。用户不止关心自己的安全，也关心他人的安全，因为他人不安全也就代表自己不安全。别让我死这个问题不是特别常见，但也不算特别罕见，特斯拉的“自动驾驶”就是另一个例子。 2016 年 1 月 20 日，23 岁的高某驾驶一辆特斯拉在京港澳高速邯郸段行驶时，追尾道路清扫车身亡。2016 年 7 月，受害者父亲对特斯拉提起诉讼，索赔 1 万元，称特斯拉夸大宣传自动驾驶功能，致使受害者在驾驶时放松警惕酿成这起车祸。2016 年的 8 月，特斯拉将中文官网的“自动驾驶”一词改为“自动辅助驾驶”。2018 年 2 月 27日，在大量证据面前，特斯拉承认事故车辆当时处于自动驾驶状态。 特斯拉的策略非常精明，简单来说就是既想占宣传上的便宜，又想避免承担法律上的责任。在功能名称描述上打擦边球，在功能介绍里强调这是辅助驾驶，在广告里绝对不吹嘘；而在非广告宣传里，特斯拉首席执行官马斯克在 Twitter 中转发过不少双手脱离方向盘的危险驾驶视频，2019 年还在这么做。有人认为马斯克在无形中暗示辅助驾驶功能可以让人双手脱离方向盘。相比滴滴出行的窘境，特斯拉的市值高歌猛进，在 2020 年 8 月已经突破 4000 亿美元。

马斯克转发双手脱离方向盘的危险驾驶视频截图

特斯拉官网可是说手要放在方向盘上随时准备接管车辆，如下图所示。

特斯拉官网截图（https://www.tesla.com/support/autopilot）

举这两个例子是希望大家在做产品的时候能对用户保持敬畏之心。“用户”不只是数据库里的一串串信息，每个用户都是鲜活的生命，产品如果没有做好就会扰乱他们及其家人的生活。 只要一个用户发布的信息能被另一个用户看到，就有被骚扰的可能。骚扰不限于产品内部，还包括其他产品和现实生活中。“奥利给”大叔黄春生在快手走红之后，他的黑粉们成立了一个“反怪联盟”（黄春生的网名叫朝阳冬泳怪鸽），专门找他麻烦，在直播间骂脏话挑衅，不间断地打骚扰电话，给他 PS 遗照，甚至他的家人也一并遭殃。祁迎春是“反怪联盟”的积极参与者，他原本是和黄春生同时“出道”的短视频博主，几年前一起在大凌河拍短视频，两人的粉丝数都是 1 万多。但不久后，祁迎春的快手生涯因为入狱而突然中断，直到 2020 年 5 月他才出狱。为了围追堵截黄春生，祁迎春花了 20 万在黄春生家附近买了一套房。“我气啊，我要不进监狱，他老怪能火起来？”祁迎春说。 同理心能让我们换位思考，但如果我们对人性的复杂认知不足，不知道会有歹徒、黑粉使用我们的产品，同理心就会出现缺口，产品就会出现漏洞。私家车是不是一个社交空间？是。私家车是不是像酒吧一样半公开、半私密？不是。当私家车在空旷的道路上行驶，就会变成完全私密的空间，而且只有司机和乘客，万一其中任何一个人动了邪念，后果不堪设想。如果用户里绝对没有一个歹徒，黄洁莉的设想很好。“一开始就想得非常清楚”？没有考虑墨菲定律啊。 {% hint style="info" %} 墨菲定律：如果某件事有可能发生，就一定会发生。 {% endhint %} “这个世界有人的地方就有恩怨”，我们肯定没办法完全屏蔽掉歹徒和诈骗团伙，也没办法完全避免用户和用户之间的摩擦，但我们可以努力降低这些事件发生的概率，特别是恶性事件发生的概率。这样做不只是为用户着想，也是在防范自己产品的公关危机。只给用户提供拉黑功能是不够的，拉黑并不能预防骚扰和诈骗，只能事后亡羊补牢。我们可以更进一步把预防骚扰和诈骗看成一个产品，为它设计一系列的功能和策略，比如在用户发言的输入框里加入友好发言的引导，自动过滤不友好的发言，对广撒网却很少收到回复的用户进行“杀猪盘”检测，等等。防骚扰防诈骗产品的概念和形态可以“抄”其他产品，也可以根据自家产品和用户的特点自主创新。 {% hint style="warning" %} 思考题：给儿童买人身保险，为什么不满十岁的儿童身故后赔付额 20 万元封顶？ {% endhint %} **产品需求文档** 产品需求文档是由产品经理和设计师（包括交互设计师、视觉设计师等）共同产出的文档。我理想中的合作模式是，产品经理负责获客、留存、变现这些杠杆的设计，设计师负责用户体验的设计，当两者发生冲突时，产品经理和设计师商量着寻找双赢方案或妥协方案。实际工作中可能是，产品经理承担了大部分用户体验设计的工作，设计师主要负责完成视觉设计的工作，具体的合作模式以大家所处的实际情况为准。 关于产品需求文档的形式，目前有两个流派，一派是单页流，另一派是全景流。

单页流需求文档

全景流需求文档

单页流的好处是可以做交互动画，更贴近真实产品的体验；全景流的好处是可以对用户的动线和产品的复杂度一览无遗。有些单页流的人不承认存在全景流，觉得这一张大图不能模拟操作体验，还缺少动画效果，无法充分说明产品需求。有些全景流的人不承认存在单页流，觉得它顶多算是全景流的补充演示手段，全景图才是本体，想要看清页面间的逻辑关系只能通过全景流，在单页里点来点去操作半天都不一定能遍历所有页面。 选择哪个流派，产品经理个人的偏好是次要的。产品需求文档的用户是视觉设计师和开发团队（视觉设计和开发通常是并行的，视觉设计产出的图片、动画等素材不阻塞开发进度就好），他们习惯用哪种就选哪种。如果他们觉得都行，就可以按产品经理的偏好来。产品需求文档是产品经理和产品团队进行书面沟通的渠道，也是产品和用户进行书面沟通的渠道。产品团队能否看懂说明书，用户能否看懂产品中的文案，对产品经理的书面表达能力是一种考验。 书面沟通也是沟通，我们前面讲过的“保持坦诚，将提议的成功率保持在高位”依然适用。和口头沟通相比，书面沟通有自己的特点，比如我们无法直接捕捉到对方的反应。如果对方感到疑惑，我们不能及时进行更详细的讲解。这就要求书面沟通尽可能站在对方的角度进行表达，确保对方能够理解我们的意思，提前消除疑问和歧义。有效的书面沟通不一定需要华丽的辞藻，比如“参加红军可以分到土地”这句经典的表达，直指人心。另外，在产品文案中应尽量避免错别字和标点符号的使用问题，这些低级错误会让用户质疑产品的品质。 **明确项目目标** 产品团队经常会面对一个困惑，我们的 KPI 是数字，但产品需求文档里都是功能和策略，它们之间好像有点跳跃。这个问题可以用目的拆解表（Objective, Goals, Strategies, Measures，OGSM）来解决。据说，OGSM 的概念于 20 世纪 50 年代起源于丰田，后被宝洁、NASA、可口可乐、大众汽车等众多组织所采用。

冷启动目的拆解表

日常沟通中经常会出现一种“X—Y 问题”，本来我们要解决的问题是 X，比如完成冷启动，我们设想的解决方案是 Y，比如给老用户赠送头像挂件，沟通中我们谈论的都是 Y 问题，甚至还花时间把 Y 实现了，但 Y 可能并不是 X 问题的解决方案，而参与讨论的其他人压根不知道我们所面对的是 X 问题。目的拆解表就很好地解决了“X—Y 问题”，它从一开始就明确表达了我们的问题是 X，目标和目的是否相符，策略和目标是否相符，策略达到评估标准后能否完成目标，进而实现目的，整个拆解过程一目了然。 X 问题和 Y 问题同时呈现在一张表格里，就形成了一个高效的沟通平台，可以增强产品团队每个成员的主观能动性。团队中的每个人，不管是运营经理还是开发工程师，都能通过这张表格清楚地了解自己当前的工作内容和工作意义，有不同意见或更好的想法都可以及时提出来进行讨论。产品经理不一定总能想到达成目标最有效的策略，运营经理和开发工程师有时会有更好的创意。另外，开发工程师的逻辑思维能力通常都很强，他们如果看到表格里不符合逻辑的地方，及时提出疑问，也能有效减少伪工作。 好记性不如烂笔头，为什么做这个功能，为什么要实施那个策略，人是会忘的，但文档不会变，产品需求文档和作为文档附件的图片、动画等素材最好能做好归档工作，健全的文档也有利于新人入职后快速熟悉产品。还需要注意的一点就是，产品需求文档在提交给开发工程师之后可能会有修改，建议大家详细记录需求变更的理由，原因还是一样，好记性不如烂笔头。 ### 5.3 实验 实验是探究假设是否成立的阶段，也是整个项目周期中燃烧经费最多的阶段。团队中几乎所有人都要参与实验，如果需要做获客实验，可能还要再烧掉很多广告费。产品经理不太可能也没有必要完全搞懂实验过程中的所有细节，但需要了解每个环节应该完成哪些工作，在这些环节中自己具体参与什么。互联网产品有很多形态，不一定是应用、网站，也可能是一个微信群、一个视频账号、一个直播间，希望大家能够透过案例看到每个环节存在的价值，举一反三映射到自己的产品中。 #### **开发** 哈利·波特的世界里有会魔法的人和不会魔法的人，前者被称为“巫师”，后者被称为“麻瓜”。现实世界里有会编程的人和不会编程的人，如果把编程看成魔法，前者就是巫师，后者就是麻瓜。不会编程的麻瓜产品经理如何同会编程的巫师开发工程师进行沟通，是个世纪难题。 **麻瓜生存指南** 这个难题的终极解决方案也许是产品经理应该学会编程？很多老板级产品经理会编程，比如拉里·佩奇、谢尔盖·布林、比尔·盖茨、马化腾、张小龙、雷军、李彦宏、张一鸣，等等（排名不分先后）。其实不学编程也没关系，苹果的联合创始人斯蒂芬·沃兹尼亚克就说乔布斯从来不编程，这说明麻瓜一样可以成长为伟大的产品经理。 > **开发工程师的发难** > > 曾经有开发工程师向乔布斯公开提问技术问题，想要羞辱这个麻瓜产品经理，乔布斯回答道：“当我们思考苹果公司的战略和愿景时，总是从不可思议的用户价值出发，而不是看工程师手里有什么尖端技术可以拿出来卖钱，我认为这才是正确的方向。” > > 所以麻瓜产品经理们不用自卑，我们的价值是从用户价值出发思考问题，这个视角与设计师从用户体验出发和开发工程师从技术实现出发是不同的，具有独特的价值。 为了搞清楚麻瓜产品经理如何更好地和开发团队合作，我采访了很多开发工程师，请他们谈谈记忆中高效、愉快的合作案例和低效、不愉快的合作案例。在这些案例背后，我发现了一条分界线：专业。如果产品经理在沟通中能体现专业性，比如摆事实，讲逻辑，有目标，合作就会高效、愉快。如果产品经理在沟通中不专业，比如事实错误（拿着浏览量下降的数据问收入为什么下降了，而收入其实并没有下降），逻辑混乱，没有目标，越界指定技术方案（同理，越界指定设计方案、运营方案也都不专业），合作就会变得低效、不太愉快。 重新看一遍乔布斯对开发工程师的回复，是不是很有逻辑，是不是很“专业”？其实这个专业和我们之前讲的非授权领导力差不多是一回事。如果麻瓜产品经理能在合作中积累越来越多的项目成功案例，和开发团队的合作就会更顺畅。如果麻瓜产品经理能对技术（不是编程）有一些了解，比如知道应用主要负责展示数据，服务器主要负责存储和处理数据，应用和服务器通过网络交换数据，当然也会进一步提升沟通效率。 **能力和意愿** 我们当然期望开发团队能够披荆斩棘攻克产品的技术难点假设，并且锦上添花为产品提供新的增长点，比如低延迟低成本的视频通话、把用户“困”在信息流里的推荐系统、能通过图灵测试的人工智能等。但我们需要面对的现实是，不管是开发负责人的人选，还是开发团队的整体实力，产品经理这个岗位所能施加的影响是非常有限的。 产品的成败通常是多因一果，其中开发起到的作用难以一概而论，那么，有没有纯开发因素导致的失败呢？我想并不罕见。在坨厂众多失败的产品中，就有两个是由于开发原因失败的。也就是说，不考虑市场等外因，纯开发问题就导致它们无法继续，一个是三消游戏，一个是狼人杀。 三消游戏失败是因为掉落规则的算法问题。开发工程师使用了一种预先计算掉落补位路径的方式，一开始工作得挺好，可随着游戏关卡的增加，玩法越来越复杂，这种方式就逐渐无法实现新的设计要求了。更简单、更灵活的方式是给每个珠子设置基本的掉落规则，正下方有空位就往正下方落，正下方没空位但左下方有空位就往左下方落，正下方和左下方都没有空位但右下方有空位就往右下方落。等到团队发现算法硬伤的问题，经过评估，重构成本相当于重新开发整个游戏，而市场上又有了别的机会，只好放弃该产品。 狼人杀的问题是团队没把它当作游戏来开发。它虽然看上去像语音聊天室或直播软件，但其实是客户端逻辑非常复杂的游戏，为了防作弊，这些逻辑服务端也要有一份。如果采用游戏的开发方式，就应该用 Unity 等游戏引擎，每个玩法只需要写一份代码，多个平台都可以运行。用普通应用的开发方式，就需要 iOS、Android、服务端各写一份代码，每一端暴露出的缺陷还不一样，开发和测试的周期都很长，随着游戏角色和玩法的增加，更新成本逐渐变得不可接受。 这两个产品失败的原因是团队对产品的理解不够深入，对产品发展过程中的技术路线考虑不足，这些问题都是行业认知的问题。行业认知是很难在产品立项阶段快速提升的。如果立项时团队的行业认知与项目不匹配，在回答 “能不能做”的时候，明明不能做却自认为能做，大概率会失败。当然，产品和团队不匹配的风险并不局限于技术岗，产品、运营、营销等岗位都有可能出现。 除了能力问题，另一个现实问题是意愿。产品经理精心准备的需求被开发团队用 “做不了”三个字挡回来，这种情况也是存在的。麻瓜虽然不会编程，但麻瓜可以有几个会编程的朋友。请朋友帮忙判断一下能不能做，大概要怎么做，心里有底之后再和开发团队摆事实、讲逻辑重新沟通，依然有机会解决问题。如果这样还是不能解决，那可能就不是沟通技巧的问题，而是投诉技巧的问题了。 #### **测试** 简单来说，测试团队负责验证开发结果是否与产品需求文档一致。我们前面案例的产品需求是让猴子背诵《哈姆雷特》，开发团队教给猴子的剧本却是《哈利·波特》。你别笑，我们的表达有时候是不够清晰的，就算做到了清晰也很难完全消除歧义，所以这种问题经常会出现。测试团队会检查开发团队的阶段性结果，发现这种偏差后及时通知开发团队修正，确保猴子登台演出之前能够全文背诵《哈姆雷特》。 当然，测试团队所面对的实际情况肯定没这么简单，产品经理和设计师在做产品设计的时候并不会考虑到很多极限的产品使用场景，比如用户在创建账号的时候输入了带有特殊字符的用户名，比如对老版本的兼容性问题，开发团队在开发的时候可能也没考虑到这些情况，而测试团队会基于自己对用户多样性的理解提前预判这些情况，确保开发结果在绝大多数使用场景中与产品需求文档一致，不会轻易出现错误，甚至崩溃。 产品经理在测试阶段主要参与三项工作：产品需求文档答疑、参加测试用例评审和版本验收测试。 由于沟通中可能存在问题描述模糊，或者容易产生歧义，测试团队会经常找产品经理确认产品需求文档中的需求到底是什么（产品团队的其他成员也经常会这么做），所以答疑是一项非常必要且重要的工作，且贯穿整个版本周期和整个产品生命周期。产品经理千万不要假设大家心有灵犀，在介绍项目管理的时候我们说过人与人之间的沟通是一件效率很低的事情，一定要有耐心解答的觉悟。如果想要减少答疑的工作量，就要在撰写产品需求文档的时候多投入，尽量做到详细和精确。 测试用例是测试团队的重要工具，可以把它理解为基于产品需求文档撰写出来的另一种形式的“产品需求文档”，但更精确、更周全。测试团队会保障开发团队的开发结果与测试用例一致，产品经理要在测试用例评审中保障测试用例和产品需求文档一致，这样才更容易达成开发结果和产品需求文档一致的目标。 **驿站传书** 驿站传书是一个模拟沟通链条的经典团建游戏。游戏参与者站成一排，全程不能讲话。游戏开始的时候，队伍末尾的参与者会收到一个信息，他需要拍拍前一个参与者的肩膀，让这个参与者转过身来面对自己，然后用肢体语言把自己收到的信息传递给他。这个过程不断重复，直到队伍开头的参与者接收到信息，这时候他需要把这个信息写到白板上让所有人看到，游戏结束。游戏参与者对比白板上的信息和自己接收到的信息会发现，原始信息在每次传递的过程中都发生了一些变化，这些变化累积到一起最终导致了巨大的差异。 即便有了详细明确的产品需求文档，产品经理也进行了充分的答疑，仔细评审了测试用例，测试团队也验证了产品版本成功通过所有测试用例，但由于这个链条中的每个环节都可能会出现一定的偏差，因此，产品版本是不是与产品经理心中的产品需求一致，最终还是要靠自己验收确认。 产品经理在验收中可能会发现两类问题，一是产品版本与产品需求不一致，比如说好的《哈姆雷特》变成了《哈利·波特》，二是产品版本与产品需求一致，但产品的逻辑或体验有不对劲儿的地方。这两类问题最好区分来看：前者是测试阶段的问题，应该标记为缺陷进行修复；后者是用户研究的问题（后面会展开讲），要解决这类问题，就要提出新的产品需求，或者对现有产品需求做变更。如果对这两类问题不加以区分，一股脑儿都当成需要被修复的缺陷，测试阶段就需要延长，当前的项目周期会被破坏，后续的版本排期也会被打乱。 #### **运营** 本书的开头举过饮水机的例子，它可以自动化地提供服务，但它的自动化是有局限的，比如一桶水空了之后饮水机没办法自动换水。绝大多数互联网产品做不到完全的自动化，它能自己上架到各个应用市场吗，它能自己提供令人满意的客户服务吗？这些产品需要完成却无法自动化完成的工作，都是广义上的运营。在产品的整个生命周期中，有三类问题需要运营解决：等不及、做不到和划不来。 **等不及** 在移动互联网刚刚出现的时候，智能手机除了拍照、浏览网页、玩玩单机小游戏，其实还干不了太多事情。有一天我碰巧下载了一个扫描名片的应用，对着名片拍照，过一会儿它就能把名片上的信息识别出来，存入手机通讯录。让我惊讶的是，它的识别准确率非常高，要知道有些名片会用艺术字体，有些名片会用竖向排版，它都能完美识别。我去请教懂技术的朋友，现在的光学字符识别（OCR）技术这么先进了吗？他说，这个准确率不像是 OCR，从等待时长来看搞不好是人工客服在帮你识别。我有点吃惊，这么高大上的人工智能居然是人工扮演的智能？又找其他朋友打听这家公司，发现还真是人工客服在识别。 如果要开发出同等准确率的应用，项目周期可能要很久，产品概念的验证周期就变得很长，验证成本也很高。但如果是用运营来提供这项服务，大概只要几天就可以发布产品，收集用户的反馈。运营是设计最小可行产品时经常会用到的手段，大多数情况下，人了解一项新工作比机器了解一项新工作要快多了。 **做不到** 随着人工智能的发展，机器自动化的能力进一步增强，于是又一批工作岗位开始消失了。（为什么要说又呢？）以前停车场是有人管理的，入场的时候登记车牌或者发张卡，出场的时候根据登记表或读卡收费。现在停车场变成了自动识别车牌，自动计费，出场的时候扫码支付。以前使用产品遇到问题可以直接和客服沟通，现在通常会先遇到机器人客服。 {% hint style="warning" %} 思考题：交警这个职业会在什么时候消失？ {% endhint %} 在可见的未来，有两类工作是自动化无法取代的，创意类工作以及与人沟通的工作。寻找低成本获客的渠道、联系新媒体做宣传、策划拉新活动、策划留存活动、策划变现活动，等等，都是需要依赖运营团队完成的创意类工作，自动化没办法产生这些创意。因为人是创意丰富的动物，甭管产品设计得多完善，测试用例多全面，用户总能找到奇怪的角度来使用产品，比如爱尚鲜花在电商平台刷单，当产品无法有效应对用户千奇百怪的用法时，就需要运营团队出面和用户聊聊了。人还是感情丰富的动物，修辞再礼貌的自动反馈也是机械的、冰冷的，并不能让用户足够满意，而且很多用户非常在乎产品官方的认可，这也是一种很常见的情感诉求。投诉处理、客户服务、大客户维护、参加线下用户活动，等等，都是与人沟通的工作。 拿我比较熟悉的直播产品来说，产品运营团队涉及以下工作。

热猫直播的运营活动

* 获客：接触经纪公司引进大量主播，去其他产品挖角一些主播和鲸鱼用户，有些产品团队中广告投放也是运营的工作。 * 留存：和经纪公司、主播、鲸鱼用户保持良好的沟通，策划留存活动。 * 变现：策划变现活动，召回流失的鲸鱼用户，邀请鲸鱼用户参加活动。 其中，创意类的工作有： * 广告投放，发现投资回报率高的投放渠道，制作投资回报率高的广告创意； * 策划线上活动，提供游戏化的体验，保持产品的新鲜感，提升变现效率。 沟通类的工作有： * 通过经纪公司引进主播； * 挖角主播和鲸鱼用户； * 和经纪公司、主播、鲸鱼用户保持良好的沟通，解决他们使用产品中遇到的问题，处理他们之间的纠纷； * 流失用户召回； * 活动邀请。 **划不来** 当用户规模越来越大，最初“等不及”但并非“做不到”的工作会逐步实现自动化，如果符合这两个条件的工作迟迟没有自动化，一定是经济账不划算。比如一个堵住用户奇怪用法的需求开发成本高昂，但这种情况其实很少出现，运营团队处理起来几乎没有成本，那么把这项工作自动化就“划不来”。 全自动完成某项工作划不来，但又想提升运营效率、降低运营成本，怎么办？答案是开发运营工具。比如一个操作效率很高的审核平台，也许能将审核效率提升 200%，一个机器人客服系统，也许能减少 60% 的客服工作量。之前我们说过产品需求文档中的产品需求来自各方，其中就包括运营团队，这些需求需要产品经理判断要不要做，如果做的话排期到哪个产品版本做。 由于等不及、做不到、划不来这三类问题长期存在，运营团队并不会随着产品用户规模扩大而减员，通常会持续增员。随着运营团队规模的扩大，它会逐渐分化成推广、审核、客服等多个团队（每个最小团队最好不超过 9 个人），分化之后所剩下的工作内容就变成了狭义上的“运营”。 ### 5.4 评估 项目按时完成了，除了开香槟庆祝，产品团队还应该做些什么呢？其实版本发布意味着“假设—实验—评估”这个循环已经走完了假设和实验，来到了评估阶段。为了更好地迎接评估阶段，在撰写产品需求文档的时候我们已经事先明确了项目目标，现在要做的就是评估实验结果是否达到了项目目标。如果达到，说明相应的假设成立；如果没达到，说明相应的假设存在问题需要进一步的分析。 评估是一个项目的最后阶段，但不是这些假设的终点，我们可以在评估中发现新的实验方案或者新的假设（比如验证成立的假设能不能推广到更多的场景），在后续项目循环中开展新的实验。 #### **评估的精度和速度** 随着产品的反复迭代，产品的复杂度通常会呈现出不可逆的熵增，复杂度越高，产品可优化的方向就越多。一个开发版本通常会包含多个假设，但它们并不一定都具有优化效果，可通过 A/B 测试来验证。产品的经营数据每天都被大量的外部变量和内部变量锁影响着，比如竞争对手的机房断电了导致用户涌入我们的产品，比如我们的用户创造了一个出圈的内容引来了大量新用户。当我们只想分析某个改动所产生的效果时，我们可以把用户分成 A 和 B 两组（开启平行宇宙），其中一组的产品体验保持不变，另一组的产品体验加入需要评估的改动，如果我们能观察到 A 组和 B 组的经营数据产生了差异，就看到了这个改动的效果，这种评估方法就是 A/B 测试。

Algolia 的 A/B 测试服务

我们新发布的1.3 版本包含了假设 X、Y、Z，和之前的版本相比，发布后的留存率提升了 4%，说明我们实现了优化。如果做更细致的 A/B 测试，我们也许会发现，X 将留存率提升了 5%，Y 将留存率提升了 3%，Z 导致留存率降低了 4%，基于这个数据，留下 X 和 Y，去掉 Z，1.3 版本的留存率相比旧版本提升了 8%。和不做 A/B 测试相比，提升翻倍，这就是提升评估精度的效果。 助理级产品经理在堆砌功能的时候也许是在渴望“银弹”：下一个功能一定能引爆流行，实现爆发式增长。一次性提升数据 20% 的“银弹”可能可遇而不可求，但一个数据如果涉及 5 个环节，每个环节提升 5%，105% 的 5 次方是 128%，比 20% 的预期还超出 8%。做产品的时候当然不能放弃尝试投入产出比超高的“银弹”，但是在没有“银弹”的时候，也不能守株待兔。踏踏实实做好增长漏斗上每个环节的优化，就可以实现可观的增长。 假设越多，A/B 测试平台就越繁忙，甚至可能成为限制产品迭代速度的瓶颈。 为了提升测试速度，Netflix 发明了交织测试（interleaving），把不同策略所推荐的内容交织在一起展示给用户，从中快速识别出优秀的策略。这种方法只需要 1000 个样本就可以判断出假设是否带来了增长，置信区间 95%，而传统的 A/B 测试方法要达到同等的置信区间则需要 100 000 个样本。通过交织测试快速筛选出表现出色的假设后，Netflix 再对它们进行样本量更大的传统 A/B 测试。 A/B 测试很有效，但容易走向两个极端。有些人对自己的假设信心满满，觉得不需要 A/B 测试，绝对能提升产品的竞争力，但不做测试怎么能知道具体提升了多少呢？万一这个假设对产品是负优化呢？如果开发工程师说不用测试，直接发布，绝对不会崩溃，产品经理要接受吗？还有些人沉迷于 A/B 测试，拿着锤子看什么都像钉子，不深究自己的假设靠不靠谱，通通交给 A/B 测试，产生了大量的伪工作。 AppSumo 创始人诺亚·卡根（Noah Kagan）分享其 A/B 测试经验时说，他们觉得首页的宣传语会影响转化率，先后尝试了 8 版文案，却没有任何一版产生明显的数据变化。从中他们得出了什么结论呢？其实，他们并不知道为什么没有任何变化，可能用户并不阅读文字？ 上面这个案例揭示了 A/B 测试的两种产出，一是假设发布后所带来的数据变化，二是假设和数据变化之间为什么会有因果关系。前者可以帮助产品团队决策某个假设的去留，后者则可以形成对规律的认知，提升后续假设的靠谱程度。 同时，我们也要看到 A/B 测试的局限性，它有时会误导团队形成错误的认知。当我们在一个方向，比如内容的排序分发，想了很多假设，做了很多测试后，它的效果有了一定提升。这时我们发现了另一个完全不同的方向，比如内容的推荐分发，我们做了推荐分发的最小可行产品，将它和排序分发进行 A/B 测试，很可能得出推荐远不如排序的结论。而实际情况却是排序分发的效果已经接近天花板，推荐分发的天花板远高于排序分发。如下图所示，方向一代表排序分发，方向二代表推荐分发，团队在方向一已经迭代增长了一段时间，这个时候切换到刚开始探索的方向二，很可能面临效率暂时降低的问题。

充分优化的方向一和待优化的方向二

增长和发展是两码事，瞄准一个方向不断努力总会有增长，发展则是切换到天花板比当前方向更高的方向。在比较不同方向的时候，如果我们只看 A/B 测试的结果，就会陷入“创新者的窘境”，有潜力的新方向在萌芽期就被成熟的老方向打败了。1975 年柯达发明了数码相机，但觉得它能产生的利润远不如胶片多，会导致公司整体利润下降，于是雪藏了这项技术，时过境迁，2013 年柯达宣布破产重组。 怎么判断方向一和方向二的天花板呢？每个方向的天花板并不是抬头就可以看见（如果能看见也就没什么机会了），我们不断建设楼梯往上走，有一天发现撞到头走不动了，这时候我们所处的高度就是天花板的高度。坨厂的增长总监李威说：“这就是商业的魅力所在，方法和数据并不能给出所有答案，选择哪个方向取决于我们内心相信什么。” **数据分析** 我大概是在初中的时候开始接触速冻饺子这种食品，寒暑假的时候中午一个人在家，偶尔会煮一袋饺子吃。当时我妈妈教给我的方法是，饺子煮到飘起来就放半碗冷水，如此重复三次后就可以吃了，可在实际执行的过程中，有时候煮过头破皮了，有时候夹生了，煮到完美状态的情况并不多。后来这个问题得以解决靠的是饺子外包装的变化，速冻饺子的产品经理终于把使用说明印在了包装袋上：沸水下锅后加盖，中火煮 5 分钟，然后揭盖中火再煮 1.5 分钟。这两个简单的数据，极大提升了我煮饺子的成功率，基本上不会再失败了。 进入大学后，学校里有个传说，某位老教授年轻的时候“上山下乡”被分配到窑厂烧窑，窑厂给教授分配的老师傅说，这可是个技术活儿，没有几年的积累根本掌握不好火候，慢慢学吧。结果，教授用了一周的时间，就达到了和老师傅一样的技术水平。秘密是什么呢？教授随身带了一支温度计。 如果没有数据，我们想要的 A/B 测试是无法实现的，功能渗透留存矩阵也无从谈起。数据对于产品经理有两大价值，一是了解产品的整体经营状况，及时发现问题，解决问题；二是通过数据来分析评估中所发现的问题，找到调整方案，进行新一轮的尝试。 产品经营中会面对很多变量，不是产品团队做了实验产品数据才会变化，外部世界每时每刻都可能发生一些事情导致产品数据变化，所以产品经理通常会建一些数据看板，比如“获客—激活—留存—变现—传播漏斗”（AARRR 增长漏斗），比如使用时长、同时在线用户数、发帖量、成交量等关键指标。这些数据看板可以让产品经理了解产品的整体状况，也能在产品出现异常的时候及时发出警报。横向来看，我们可以将这些数据和竞争对手的数据做比较，判断自己的效率是否落后了；纵向来看，我们可以将这些数据和过去的数据做比较，看看是否在保持增长。如果拿看病来类比，这些数据就像是温度计，可以给产品测一测“体温”，看看“发烧”了没有，但不能进行更深入的诊断，对症下药就更无从谈起了。 前面讲提升行业认知才能发现瓶颈，才能将产品带到新的高度，还讲了功能渗透留存矩阵可以帮助我们聚焦。功能渗透留存矩阵就好比血液检测，和温度计相比，通过血液检测能进一步了解产品。如果要再进一步呢，我们还需要超声波、核磁共振、核酸检测等。 现代医学起源于解剖学，人类发现心脏和血管后，建立了血液循环理论，为医学大厦打好了基础。同样，做产品也需要为产品构建分析工具，分析产品得到结论后才能建立行业认知。增长漏斗是大家都了解的基础知识，它并不能解决如何提升获客效率、如何提升留存率等问题。解决这些问题需要我们对获客渠道和用户需求有自己的认知，而数据是建立认知的基础之一。 以视频网站的付费页为例，下图左侧是爱奇艺 VIP 会员购买页，右侧是腾讯视频 VIP 会员购买页，国内视频领域两大巨头的付费选项差异这么大，是不是有点意外？

爱奇艺的 VIP 会员购买页与腾讯视频的 VIP 会员购买页截图

这两个付费页的不同点有价格、文字（新用户专享、新客首月 6 元等）、设计（颜色、选项个数等）和其他（支付方式、登录前置还是后置等）。额外强调一个截图状态下无法体现的明显区别，爱奇艺的付费页可以在未登录的状态下打开，但付费二维码是不可用状态，点击二维码上的“请点击刷新” 会跳出登录界面，而腾讯视频的付费页则需要用户登录后才能打开。 考虑到不同类型的用户（万一有大数据杀熟呢）所看到的文字和价格可能是不同的，变量就更多了。面对这么多可调整的变量，拍脑袋可以确保付费率和每用户平均收入（ARPU）提升吗？ 在追求效率这条道路上，科学方法比拍脑袋更有效。通过测量获得数据比拍脑袋有效，通过 A/B 测试验证一项实验是正优化还是负优化也比拍脑袋有效。场景越复杂，就越会发现想拍脑袋都下不去手，图 5-30 形象地展示了我们的困境。 为自己的产品量身定制分析工具，和为自己的产品量身定制最小可行产品类似。分析工具本身就是行业认知的一部分，确定要分析的问题，找到量化标准来分析问题，这些只能靠自己摸索。在行业认知之外，我提供三个笼统的数据分析思路，一是从解决问题出发，二是从整体到群体再到个体逐级深入，三是数据平台需要不断发展。

困境

**从解决问题出发** 获取数据和查看数据都是为了使用数据得出新的假设进行新的实验，如果只停留在看数据，产品并不会发生变化，产品的市场份额也不会自动增加。所以，从解决问题出发来获取数据、查看数据、使用数据，才是有意义的。如果没有需要解决的问题，发现产品隐藏的瓶颈就是需要解决的问题。这时候可以尝试从用户任务着手，看看用户到底在使用产品完成哪些任务，在完成任务的过程中有没有被卡住的低效率环节。 如果所分析的问题没有价值，分析技术再强大，分析得再深入，也只是在足球场上表演了一套高难度的艺术体操，“瓶颈问题们”面面相觑、“一脸黑人问号”，对改变产品所面临的困境毫无帮助。比如产品数据出现下滑，分析下滑原因太难，于是开始做新功能的 A/B 测试，试图用新的增长来抵消下滑，这就是在逃避问题。解决下滑的问题所带来的数据恢复，加上新功能带来的增长不是更好吗？在激烈的竞争中，产品所积累的“暗病”可能就是效率落后的原因。 有价值的问题通常都是困难的问题，比如获客和变现互相踢皮球，获客说变现效率太低，变现说获客拉来的用户都是铁公鸡，到底是谁的问题，或者说各自的问题分别是什么？ 有一段时间我很喜欢看修电脑的视频，一台电脑不能开机了，可能的原因有很多，也可能是多因一果（越宏观的指标越有可能出现多因一果，比如活跃用户规模、用户生命周期价值等）。如何快速定位问题，是维修能不能赚钱的关键，定位问题之后，维修成本和配件成本都是可控的。但是，如果维修师傅经验不足，定位问题花了太长时间，工时费过高，就可能超出了客户的心理承受能力。 通过数据分析定位产品的问题很像修电脑。如果获取数据做得比较好，问题发生前后的数据是完备的，那么总有办法确定问题所发生的时间点和原因，不确定的因素只是定位问题所需要的时间。一个问题分析了一段时间后没有结果，这时又要写新的产品需求文档，分析工作可能就会半途而废。如果我们掌握了一些高效的分析方法，比如细分，就能有效避免这类情况。我们可以把新增用户细分为口碑获客用户和广告获客用户，其中口碑获客用户的付费情况可以用来分析变现的问题，广告获客用户的付费情况相对口碑获客用户的比值可以用来分析广告获客问题，这些数据都摆出来之后自然就没球可踢了，谁的问题谁认领。 提升自己定位问题的能力，让定位问题所需时间变短、可控，是解决不敢面对问题的关键。另外，我们可能会面临情感压过理性的局面，比如我们很容易觉得做加法有天然的正确性，每个加法都有自己的理由，而做减法则有天然的割肉感，这些非理性的情感会阻碍我们面对有价值的问题。我们可以用展望理论中的“参照依赖”克服这个问题，损失和获利是相对于参照点而言的，改变评价事物时的参照点，就会改变对风险的态度。加减法的参照点是产品的复杂度，更有意义的参照点是增长（包括获客、留存、变现、资本），加法可能会带来负增长，减法可能会带来增长，关注增长而非产品复杂度会让我们的决策更加理性。 **从整体到群体再到个体** 如果不对用户进行细分，我们看到的留存就只是整体留存，就没办法分析和解决前面提到的获客跟变现踢皮球的问题。稍微细分一下用户群，就能看到新增用户的获客成本、留存率和付费率，这对评估获客效率非常关键。 不同的用户需要不同的产品功能和体验，比如内容生产者需要编辑工具和数据平台，内容消费者则不需要，南方的用户会购买电暖气，北方的用户有集中供暖。从用户生命周期来看，新用户和老用户也需要不同的产品功能和体验，新用户可不只是需要一个注册功能，新手引导和新手礼包都是常见操作，给游戏新玩家在前期匹配人工智能对手创造“我有天赋”的错觉也正在变成标配。有了用户分群和用户生命周期分段这两个维度，整体的用户就被细分成了下图里的好多个群体，我们可以针对每个群体进行分析，比如查看每个用户群体的功能渗透留存矩阵，找出不同群体的核心体验。还可以举一反三，看看每个用户群体的内容渗透留存矩阵、内容留存付费矩阵等等。

用户分群

再按地域细分，能看到不同地区新增用户的获客成本、留存率和付费率。继续细分下去，我们还可以给每个用户建立画像，有了个体用户的画像和行为，推荐系统才能搭建起来。但是，也不要一上来就只看个体。我们需要先通过整体和群体全面了解产品，找到产品的增长瓶颈后，再做更细致的工作。 **数据平台需要不断发展** 运动员和电竞选手会通过观看比赛回放来分析自己的问题，产品经理也可以通过回放用户的行为来分析他们所遇到的问题。产品经理对数据的需求不能被工具所限制，这种情况一旦发生，产品经理的行业认知就被局限了，因此，要想办法更新和打造自己的工具。分析工具、运营工具、项目管理工具等内部工具都是非常重要的产品，和面向用户的产品一样应该有产品需求文档和产品版本。 以坨厂为例，产品开发阶段只有业务数据库，上线的时候使用了第三方用户行为分析平台。随着产品发展，用户行为分析平台开始暴露出能力不足的问题，比如它不能打通对用户和物品的分析，而业务数据库是面向互联网服务设计的，调取分析数据不仅占用开发资源，还容易影响线上业务的运行。于是坨厂开始建设客户数据平台（Customer Data Platform，CDP），如下图所示，把用户行为分析平台的数据和业务数据库的数据整合到数据仓库中，提高分析效率，调取数据的工作可以由数据平台的运营经理或产品经理自己操作，不再需要占用开发工程师的时间。

坨厂的数据平台架构

大厂的发展路线可能不同，它们一开始就有客户数据平台，业务数据库的内部数据和外部机构提供的数据直接汇总到客户数据平台，分析工具和运营工具都基于客户数据平台进行开发，在分析中会使用外部数据，但不需要使用外部的分析工具。 我参考 GrowingIO 咨询与服务副总裁刑昊的分享，制作了一个数据能力自测表，将团队对数据的应用能力划分为 5 级（类比自动驾驶技术级别的 L1\~L5）。

数据能力自测表

* L1，无数据，工作拍脑袋——想到什么做什么，做成什么样不知道。 * L2，无数据，工作系统化——知道该做什么不该做什么，但做成什么样还是不知道，开始做收集数据这项工作。 * L3，看数据，工作系统化——可以利用数据发现问题与分析问题。 * L4，用数据，工作系统化——可以对用户、内容、广告进行分群分析，具备了 A/B 测试的能力。 * L5，用数据，工作自动化——对用户、内容、广告的分析进一步细化到个体，并且跟踪每个个体的全生命周期数据，建立起自动化的推荐系统、广告投放系统等。 大家可以通过它了解一下自己团队目前所处的位置。 数据平台很这类工具很重要，但不要迷信工具，人永远是最重要的。比如我们新开了一家医院，先进设备一应俱全，人手方面全是实习生，看上去能操作设备，却没办法做出高准确率的诊断，这家医院的水平肯定无缘三甲。 工具强不能等同于人强，人强才能用好工具，才能量身定制工具。 > **看数据的团队输给了不看数据的团队？** > > 我有两个朋友都做直播带货，就称他们为 A 团队和 B 团队吧。A 团队不怎么看数据，连财务账目都是一团糟，库存也算不清。B 团队对数据很敏感，还会运用 A/B 测试提升粉丝转化率。结果却是，A 团队很赚钱，B 团队勉强求生。 > > 坨厂内部聊到这个事情，有人提出：“过于追求数据是不是容易忽视用户需求？”增长总监李威说：“其实他们都看数据，A 关注行业数据、排行榜这些外部数据，这些数据决定增长漏斗顶部的效率，B 关注内部数据，这些数据处于增长漏斗的中下部分。A 团队比 B 团队发展好，是抓住了看数据的重点。” #### **用户研究** 有些问题数据可以给我们答案，但有些问题数据没办法给出答案。 我入职腾讯的职位是 QQ 邮箱产品经理，当时 QQ 邮箱的留存数据并不好，而且毫无口碑可言。产品团队由我和刚刚被收购的 Foxmail 团队构成，对于这个相对成熟的产品来说全是新人。快速找到当时最紧要的产品问题，就成了我面临的第一个考验。我想到的办法是流失用户问卷调查。先和技术同事一起列出了一份近期流失的 QQ 邮箱用户名单，设计好回访问卷，然后找到客服中心的主管，请她帮忙分配一些人力回访这些用户。整理出第一批问卷结果后，对问卷内容进行调整又做了第二版问卷。问卷调查给出的结果非常清晰，用户流失的主要原因有两个，一是垃圾邮件太多，二是病毒邮件太多（这两个原因导致的流失远超其他原因）。我把防垃圾和防病毒这两个需求提交给 QQ 邮箱开发团队，得到的估时反馈是要开发两三个月，无所事事的我就帮忙去写 QQ 浏览器的产品需求文档了。 让我印象深刻的另一个案例是第一次使用腾讯的体验观察室。当时我们在做 Q 吧产品，在一些流程的设计上团队内部有分歧。用户研究中心派驻到我们产品组的交互设计师说，其实这个分歧不难解决，邀请一些目标用户来体验观察室试用我们的产品，就可以知道设计方案有没有问题了。

配备了单面镜的观察室

用户由研究员陪同在体验观察室里完成研究员交给他的一些任务，研究员不能提示用户如何操作产品，产品团队在观察室的隔壁，透过单面镜和显示器可以看到用户的操作情况。测试开始前，大家还在争论，坚持自己的观点，结果，第一个用户被流程卡住，第二个用户被流程卡住，所有人都不讲话了，语言层面的推理在用户无法完成任务的事实面前是苍白的。大家默默回到自己的座位之后，不但很快解决了问题，整个团队也更同心协力了，因为我们都充分认识到自己的同理心还远远不足。 用户研究和数据分析有交集，但不是一个包含另一个的关系，比如 A/B 测试和功能渗透留存矩阵都是利用数据进行用户研究的方法，调查问卷和体验观察室就是不依赖于数据分析的用户研究，数据平台可以给产品团队提供展现产品整体经营状况的现金流报表，这个报表并不是用户研究。 用户研究是贯穿产品整个生命周期的一项重要工作。按照问题的开放性由大到小（问题越开放研究难度越高），用户研究解决这三类问题： 1. 发现产品概念 2. 发现产品瓶颈 3. 验证假设 这三类问题和产品经理所面对的找方向、找瓶颈、做实验其实是一样的，但这只是字面知识，不是看过后立马就能实践的经验。当我们看数据的时候，筛选出来的数据集不同，解读方向不同，就会得出完全不同的结论。当我们与用户交流的时候，提出的问题不同，提问方式不同，也会得出大相径庭的结论。提升用户研究的能力需要在实践中精进一项或多项用户研究方法（比如调查问卷或 A/B 测试），还需要对用户有深入的了解。 **不盲从用户的建议** 除了在腾讯做产品，我还在腾讯的战略发展部工作过一段时间，其中有一项工作内容非常有趣。客服中心会把一些执意要见 Pony 的进言型用户转给战略发展部处理，可能是怕错过一些不世出的天才吧。我接待过三四个这样的用户，结果证明，没有一个用户能提出有价值的建议。包括后来我自己创业，也有进言型用户非要坐飞机过来面谈，好说歹说变成网上沟通，结果证明并不靠谱。 李诞讲过一个吐槽飞机乘客的段子：飞行员播报，因天气原因暂时无法降落，需要盘旋一小时。一位大哥按铃叫来空乘人员，指着窗户说，“我看这明明就可以降落，你这都不敢降落，当什么飞行员？你看人家《敦刻尔克》那飞行员，没油都能落！”我都不知道这人咋想的，神经病，质疑人家飞行员。人家飞行员有雷达，有塔台，有各种设备，你一个乘客你有啥，小桌板、遮光板、枕头、毛毯，你还可以调节座椅靠背…… 这个段子的笑点在于洞察了生活中的信息不对称，乘客大哥想用肉眼观测到的信息挑战飞行员通过专业设备和专业团队获取的信息。在进行用户研究时，产品经理要观察用户在使用产品过程中遇到的问题，分析原因，寻找解决方案，而不要盲从用户的建议（这一点《率土之滨》团队就做得特别好）。 **渐离式观察和体验** 关于用户研究，还有一点需要特别注意：产品经理和产品团队通常都不是自己产品的主流用户。思晨创意写作的创始人陈思说阅读可以分成两种，一种是入迷式阅读，一种是渐离式阅读，如果想通过阅读来提升写作技巧，就要使用渐离式阅读。我理解入迷式阅读就是读者把自己代入角色的视角，渐离式阅读就是读者把自己代入作者的视角。前者能体验故事，后者能看清作者是怎么编织故事的。产品经理要注意避免自己陷入入迷式的体验状态，因为今天的互联网是非常下沉的，绝大多数人能用手机上网，主流用户并非像产品经理一样高学历高收入，产品经理自己对于产品的需求不能代表产品主流用户的需求。产品经理需要对产品保持渐离式的观察和体验，从产品所有干系人的角度来一一考虑产品所面临的问题，并在这些问题中做出取舍。 对于一些面向专业用户的产品，渐离式的观察和体验可能存在效率和深入度两方面的问题。苹果公司有一系列面向各类专业用户的软件和硬件：Final Cut Pro、Mac Pro、MacBook Pro、iPad Pro，等等（或者它们要与更专业的设备搭配使用），但早期苹果内部并没有深度使用这些产品的各类专业用户。与外部专业用户沟通存在各种各样的问题，比如他们的时间非常宝贵很难保持密集的沟通，比如他们手头正在进行的项目有保密要求不方便透露太多信息，总之沟通效率很低。苹果自己有拍宣传片、广告片、制作发布会 Keynote 等需求，以前是外包出去，到了 2018 年苹果招募了一批顶尖的专业用户，组建了“专业工作流团队”（Pro Workflow Team）。专业工作流团队有三方面的价值，一是解决公司在 3D 动画、视频剪辑等方面的专业需求，二是软硬件团队可以贴身观察他们的工作流发现产品的问题，三是公司可以根据专业工作流团队的需求规划 Pro 产品线未来的方向。 苹果硬件工程高级副总裁约翰·特努斯（John Ternus）, 同时也是专业工作流团队的老大，举过一个通过观察专业工作流团队成员使用产品从而解决用户“痛点”的例子。3D 动画师在微调动画细节的时候经常需要打开一个窗口，这个窗口所涉及的运算量并不是太大，但它需要 6 到 10 秒才能打开，而它每天要被打开接近 100 次——这太要命了。发现问题之后，软硬件团队很快定位到这是显卡驱动的问题，通过修复问题大幅提升了 3D 动画师的工作效率。 这个显卡驱动问题通过测试是很难发现的——电脑硬件本身没有任何问题，软件的各项功能都正常，窗口的打开时间看起来也“可接受”，3D 动画师却在抱怨：“这台电脑实在太慢了！”如果不进行深入的用户研究，如果没有专业工作流团队的帮助，产品团队别说解决问题了，连定位问题可能都做不到。 ### 5.5 是否跳出项目循环 在聊确认产品概念的时候我们分析过，做产品遭遇失败是大概率事件，获得成功是小概率事件，这个结论同样适用于大公司做新产品。大公司能提供前期的资金、先进的工具、完成冷启动的流量，但不一定能给新产品分配老板级产品经理，产品团队可能还会被路径依赖（过去成功的经历）所束缚，限制了获客、留存、变现的创新。这些因素叠加起来，含着金汤匙出生的产品也需要做好失败的准备。如果我们经过评估和多次实验后发现一些假设不成立，产品无法达到预期的市场份额，就要跳出项目循环，考虑其他产品概念，甚至考虑加入其他产品团队了。 #### **产品生命周期** 做产品是一个“假设—验证—赢得市场份额”的循环，如果几轮循环过后市场份额不再增长，或者亏损无法收窄，产品的发展就遇到了困难。如何处理增长失速的产品？我们可以结合产品的生命周期来看。

产品生命周期

产品的一生可以分为 4 个阶段：幼稚期、成长期、成熟期、衰退期。产品在幼稚期会尝试获取用户，以此验证用户价值；到了成长期用户规模和市场份额快速增长，产品可能开始实现盈利；当产品占据了一定的市场份额，却无法在获客、留存、变现、资本这 4 个杠杆进行大的创新，就进入了成熟期；当市场上出现了能更好地满足用户需求的新产品，产品就进入了衰退期。 如果产品停滞在了幼稚期，第一种可能的情况是获客无门，我们没有找到获客杠杆，第二种可能的情况是最小可行产品的留存很差，我们的产品概念并没有抓住真实的用户需求。如果想不到解决这些问题的新假设，就应该关停产品。 **发展来自探索** 项飙在《跨越边界的社区》中说，不管是一个人还是一个民族，发展主要来自不断地探索，而不是事先一揽子设计。我们的产品能不能赢得市场份额，首先取决于能不能找到会说话的猴子，这种假设成立的概率是很低的，所以很多产品在幼稚期就要面对如何转型这道题。 {% hint style="warning" %} 思考题：如果支撑一个产品概念的所有假设都很容易成立，这意味着什么？ {% endhint %} 2020 年 3 月，知识星球注册用户突破 2000 万，回顾从小密圈到知识星球走过的 4 年，创始人吴鲁加说：“能撑下来，也算奇迹。”4 年间，知识星球的品牌口号改动了 4 次： 1. 小圈子，更亲密； 2. 移动协作利器； 3. 开心工作，安心分享； 4. 连接一千位铁杆粉丝。 这 4 个口号对应 3 个产品定位。口号 1 和口号 2 是面向企业用户的产品定位，解决企业内部分享文档、沉淀讨论、协作办公的需求。口号 3 是面向小团队的，解决同时管理多个微信群太麻烦的问题。口号 4 是面向内容生产者的，解决粉丝管理和变现的问题。从最初“面向企业的协作工具”这个产品概念出发，经过两次转型和一次改名之后，知识星球终于赢得了属于自己的市场份额……这样的描述不足以还原转型的风险和痛苦，我们试试加点特效——小密圈团队造好一辆汽车后高高兴兴地开着它上路了，一脚油门下去，却发现汽车跌落悬崖，团队手忙脚乱地把汽车拆散拼装成了一架飞机才幸免于难，可惜这架飞机不断滑落无力拉升，眼看就要坠入大海了，改名为知识星球的团队再次把它拆散拼装成了一艘快艇，这回终于可以平稳地行驶在海面上让大家喘口气了。 世界不断变化，竞争格局也不断变化。QQ 获得市场份额的时候并没有想到自己能通过 QQ 秀和游戏变现，阿里巴巴获得 B2B 市场份额的时候并没有想到可以做淘宝，诺基亚风光无限的时候并没有想到会出现 iPhone，拼好货快速增长的时候并没有想到自己会并入拼多多，我们在 2019 年并没有想到会遭遇新冠肺炎疫情。我们说产品经理的一大工作是“持续优化整体产品定位”，是因为产品在幼稚期、成长期、成熟期和衰退期都可能遇到无法匹配用户需求的情况。这种不匹配在产品的幼稚期非常普遍，但绝不意味着走过幼稚期后就不再发生。 > **写作来自探索** > > 本书的写作过程也是一个“发展来自探索”的案例。过去几年间，我时不时想写新版本，又觉得自己懂得实在太少了，没什么可写的，无法形成一本书。直到图灵教育创始人谢工和刘江两位老师找到我说，《结网》出版十周年了，其中的案例虽然是读者依然需要学习和研究的，但最近几年互联网飞速发展，是时候复盘一下新案例了。十年前的《结网》能成书，离不开刘江老师对我的指导和鼓励，他这时候的提醒让我开始直面问题，下定决心更新一个与时俱进的版本。在花了一些时间和本书编辑以及身边的朋友们讨论后，发现可写的内容挺多的。 > > 全书的写作过程就是迭代一系列最小可行产品，从目录到细化的章节目录，从每一章都只有一两句话到逐步扩充，它一开始就包含了所有我想讲的内容，只是线条很粗。评估也是从目录阶段就开始了，如果你觉得现在的目录看起来还算清晰有逻辑，那是因为多位朋友给了多轮意见，最初它只是一团乱麻。有了更细化的章节目录之后，我发现自己的知识盲区还不少。写书对我而言也是一个逼着自己学习的过程，要把事情讲清楚，找到恰当的配图或案例很有挑战性，需要查阅很多资料，也需要向很多人请教，这些事情比玩游戏有意思多了。 > > 很感谢朋友们在线条由粗到细的过程中给予的肯定和建议。写书是个很孤独的过程，同一时间地球上可能只有一个人在写作某一专业细分领域的内容。做产品也是类似的，没有多少人理解你的产品，理解的人通常是竞争对手，没法进行深入交流，没有热情的反馈很难坚持下去。 > > 在书稿迭代的过程中，我发现写书并不影响工作，反而通过升级行业认知提升了工作效率。以前想得不够清楚的问题，写书的时候跳出问题本身，思考一些更通用的方法，反而能更有效地解决工作中的具体问题了，进入良性循环的状态后就越发沉迷，废寝忘食。如果不开始行动，更新《结网》只停留在一个想法，这些事情都不会发生。 如果产品停滞在了成长期，主要问题可能出在变现上。产品靠资本杠杆或口碑获客扩大了市场份额，但变现杠杆不足以实现收支平衡和盈利，团队剩余的资金越来越少，接近枯竭。 > **价值 2490 万的失败经验** > > 2019 年 8 月坨厂立项了一个海外聊天室的产品。这个产品 2019 年亏损 440 万，2020 年亏损 1800 万，2021 年 1 月亏损 160 万，1 月底公司关停产品，解聘相关员工，待付赔偿金 90 万，合计亏损 2490 万。如果亏掉这些钱没有换来任何认知，那就真的太亏了，所以有必要好好复盘一下，争取把后面的产品做好。 > > 失败的首要原因出在筛选产品概念环节。海外，意味着海外营销和海外运营，对此我们没有任何经验。立项时的想法是边干边学，边干边招。可产品一旦运转起来，学习的试错成本就要加上团队日常开销的成本，代价高昂；招人方面就更不可控了，新产品有风险本来就难招人，慢慢招人产品等不起，着急招人就会降低标准，导致招进来的人无法补足团队能力短板。不管是学习还是招人，都在大量消耗资金，也在消磨团队士气，进一步降低了产品的成功概率。 > > 要想产品成功，产品和团队匹配是前提，匹配不一定会成功，但不匹配大概率会失败。如果对于产品而言团队能力有短板，要么别立项，要么招人补足短板再立项。 > > 海外运营和海外营销这八个字可能不太直观，怎么就影响产品成败了呢？我举个很小的例子，我们的产品上线没多久就赶上了新冠疫情，海外的土豪们进入了居家隔离状态，不方便充值。有本地团队的公司会派人上门去土豪家收款，然而疫情期间我们怎么出国组建海外运营团队呢？这还不算线上充值要交 30% 的苹果税。 > > 既然这个产品大概率会失败，有必要亏损 2490 万吗？没必要，这涉及很多非理性决策。第一个非理性决策是在冷启动阶段就对团队进行扩容。 > > 2019 年 8 月到 2019 年 11 月是开发阶段，2019 年 11 月到 2020 年 3 月是冷启动阶段。冷启动刚刚完成，用户能在产品里玩起来了，留存率数据值得一看了，然而此时疫情的影响导致公司其他产品出现亏损，为保持这些产品收支平衡，需要优化人员。按照聊天室的发展势头，后面可能要招人，纠结了一下之后公司决定把其他产品的人员挪到聊天室产品，聊天室团队从 24 个人变成了 39 个人，扩大了 63%。从账面上看，公司就只有聊天室产品亏损，其他产品很快恢复了收支平衡。 > > 扩容带来很多问题。其中的一大问题是，由于沟通所带来的损耗，团队规模和团队产出并不是线性关系，而是边际效用递减，人力成本增加了 63%，团队生产力的增量远没有这么多。为了让大家都有事情做，产品和运营要提出更多需求，于是低效打磨的需求越来越多。产品完成冷启动之后，并没有顺利进入高速增长阶段，收入增长没有人力成本增长快，产品负责人的精神压力变大，焦虑的时间变多了，思考产品的时间变少了。实现一些容易操作的局部增长可以缓解焦虑，这时候就很容易陷入用战术上的勤奋掩盖战略上的回避的状态。其实冷静想想，增长漏斗底部的优化弥补不了增长漏斗顶部的问题，但人就是会有冷静不下来的情况。 > > 什么情况下需要扩容呢？团队扩容应该来自产品增长的需要，并且与增长幅度相匹配。团队扩容不是实现增长的手段，更不是解决公司其他产品问题的手段。面对压力，人难免会焦虑，但焦虑不能解决问题，倒是解决个人的焦虑问 > > 题有可能会间接解决产品的问题，因此建议有需要的产品经理可以考虑寻求专业心理咨询师的帮助。产品的成败在于人，人的心理健康如果出现问题，产出就会下降，产品失败的概率就会变大，不要忽视这类问题。 > > 第二个非理性决策，或者说第二类一系列非理性决策，就是没有贯彻 80/20 定律。比如低效打磨，就脱离了渗透留存矩阵中的核心体验，实际上这些细枝末节的体验根本不影响产品市场匹配的验证。Clubhouse 就那么几个功能，产品团队的时间和精力都花在了刀刃上，Clubhouse 就变成了留存和口碑双高的产品；我们做了“一火车”功能，却连好友列表的在线状态都没实现好（当然，这也有产品概念不同的原因，关系链对娱乐性聊天室而言没有社交聊天室那么关键）。这其实还牵扯到一个“抄作业” 的问题，因为不是原创产品，所以团队总觉得自己的产品和成熟产品相比差距很大，不“抄全”不舒服。而“抄全”这件事就意味着团队放弃了对用户需求的独立思考，“不舒服”这件事则表示团队决策的感性压过了理性。比如在产品的打开速度这个功能上，因为找不到行业标杆，研发人员断断续续用了 4 个月的时间进行优化，等找到行业数据后发现，前面 2 个月的优化其实已经够用了。更严重的问题是产品的瓶颈早就从留存和变现转移到了获客，但营销的力度没跟上。 > > 2020 年 3 月到 2020 年 6 月是产品的低效打磨阶段，人力成本与营销成本的比值是 8∶2，这个资源错配问题的一部分原因是团队扩容，但更重要的原因是团队没有从整个产品的角度寻找瓶颈。这时候公司的现金流开始紧张，资源紧缺是迫使人认真思考的良药，团队终于发现了团队扩容和资源错配的问题，优化掉了一些人员，加大了对营销的投入。 > > 2020 年 7 月到 2021 年 1 月是产品冲刺收支平衡的阶段，团队从 39 个人精简到 25 个人，人力成本和营销成本五五开。期间获得了很有希望的数据，我个人也追加了 200 万资金以做更多营销测试，但是运气不好，到了 2021 年 1 月，疫情的第二波影响来袭，产品营收反而急转直下，只能无奈关停。 > > 第三个非理性决策是关停时机的判断。根据展望理论的反射效应，投入越大，就越难接受产品失败，越想挽救产品。但是就算穷尽各种极限操作，产品成功的希望也是渺茫的，等到必须要关停产品的时候，已经伤及公司 > > 的现金流和整体士气，哪怕关停后公司整体现金流已经为正也于事无补了。 > > 所以，团队在立项阶段就应该把关停方案考虑进去，比如把赔偿金加入预算、设置关停触发条件等。如果团队提前做好了关停预案，在扩容上就会更谨慎，在关停的时机选择上也会更理性，那么关停实际发生时对整个公司和其他产品的影响就可以降到最小。 > > 成功的复盘往往只体现成功相关的因素，失败的复盘往往只体现失败相关的因素，其实都不是整个项目的全貌。虽然产品失败了，但坨厂增长总监李威对聊天室团队的评价很高，说这是他工作以来共事过最优秀的团队，团队的合作精神、看数据与用数据的能力、学习能力，都非常棒。 > > 在这个故事的最后，就用坨厂财务总监彭兰红的寄语结尾吧！ > > 凡是过往，皆为序章。 > > 凡心所向，素履以往。 为了避免不好的示范，再稍微补充一下资金投入的问题。我能给产品追加 200 万投资是因为这笔钱并不会影响我的生活，我的家人也支持我尝试一下。我见过一些创业者卖房维持产品，他们的投资人和朋友作为旁观者其实很反对这种做法。在资金耗尽之前，比较靠谱的变现假设应该都已经验证过了，剩下的都是不太靠谱的假设，甚至根本不存在新的假设可供验证，创业者只是想通过这种办法多撑几个月。寄希望于奇迹是买彩票不是做产品，我们做产品的目的是创造财富还是损失财富呢？非创业者产品经理可能不会面临资金损失的问题，但时间成本也是非常昂贵的成本，一样要思考如何让它的效用最大化。 成熟期的产品通常是盈利的，可能已经帮助产品团队实现了创造财富的目标。这种情况下坚持运营还是关停，取决于产品团队或公司对盈利规模的要求。即使产品还有些许盈利，只要它还在运营就需要产品团队进行维护，这些人去做其他事情的收益会不会更大？这就是一个衡量机会成本的问题。如果有机会进入成熟期产品的团队工作，是可以接触到该领域当前最前沿的行业认知的，收入可能也不错，但没有成长期产品的造富潜力大，收益和风险总是成正比嘛。 衰退期的产品虽然是即将沉没的游轮，但不等于没有吸引力。如果能保障几年的收入，积累一些工作经验，其实也是一种机会。衰退期的产品已经不再拥有最前沿的行业认知了，可能还看不上正在蚕食自己市场份额的新产品，如果能及时警醒，把行业认知的课补上，也许还有转型翻盘的机会。 #### **侦察兵和士兵** 由于自身行业认知的局限，加上竞争对手、政策法规等外部因素，产品的生命周期曲线通常不会按照我们的预期起伏。在它走势不理想的时候，我们应该坚持的一个底线是，理性地分析事实。很多人采取的却是鸵鸟政策，埋头不再看数据或者扭曲数据来满足自己的想象，这类应对方式只会让情况变得更糟。这就好比拳击比赛打到一半，处于劣势的拳击手给自己戴上了遮光眼罩。决策专家朱莉亚·加莱夫（Julia Galef）给这两种思维模式起名为侦察兵模式和士兵模式。这两种思维模式的驱动力不同，侦察兵模式是由求知欲驱动的，对事物保持开放的心态，了解到与自己直觉相反的事实反而会更兴奋；士兵模式是由胜负心驱动的，坚信自己认定的事情，遇到不符合预期的事实后会先想办法否定事实，而不是转变自己的想法（有点处于愚昧山峰的感觉）。 进化论奠基人、《物种起源》作者查尔斯·达尔文的父亲叫罗伯特·达尔文，是名医生。父亲给达尔文设计的人生轨迹是子承父业当医生，送他到英国当时医科排名第一的爱丁堡大学学习，但达尔文怕血，见不得尸体，做不了解剖，实在学不下去。当时的好工作除了医生还有牧师，于是父亲就送达尔文到剑桥大学学习神学。 神学并不是只研究基督教，当时的神学家认为研究丰富多样的生物可以凸显造物主的伟大。达尔文愉快地学习了几年昆虫学，对植物学也抱有浓厚的兴趣——神学院不知不觉中培养了自己最大的敌人。达尔文毕业后收到了环球旅行的邀请，乘船到世界各地考察，记录了大量的地质现象、化石和生物，并系统性地收集了很多标本。逐渐地，他发现了生物演化的事实，那么造物主还存在吗？达尔文陷入了长达 20 年的思考。直到博物学家华莱士准备发表一篇名为《论变种无限离开原始型的倾向》的论文，达尔文才意识到华莱士独立提出了自然选择学说，在朋友们的建议下，同年，达尔文跟华莱士一起发表了有关自然选择的论文，并于第二年出版了《物种起源》。 在《道德动物》一书中，罗伯特·赖特提到，一位作家曾经问道：“为什么是达尔文？和他的许多同事相比，他缺乏野心、没有想象力、才疏学浅。为什么他能发现其他人孜孜以求的理论？究竟为什么一个在学识上如此有限，在文化上如此迟钝的人，竟构思出如此结构宏伟、意义深远的理论？”我想，这离不开达尔文的侦察兵思维模式，他没有因为坚信造物主的存在而否定自己亲眼所见的事实。 士兵思维模式并不是一种缺陷，而是人类祖先存活下来的成功经验，我们面临的问题是不分场合的路径依赖。我们的穴居人祖先需要通过士兵思维来维护自己在部族中的形象以获得生存空间，但生活在网络时代的我们会和比祖先接触到多的多的人，其中大部份都是擦肩而过的陌生人，在陌生人面前采用在乎“面子”的士兵思维模式并不能给我们带来长久的收益。在血亲谱系中，工作和保险的重要性越来越高于血亲们的认可和支持。在工作中，如果士兵思维模式和个人成长或集体利益发生冲突，通常来说收益更大的选择是个人成长和集体利益。公司如果在乎士兵思维模式大于成长和利益，就去找一家更在乎成长和利益的公司好了。 #### **压力管理** 创业公司死亡只有两个原因：创始人放弃，或者现金用完了。我在腾讯接受过一堂压力管理的培训课程，当时并觉得这个培训对我的工作有什么帮助。在之后创业的过程中，我没有在现金用完之前放弃，而且身心健康、乐观向上，压力管理功不可没。 压力管理的第一步是识别自身的压力状况，我们可以通过下面这个简版的压力测试题来监测自己的压力状况。请回想自己在过去 1 个月内是否发生过下述情况，如实选择，并按以下标准计分：从未发生计 0 分，偶尔发生计 1 分，经常发生计 2 分。 * 觉得手上工作太多，无力应付。 * 觉得时间不够，所以要分秒必争，例如走路和说话的速度很快。 * 觉得没有时间消遣，成天惦记着工作上的事情。 * 遇到挫败时很容易发脾气。 * 很在意别人对自己工作表现的评价。 * 觉得上司和家人都不欣赏自己。 * 担心自己的经济状况。 * 有头痛、胃痛、背痛的毛病，难以消除。 * 需要烟酒、药物、零食等抑制不安情绪。 * 需要借助安眠药才能入睡。 * 与家人、朋友、同事的相处令你心情不佳、易发脾气。 * 与人交谈时不能耐心倾听，经常忍不住打断对方的话题。 * 上床后思潮起伏，牵挂很多事情。 * 觉得工作太多，不能每件事都做到尽善尽美。 * 当空闲时轻松一下就会心生内疚。 * 做事急躁、固执、任性，而事后感到内疚。 * 觉得自己不应该享乐。 累计分数参考标准如下。 * 0\~10 分：压力程度低，轻松自在，也可能生活缺乏刺激，比较简单沉闷，激情和做事的动力不足。 * 11\~15 分：压力程度中等，虽然有时感到压力较大，但仍处于可以自我调节的范围内。 * 16 分或以上：压力偏高，需要寻找压力源以及调节压力的方案。 这个测试主要是为了引导大家关注压力与心理健康，如果发现分数不理想或不符合自己的情况，请不要太介意，你的实际情况应以专业机构给出的结果为准。 适度的压力能帮助我们应对各种挑战，而过度的压力会影响我们在工作中的判断和表现，并且可能危害我们的身心健康。当我们意识到自己正在承受过度的压力后，接下来就需要分析压力源是什么。压力源可能存在于多个方面，如下图所示。
个人方面健康欠佳、情绪不稳定、自卑、失落等
家庭方面家庭经济状况欠佳、家人间的冲突、子女教育、父母陪护、亲人去世等
朋友方面缺乏知己、被朋友欺骗、发生纠纷等
工作方面任务太多、业绩不理想、同事关系不好、沟通不畅等
社会方面居住环境差、交通拥堵、卫生环境恶劣、社会风气败坏、通货膨胀等
调节压力的关键在于正面解决压力源，而不是消极逃避。（和解决产品瓶颈问题是不是很像？）压力源往往隐藏得比较深，可能是我们的某种本能把它隐藏了，表面上好像没有任何问题，但它却在角落里持续地制造压力。（和定位产品瓶颈问题是不是很像？）比如，工作中无法进行快速决策，就是压力的一种表现，隐藏其后的压力源可能是害怕做出错误的决策。当我们认清压力源之后，找到一些适当的方法降低错误的成本，如最小可行产品，压力源得到解决，压力自然也就变小了。 有一次同事找我抱怨说，设计广告素材的过程中问题层出不穷，有种按下葫芦浮起瓢的无力感。我听他讲了一下过去遇到的问题，发现这些问题是有层次的，符合作品创作遵循的 6 个步骤。比如有一些是概念问题，前期已经解决掉没再出现了，现在还在出现的是风格问题和结构问题。有了这个视角，问题层出不穷就变成了已经彻底解决了概念问题，风格问题也快要完全解决了，其实我们已经取得了阶段性的成果，他的压力肉眼可见的减少了。 当然，压力源不一定都能被消除，有句话叫“改变可以改变的，接受无法改变的”。在我们的生活和工作中，确实有很多事情无法改变，比如飞涨的房价、父母的衰老、同事的脾气，等等，我们接受这些事实，这些事实存在，我们不接受事实，这些事实依然存在，还多出来一个压力。一个具体的例子，幼儿到了两岁左右会进入“违拗期”，开始有独立的意识，会违抗家长的意愿，故意和家长对着干。很多家长并不了解“违拗期”的概念，只是发现小孩子忽然不听话了，试图用对抗的方式让小孩子听话，结果自然是徒劳无功，给自己增加了压力。《从出生到 3 岁》一书指出，家长应对幼儿“违拗期”最好的方法，就是了解“违拗期”对于幼儿成长的重要性和必然性，提前接受这个概念并做好心理准备，这其实就是理性情绪行为疗法（REBT）发明人阿尔伯特·艾利斯所说的理性，“有弹性的，根据事实而符合逻辑的，并非对或错的分别”。 不接受无法改变的事情，很容易引发可怕的后果，举个比较极端的案例：暴力伤医。大部分医闹的期望是恢复健康，殊不知本来病人的病情发展趋势就很不乐观，医疗只能延缓病情的恶化。医闹者在病人病情恶化后不接受现实，通常如此这般跟医院“理论”：“我父亲进医院的时候也就坐个轮椅，住院治疗花了这么多钱，现在反而胳膊都不能动了。我不懂医，我的要求不高，进来的时候什么状态出院还是什么状态，这不过分吧？”还好互联网从业人员的素质比较高，暴力伤产品经理或开发工程师的案例极少。

医闹是怎么发生的

传课网创始人王锋曾经跟我说：“创业就是你所设想的好事都没发生，你没想到的坏事接踵而至。”把创业换成做产品也一样，放低自己的预期，做好迎接“黑天鹅”的心理准备，有利于保持健康的心态。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://jiewang.gitbook.io/chan-pin-jing-li-de-wu-xian-you-xi/di-5-zhang-yan-zheng-chan-pin-gai-nian.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.