22-硅谷产品实战36讲

开篇词 | 打造千万用户的世界级产品

每次朋友聚会，甭管是高雅的奶酪红酒派对还是啤酒撸串，大家一见到我，总是会眉飞色舞地跟我吐槽，说我们刚刚发布的产品哪里哪里不好用，或者哪里哪里好玩得不得了；甚至和六七十岁的老校友聊天，说得最多的也是我们发布的产品。

纽约的地铁上、哥斯达黎加夜店的舞池上，看着形形色色的路人，坐着的，趴着的，站着的，看到他们拿出手机在 Facebook 产品的界面上敲敲打打，这是我最幸福的时刻。

我叫曲晓音，在 Facebook 做产品经理，领导着一个几十人的产品团队。之前，我在 Instagram、微软都做过产品经理，担任过多个千万级用户产品的产品经理，也有过自己的教育创业公司，还在上市之前的 Atlassian 做过营销工作。而我最喜欢的，就是打造世界级的产品。

我向来喜欢写作与分享，而第一次发布产品经理的相关文章，是写在美国 Medium 网站的产品经理面试秘籍，没想到文章一发布瞬间就火了，我因此收到无数的邮件和信息，太多人问我怎样才能成为产品经理，怎样才能成为一个卓越的产品经理。受宠若惊之余，我也意识到两个关键问题：一是产品经理受众人热捧，因此有很多人期望转行为产品经理；二是太多人对如何能够脱颖而出，成为真正优秀的产品经理备感困惑。

产品经理貌似随处可见，但是卓越的产品经理难找得很。产品经理理念与工作方式的不同，直接影响团队的开发效率和产品上线后的表现。因此，下面的这几个问题，是否已经说到你的心坎儿里？

你加班好几个月写出几万字的产品需求文档，却没有解决真实存在的用户需求；

你辛辛苦苦推出的新产品，却无人问津，没人下载；

你刚刚成为产品经理，怎么处理好产品团队关系，让你“亚历山大”；

或许你想进入产品经理这个行业，却不知道产品经理到底是什么，以及从何开始；

或许你信心满满的参加面试，可不知怎么的，总是拿不到理想的 offer；

或许你压根不想自己当产品经理，只是想知道，面对你那个讨厌的产品经理，该怎么对付他。

如你所期望的，我将在这个专栏里解决你的这些痛点。

那是还在上学的时候，我刚刚听说有产品经理这个岗位，感觉酷极了。当时翻遍书海，找到了一本刚刚出版月余的Cracking PM Interview，即《产品经理面试宝典》，如获至宝，虽然这本书讲的内容其实很浅显，但对我而言就好比发现了宝藏。因此，我希望通过这个专栏来帮你梳理思路，希望它之于你，也能像当年这本书之于我一样，带你入行，给你指引方向，让你成为一个更好的产品经理。

我希望通过这个专栏， 通过我在顶尖科技公司的实战所学，向你分享那些自己看书学理论学不到的东西。而我通过亲身实践试错得来的“秘籍”，希望能够总结我的试错经验，帮你绕过那些坑儿。在这里，我要给你讲清楚三件事。

第一，如何把一个随便说说的 idea，或者用户一句小声的抱怨，转化成一个实实在在、有着卓越体验的世界级产品。我会讲解产品经理最重要的基本功，比如产品开发的流程、如何理解用户需求、如何进行用户调研、如何制定产品策略、如何分析产品数据、如何决定产品功能、如何写产品需求文档，如何指导产品发布，等等。这一部分，希望能够提高你的产品思考能力。通过这个部分，让你能开发出真正满足用户所需的、具有优秀用户体验的明星产品。

第二，如何引导团队里不同性格、不同经历、不同脑洞的工程师、运营、市场、法律、设计达人们，让大家能够拧成一股绳，高效地开发出最优秀的产品。我会把你想问但不敢问、敢问却得不到回答的那些问题，给你一五一十地讲出来。怎样晋升更快，怎样催促工程师加快工期却不得罪他们，怎样告诉你的团队项目被砍了，等等这些问题将不再棘手。这一部分，可以让产品经理学会如何高效管理团队，也可以让工程师、运营、设计师与不同职能的同事更好的密切配合，搞定你的产品经理。

第三，告诉你如何进入产品经理这个行业，带你了解硅谷和国内的产品经理有什么区别，初创公司和大公司的文化差异在哪里，怎么进行产品经理面试，面试又考察哪些内容。最后，我还会给你模拟一个硅谷顶级公司的产品经理面试，培养你世界级产品的思考能力。最后这一部分，希望能够帮你了解最新鲜的行内信息，帮你成为一个更好的产品经理。

我喜欢从 0 到 1 做产品，也喜欢从头开始尝试新鲜事物。我会在这个专栏里和你分享硅谷产品经理工作的点点滴滴，也会仔细阅读每一位朋友的每一条留言。在这短短的三个月时间里，希望我们一起分享、交流和成长。

01 | 什么是优秀的产品经理？

引言

做了产品经理这么多年，最难的事情是和长辈、朋友们解释我是做什么的。常见的对话通常是这样的：

“你是做什么的？”
“我是产品经理。”
“所以你写代码吗？”
“我不写。我主要是负责决定产品的体验和功能。”
“哦，所以你是做设计的？”
“其实也不是。我更多的是组织产品团队，决定应该推出什么样的产品，拥有什么样的功能。”
“就是说，你实际上啥也不做， 就动动嘴？”
“。。。”

产品经理的定义

这几年，产品经理这个职业越来越热门，无数的朋友同学来问我怎么转行做产品经理，但是每次我详细问他们是怎么理解产品经理这个职业的，却发现大家说什么的都有。

有的说是做科技的还不用写代码，感觉终于有自己可以做的科技岗位了；

有的说经理嘛，听上去就是权利挺大的，一毕业如果去做这个倍儿有面子；

还有的说，将来想自己创业做老板，产品经理是最合适的敲门砖。

实际上，我对产品经理的理解是，带领产品团队，在高效的时间内推出满足用户需求的产品。这里面包含四点。

第一是，“经理”的意思，更多是说产品经理要能够带领和鼓舞一个产品团队，这里面有工程师、设计师、律师、营销经理、数据科学家等等不同职位的人。这就要求产品经理具备管理能力、处理团队人际关系的能力、统筹大家工作的能力、制定高效工作流程的能力等。

第二是，能够理解用户需求。通过市场调查、用户调研等等，从用户不经意的小抱怨中找到巨大的机会，把这些用户需求转化成切实可行的产品功能，让用户的体验更加通畅。

第三是，能够高效执行。产品开发的过程从来都是紧赶慢赶，有 deadline 要赶，或者要在竞争对手推出新品的时候，快速行动推出自己的新品抢占市场份额。这就需要产品经理能够做好项目管理，提前计划，在团队成员被一些外部因素阻碍进程的情况下，快速有效地帮助他们解决这些问题（也叫作 blocker）。在科技行业，常说的一句话就是要 move fast，快速行动，高效执行。

第四是，要有长远的眼光，能够策略性地制定产品的下一步规划，让这个产品能够一步步走向成功。而不能仅仅停留在这一版产品，或者现在正开发的这个功能，而是有长远的眼光 。这也是非常重要的一点。

对产品经理的几个误解

1. 产品经理是老板，工程师、设计师等都得听我的。

我在 Facebook 做产品经理的第一个月，就犯了一个错误。我和一位工程师说：“我和你老板说了，安排你来做这个项目。”

没想到这位工程师马上就火了，他说“什么叫安排我来做这个项目，从来都是我自己决定做什么项目”。原来，在 Facebook，工程师最终可以决定自己想做什么项目，就算是公司老板都不能安排他做自己不喜欢的项目，就更别说产品经理了。

我刚刚开始工作的时候，觉得既然我是经理，大家就应该听我的指挥，结果一来就碰了壁。其实，正确的做法是和工程师商量，跟他讲清这个项目为什么很重要， 能解决什么问题，然后说服他来做这个项目，而不是指望他被动地接受安排。

在很多公司，产品经理虽然管理一个产品团队， 但并不是团队工程师或者设计师的老板，没有直接的生杀大权，当然团队的工程师或者设计师就不会完全听从你的“指挥”，而是需要你来说服他们，激励他们，让他们发挥能动性自己主动做事情。在遇到分歧的时候，也要尊重他们的想法，慢慢商量，而不是跋扈专横地直接做决定。

2. 产品经理的工作就是画画 UI 图。

前一段时间，一些想转行做产品经理的朋友邀请我去回答问题。让我意外的是，一堆正在准备产品经理面试的人，问我最多的却是：“产品经理平时都用什么软件画图？我怎么样才能快速提升作图技能？” 在他们看来，要是能灵活掌握画图软件，拿到产品经理工作的几率就会增大很多。然而在我看来，面试的时候，公司指望通过画图技能决定招谁，这是一个非常大的误区。

很多初级的产品经理花大量时间写产品需求文档，看看其他产品怎么做的，东抄抄西凑凑，再用 wireframe 软件画个按钮，加个对话框，加班加点，追求完美，是要方按钮还是圆按钮，要精益求精，然后把图纸给设计师精修一下，最后抛给工程师，让他们照着图纸原封不动地开发出来。其实，这只是产品经理工作的一个非常小的部分，画草图的目的也不是为了让工程师原封不动照做， 而更多地是清晰沟通产品的想法。

对于产品经理来说，最重要的工作是决定该做什么。这包含：

第一，对市场以及用户需求的深入了解；

第二，能够制定出合理有效的成功指标，然后用成功指标推动产品功能的发展；

第三，思考帮助用户解决这个问题应该有什么样的用户体验， 在现有产品不受欢迎的情况下， 快速找到问题所在，并制定计划进行改进。

准确地说，区分一个优秀的产品领袖和普通的产品经理，更多的是看他们思考的部分。说白了，画图的工作你做得再好， 也不会比设计师做得好，如果你花时间的地方，团队其他人比你做得更好，那你就浪费了团队的时间，也没有发挥出自己的优势。

3. 产品经理就是催工程师干活的。

之前有个笑话说，产品经理就是“程序员鼓励师”，就连我自己刚入行的时候，也觉得我的工作就是要催工程师快狠准，多干活，像监工一样，生怕他们偷懒耍滑。后来，做得久了，仔细观察过工程师的工作，发现偷懒耍滑的其实占少数，大部分工程师是很拼命的，也很认真，工作态度还是非常积极的。

产品之所以拖延，其实更有可能是以下的原因：

第一，产品的需求或者由于前期准备不充足或新的用户反馈需要修改，从而增加了开发时间。

第二，开发时间的前期预估不准确。本来需要几个星期才可以完成的事情，之前过于乐观地估计了更短的时间。

第三，沟通遇到了问题，当工程师发现某个功能其实难度非常高， 执行压力大的时候，没有尽早沟通，deadline 快到了才说，耽误了工期。

第四，产品功能的设计过于烦琐，本来可以简化的功能，却花费了大量的时间，其实这个功能根本不需要浪费这么长的时间。

尽管产品经理有责任保证产品按期交付，但你看，真正能够解决高效开发的方式，并不是狠催工程师、每天夺命 call 这么简单直接， 这就需要产品经理能够发现上述问题，及时解决，从而才能高效执行。

总结

欢迎你和我一起开启产品经理的旅程，第一篇文章我讲解了产品经理的工作性质以及工作内容：产品经理能够带领产品团队，在高效的时间内推出用户满意的产品；产品经理决定什么时候该推出什么样的产品，应该具备什么功能，并且能够用策略性的眼光指引整个产品长期发展的方向。

我还讲了产品经理常见的几个误区。

第一，产品经理并不是管人的老板，并不能决定人事调度，更多的时候需要通过影响来说服团队成员， 这其中包括非常多不同职能的同事，比如工程师、设计师、数据科学家等等。

第二，产品经理的工作并不只是画画草图、画画流程图。真正好的产品经理，能够对产品的功能满足什么样的用户、什么样的需求了如指掌，能够高效地沟通。

第三，产品经理的工作并不是催工程师干活。虽然对于产品经理来说， 项目管理是一个必不可少的技能，保证产品按时交付是产品经理的责任，但是在实际操作中，导致产品不能按期交付的原因很多时候并不是工程师偷懒耍滑，而是前期准备、时间估计、面对变化缺乏快速解决方案等导致的。

思考题

最后留一个思考题，想一想，如果你要为一家创业公司招聘一个产品经理，你会如何制定评判标准呢？

02 | 硅谷的产品经理是什么样子的？

硅谷的产品经理热

如果你问斯坦福大学的大四学生，竞争最激烈的工作是什么？他们的答案已经不是投资银行分析师，或者麦肯锡的咨询顾问，也不是谷歌的工程师，而是：产品经理。

其实，不仅是本科学生， 斯坦福大学和哈佛大学的 MBA 毕业生也在疯狂地准备产品经理面试，而斯坦福大学商学院甚至在今年刚刚开设了产品经理课程，这是史无前例的。

这么多最最优秀的学生的梦想，就是能进入谷歌的轮换制产品经理项目。

Yahoo 的前 CEO玛丽莎 · 梅耶尔曾经在谷歌担任产品经理，她建立了谷歌后来闻名遐迩的产品经理项目，每年在全球挑选和培养三四十个刚毕业的、“最聪明”的年轻人，让他们一上来就直接带团队管产品。

这些年轻人会得到对公司成功非常重要的顶级项目，并且会有专人对他们进行各方面的培训，还会组织一次环游世界的游学，玛丽莎亲自带领他们和世界各地的用户交流，拓展他们的视野。

红杉资本的首位女性高级合伙人杰斯 · 李（Jess Lee），之前曾担任 Polyvore 公司 CEO（该公司后被 Yahoo 用 2 亿美元收购），就出身于玛丽莎开创的这个谷歌产品经理训练营，在谷歌担任了 4 年的产品经理。

这个项目还出了 Dropbox 的产品总监杰夫 · 巴蒂尔马（Jeff Bartelma），融资上亿美元的任务管理创业公司 Asana 的创始人贾斯丁 · 罗森斯坦（Justin Rosenstein）， 被 Salesforce 以 7.5 亿美元收购的 Quip 的创始人、曾任 Facebook 首席技术官的布莱特 · 泰勒（Bret Taylor），还有 A/B 测试公司 Optimizely 的两位创始人丹 · 斯洛克（Dan Siroker）和皮特 · 库曼（Pete Kooman）等等。

所以，进入谷歌的这个产品经理项目成了斯坦福、哈佛这类学府最优秀学生的目标。在这之后，Facebook、LinkedIn、Uber 等公司开始建立了自己的产品经理项目，为期一到两年，项目结束之后，这些年轻人会立即被委以重任。他们中的很多人，二十多岁就成了公司高管，而公司几乎所有能在 25 岁就当上产品经理的人，都是这个项目培养出来的。

这些硅谷顶级公司的产品经理项目加在一起，一年录取的人也不过一百多个，而随着申请者的人数水涨船高，录取率可以说是“百里挑一”。

而对产品经理这样高涨的热情，绝不仅在校园可见。已在谷歌、Facebook 这样的公司工作的工程师、设计师、运营经理们，也在积极地准备产品经理面试，希望能够通过这样的方式进入硅谷最核心的岗位。

为什么硅谷人会对产品经理抱有这么大的热情呢？

首先是薪资。 2016 年，美国的招聘网站 Hired 发布的薪水调查显示，在硅谷收入最高的职位并不是软件工程师， 而是产品经理。苹果公司的高级产品经理年薪高达 17 万美元。

其次是职业发展。 很多 CEO 之前都是产品经理出身，Yahoo 的前 CEO 玛丽莎，谷歌的 CEO桑德尔 · 皮蔡，盖茨的夫人梅琳达 · 盖茨全部都是产品经理出身。

在谷歌、Facebook 这样的科技巨鳄中，产品经理可以一步步晋升到副总裁级别，并没有什么职业瓶颈。而如果你选择创业，产品经理所需要的技能和创业公司的 CEO 非常匹配，所以产品经理又是很好的创业训练营。

有意思的是，如果 Facebook 这样的公司收购了一个初创公司，那么这个初创公司的 CEO 进入 Facebook 多半会被聘为产品经理。所以很多硅谷的人说，产品经理是离 CEO 最近的职位。

硅谷的产品经理是什么样子的？

硅谷的产品经理相当于产品的全线负责人，他们不仅负责制定产品的功能要求，还负责制定产品线的蓝图和策略。

看上去产品经理每天的工作就是开开会、写写文档，和各种各样的人沟通，但是一个优秀的产品经理绝对是硅谷猎头们，以及各大公司招聘部门不惜一切代价也要招来的人才。为什么？Google 风投的合伙人肯·诺顿（Ken Norton）曾说：长期来看，公司的成与败取决于产品经理。

1. 什么样的背景才能成为产品经理？

这个问题上，各个公司有各自的招聘哲学。谷歌的产品经理全部要求是技术背景出身，面试的内容也包括了编程面试。但是 Facebook 和 Uber 这样的公司，并没有对技术背景的硬性要求，而是喜欢招一些多元化背景的人。

我在 Facebook 的同事有之前的职业音乐家、艺术家，也有投资银行家、咨询师、天使投资人、新闻记者等各行各业出身的人。

可以说，硅谷的产品经理尽管百里挑一，录取难度极高，但是还真没有一个固定的模板，要求一定是什么专业或者什么背景出身。

2. 影响他人，而不是直接管理

从行政管理角度来说，产品经理需要的是影响他人，而不是直接管理他们。 硅谷的很多公司，产品经理并不担任行政职务，也就是说工程师和设计师有各自的老板，并不汇报给产品经理。

在 Facebook 和谷歌这样的公司，工程师导向的文化背景下，产品经理并不能要求工程师做什么工程师就照做。这就要求，产品经理得晓之以情动之以礼，能够用诱人的未来蓝图、逻辑性的数据支持，和切实可行的运作方案，让工程师们受到启发， 激发他们的工作热情和潜能，从而实现自己的产品蓝图。

3. 1 个产品经理 vs 7 个工程师

产品经理和工程师们的比例，每个公司有所不同，但一般 7 个工程师对应一个产品经理算是一个比较常见的比例。

4. 越高级的产品经理，越不会花大时间写需求文档

在硅谷，一个优秀的产品经理其工作不仅仅是写出一个完美的产品功能文档。实际上， 越是高级的产品经理， 越不会花大部分时间在写文档上。

对他们来说，如何能够思考产品两年三年之后的长期计划，如何能够把一个产品领域分成几个不同的功能线，如何制定有效率、有创新能力的团队文化，让团队里的设计师、工程师、运营经理等，能够最大限度发挥自己的工作积极性，如何管理一个不断扩大的产品团队等等， 才是应该花时间的大头。

在 Facebook，你很少看到产品经理花很多时间画流程功能设计图，大部分时候产品经理会讲清楚产品解决的问题，如何衡量产品的成功标准，然后会和设计师们在白板面前写写画画，在沟通中设计产品的体验过程。

你很少会看到产品经理一个人闷在电脑前，几个星期写出一份精确到每一个按钮的产品需求文档，然后直接给设计师开始设计，然后工程师开始编程。我们的产品设计过程是一个团队合作，想法不断碰撞的过程， 如果一个人独自写所有的文档，万一某个功能和现有的架构根本不契合，又要重新来过，反而浪费了大量时间。

5. 并非事无巨细，应该懂得放权

一个好的产品经理，知道什么决定需要自己拍板，什么决定可以交给团队的其他人完成。好的产品经理还是一个很好的沟通者，能够组织一个有效的产品设计会议，让工程师和设计师能够快速地了解彼此的限制条件，从而设计出投入最少，回报最大的产品功能体验。

总结

今天我先从硅谷的产品经理热说起，揭秘了美国最优秀的计算机专业毕业生、商学院毕业生全部都“趋之若鹜”的产品经理项目是怎么运作的，培养出了什么人才， 也解释了为什么 Yahoo、谷歌、Asana、Quip 的 CEO 全部都是产品经理出身。

之后，我通过描述硅谷的产品经理是什么样子的，描述了产品经理应当具有的一些重要技能，相信你已经了解为什么“长期来看，公司的成与败取决于产品经理”，知道了为什么最优秀的产品经理不应该把全部时间花在写文档上，而是应该让团队的成员得到积极影响，让别人替自己做决定。

思考题

第一个是，如果你曾经和产品经理工作过（或者自己是产品经理），欢迎留言和我讲讲你见过的优秀产品经理最突出的特点是什么？你见过的最差劲的产品经理最大的缺点又是什么？

第二个是，硅谷有着较重的工程师主导产品开发的文化，因此外界对硅谷产品经理的职责和权力有很多猜测和想法，不知在你的公司是产品经理导向还是工程师导向呢？欢迎给我留言。

03 | 科技巨头和初创公司的产品经理有什么不同？

其实对于不同的公司来说，产品经理的定义可能会差非常多。在科技巨头当一个产品经理，和在一个刚刚成立的小公司做，需要的技能和要求其实非常不一样。

在科技巨头做产品经理

像谷歌、Facebook 这样的公司，至少有几百个产品经理，上万名员工，一般每一个技能都会有专门的人来对应，而且划分地非常细。

比如，单单市场营销我就有三个同事负责：一个人负责市场调查，了解清楚竞争对手都在做什么；一个人负责产品的发布策略，负责和公司的公关部门一起制定媒体发布策略；一个人负责新产品发布的用户文档、网站更新，帮助板块的文档撰写。

所以，把所有的设计、工程、法律、市场、营销、运营、公关等等这些部门加在一起，负责我这边产品的人就可能有 40 多个。对于这么一个庞大的产品团队，这么细分的职能划分，我的工作是要知道什么时间让什么人做什么事，确保每个人的部分成功有机结合在一起。

要思考怎样界定他们每个人工作的成功，什么决定需要我自己做，什么决定可以让大家去做。在这样一个很大的团队里，作为产品经理，我不可能每一个决定都亲力亲为，所以要知道什么时候可以放手。

要思考怎样建立一个有效的、可持续的工作流程。比如，什么会应该找什么人来参加，不可能每个会都乌拉拉 40 个人全部参加，那样我们什么决定也做不了。还有， 在这些人有不同意见的时候，能不能有一个客观公正的做出决定的标准。还有就是，产品的需求会议该怎么做？

这么大的一个团队还有一个问题，就是总会有新人来，总会有旧人走。因此，怎样能快速帮助新人适应环境、了解产品的背景知识、快速上手，做好新人旧人之间的衔接非常重要。

如果你在大公司做一个从 0 到 1 的产品，最常见的方式是先组一个非常小的团队试试手，一旦能够证明一定价值了，公司会立马增大投入，快速招人，所以很有可能一年内团队的规模就涨一倍。你要思考，这个时候怎样能够重新设定工作的流程、帮助更多的新人适应环境、在团队不断扩大的情况下仍能确保高效地做出决定。

在一个大公司人很多，所以办公室政治肯定是不可避免的，特别是对于产品经理而言。很多时候，最困难的往往不是产品发布之后的外界反应，而是自己内部人的反应就已将你整得头大。或者，如果有一个非常好的项目，很快别的组就会纷至沓来要和你争一杯羹；还有可能，上司突然换了人，公司重点突然转移了，或者你的部门突然开始重组。
在这些变化不断的内部环境中，如何才能让自己的团队稳定平和，反而成了一门艺术。所以一个好的大公司产品经理 ，非常擅长和他人找到利益的共同平衡点，不断制造双赢的机会，这样才能让你的职场生涯稳步向前。

在初创公司做产品经理

在小型初创公司做产品经理，讲究一个快狠准。公司每天都在生死存亡之间，甚至来不及招人，也没有一个成熟的新人培训体系，更没有一个清晰的职能划分，所以说每天产品经理都得“吃百家饭”做各种各样的事情，甚至很多时候都需要亲力亲为。

没有数据科学家？那就得自己做数据分析，Tableau、SQL 来一堆。没有设计师？很多产品经理自己就会画草图，让工程师比划比划也就这么发布了。这在大公司绝对是不可想象的，因为大公司的设计是需要经过公司审核，符合公司设计规范和设计流程的，一般不会让产品经理随便设计一下就拿来发布。

那么，在初创公司做产品经理有哪些特色呢？

在初创公司做产品经理，能够快速地学习提高。 赶鸭子上架，说来就来，快速学习一些新知识新技能，然后就可以马上拿来用，甚至是在使用中不断学习提高。

在初创公司做产品经理，能够在数据缺乏的情况下利用用户调研等方式找到正确的方向。 很多时候你做的产品可能本来也没有人用，做完之后还是没有人用， 所以根本没有办法像大公司那样把 0.1% 的用户拿出来做对比实验，精准测试结果。所以这就倒逼产品经理要做很多的用户调研，亲自和用户沟通、问问题，找一些非常有创意的方式来快速证明你的假设，甚至很多时候还要相信自己的直觉。

初创公司做产品经理的另一个要求是，要非常有前瞻性，能够制定产品策略。 大公司的很多产品经理，已经知道自己要做什么，如果你是做视频广告的，公司估计已经有了广告的策略，你只需要思考如何把它转化成视频。但是如果是小公司的产品经理，很多时候还没有一个固定的框架，你需要思考整个公司的框架应该怎么走，这样的思考其实是非常需要前瞻性的，你做的可能是很多大公司的高管才会做的事情。

对于初创公司的产品经理非常非常重要的是，公司是一个刚刚起步的阶段，可能缺乏最最基本的流程和工作方法。 比如说， 根本没有什么产品需求会，需要你从头开始设计；也没有什么工程经理，需要你充当工程经理的角色；也没有一个能够让大家认同的决策方式，甚至是产品发布这样的大事也就是按个按钮就发出去了。所以，产品经理需要有意识地设计能够让公司更高效地做出决定、让团队合作更默契的一些工作方式。

小公司到大公司

其实很多在科技巨头工作的产品经理们来自于小公司，甚至以前是初创公司的 CEO。他们中的很多人来到大公司之后，会感觉到文化上的不适应。我见过很多人，以前自己的公司做得非常好，卖了很多钱，但是来到大公司以后却水土不服，甚至没呆多久就黯然离开。

这是为什么呢？我发现有这样几点原因。

并不能适应公司的办公室政治，不知道如何权衡不同部门之间的利益关系，创造和其他部门双赢的结果，说白了就是不知道如何和其他部门合作。

习惯了亲力亲为之后，对每个小细节管得太多，反而让自己团队里的其他人觉得没有发挥空间，从而导致整个团队的效率非常低下，士气低落。因为以前是 CEO，所以习惯了每件事儿都自己拍板，现在当了产品经理之后，在行政关系上并不是设计师或者是工程师的老板，当然别人也就不会听你发号施令。而以前初创公司的产品高管们，并不能适应通过鼓舞他人，通过影响来管理团队的方式。

在大公司，非常重要的是知道如何管理和领导们的关系，什么事情该汇报，什么事情该自己决定，以及如何汇报工作的进度。因此，他们反而可能处理不好和自己上司之间的关系，或者锋芒过露，导致不受器重。

我的建议是：

一开始放低姿态，努力学习，先和同事们建立良好的互信关系，结交几个无话不谈的好朋友，了解办公室的利益关系。

积极向同事们寻求建议和反馈，一定要主动问大家对自己有什么建议，在什么方面可以提高。然后积极思考解决方案， 和信任的同事定期讨论自己的表现，问他们自己有没有进步。

和新领导刚开始工作的时候，就问问老板他是什么风格，希望什么样的事情自己汇报，希望什么样的事情自己解决，刚开始的几个星期，主动问老板自己的表现如何，有没有什么改进意见。

大公司到小公司

很多大公司的产品经理，会创建自己的公司，或者到初创公司担任产品经理的职位。他们中的很多人，同样会有很多不适应的地方。

在我看来，不适应的原因有以下几种。

凡事过于讲流程、不够灵活，不太能适应非常动荡的创业公司环境。

做事风格过于蜻蜓点水，只关注大方向，执行能力比较差，在公司资源不足的情况下，无所适从。

做决定的时候可能过于在乎让所有人满意，所以决断力上不敢发挥，不太敢做风险非常大的决定。

适应不了小公司每天做一百件杂事的环境，“亚历山大”。

我的建议是：

先融入小公司的工作环境， 一定要意识到现在的公司和以前不一样， 以前行得通的流程现在不一定可行。所以，先积极了解公司的文化，决定怎么做，大家的工作时间多长，公司现在的最大挑战是什么。当发现小公司管理混乱的时候，思考一下自己以前有哪些流程可以用得上，主动提出来。

关注“当日事当日毕”，如果有的事情能够马上解决，就不要拖延，如果资源不足的话，先不要抱怨和反馈，而是思考一下自己有没有什么方式能够解决，同时问问同事们对自己的表现有没有什么反馈。

不要觉得这件事不属于自己的份内事， 就不需要自己做，遇到事情先主动承担，把事情做好。就算你是营销人员，遇到大家有困难的数据问题，你也可以积极帮助大家解决。

总结

今天这篇文章，我对比了科技巨头和初创公司产品经理的区别。可以看到，大公司人多部门冗杂，每个具体的工作都有专人负责，做决定讲究各部门意见的统一，做事情讲究高效的工作流程，办公室政治也无所不在，而好的产品经理在这样的环境下，能够激励各部门的同事们，满足他们的利益，制定井然有序的运作机制。初创公司的产品经理，则需要敢想敢闯敢干，有前瞻性，执行快狠准，并且哪里需要就去哪里，讲究灵活果敢。

我还讲了大公司与小公司的文化差异，不同背景出身的产品经理不适应的原因，并提出了适应新环境的一些建议，希望对你有所帮助。

思考题

最后留两个思考题，请你思考一下。

第一个是，如果你现在是一个大公司的产品经理，思考一下你如果跳槽到初创公司，可能会在哪些方面不适应？

第二个是，如果你是一个初创公司的产品经理，思考一下你如果跳槽到大公司，会有哪些难题，怎么来解决？

04 | 产品经理和项目经理有什么区别？

产品经理的英文是“Product Manager”，项目经理的英文是“Project Manager”。同样简称为 PM，这让很多人搞不清楚两个岗位间究竟有什么区别。比较大的科技公司通常会同时招收产品经理和项目经理，所以在投递简历的时候，你要区分清楚。

那么，产品经理和项目经理到底有什么区别呢？

产品经理的工作性质是能够带领一个产品团队做出决定，开发出用户想要的产品。 产品经理的成败与否取决于产品的表现，他们可能就加了一个按钮，但这个按钮牵一发而动全身，瞬间增加了百万用户，那这个产品经理也非常成功。产品经理需要在信息有限、大家并不清楚该做什么的情况下，为团队指引方向，让大家明确先做什么、后做什么、为什么要这么做，这也就是大家所说的“路线图”（roadmap）。还有一点就是，产品经理一般会固定在一个产品上， 随着产品的不断发展，不断提升产品体验，增加用户量。

项目经理的工作性质是能够组织团队在有限的时间内按期完成一个非常复杂的项目。 很多科技公司的项目经理其实是在一些底层的技术部门，比如底层架构、数据系统等部门。通常这些部门的项目非常复杂，技术难度非常高，所以需要一个懂技术的人能够把一个很大的项目分成一个个小的部分，分配给最合适的工程师，然后管理各种各样的 task；在某一个工程师被其他工程师拖连的情况下， 能够灵活修改任务分配，确保按期完成。

这样的项目经理，他们的成功标准是能不能按期完成这个复杂的项目。很多时候，策略已经制定完成，想要做什么大家也非常清楚了，这个时候把工作交给项目经理，确保能够按期交付。

JIRA 这样的工作流管理软件，是很多项目经理的好朋友。相比于产品经理的相对稳定性，项目经理经常会负责完全不一样的项目。因为一旦项目按期完成，他们就要迎接新的挑战了。

也有一类项目经理是不管技术性项目的，他们的作用是组织工作的流程。比如说 ，一个 100 人的开发团队，会议应该怎么进行，多久开一次会；或者一个几千人的地推团队，如何建立一个监督机制。

这样的项目经理更像是一个运营经理， 他们的目标是设计一套非常高效的方案，能够让工作快速进行。他们可能还会预估公司下半年应该招多少人，预算是多少等等。

相较于项目经理， 产品经理的工作方法更加多样化。在一个产品从 0 到 1 的阶段，产品经理会把更多的时间花在数据分析、市场调查、用户调查等方面，目的是能够快速制定产品的发展策略。 一旦产品经理确定了产品的方向和发展策略， 他们就会把更多的时间花在任务执行和项目管理上。所以产品经理也得是一个很好的项目经理， 这样才能保证产品的执行快狠准。

那么，产品经理和项目经理是如何合作的呢？

有的时候，一个团队，可能既有产品经理，也有项目经理，这就需要产品经理和项目经理有机合作了。比如，我之前做的一个技术难度比较高的产品，就有一个项目经理和我对接。那么，我们是怎么协作的呢？

我负责确定产品应该解决什么问题，目标客户群体是哪些，有哪些功能，这些功能如何衡量成败与否。 我和用户调查部一起采访用户，提出用户需求，然后和数据部门合作评估市场前景。

然后我根据调研情况，把它转化成产品需求文档，和工程师讨论什么能做，什么不能做。

确定了产品需求之后，我会把其中一些需要项目管理的功能交给项目经理。项目经理拿到我的需求后，会把它转化成一个个 task，然后安排给不同的工程师。

因为要和其他组一起推动这个新功能，我们就需要安排一个和其他组交流本周工作的组会。这个组会需要十几个组共同参与，所以就需要我的项目经理帮助我管理这个会。 每周他会邀请这十几个组的负责人来参加会议，并提前制定好会议进程，提出会议模式，然后负责每周会议组织，会后落实。

各项任务完成，准备发布。这个时候我和市场营销部门一起制定产品发布计划和策略，确定应该和哪些媒体通报我们的新产品，并争取让他们报道这个新产品。

顺利发布产品，用户一开始非常有兴趣，但是很快他们都流失了。

作为产品经理， 我需要和数据科学家们找到问题所在，和设计师一起提升产品的用户体验。这时，我会制定一些新的产品功能修改需求。

项目经理帮我推动这些新功能的执行。

以上，就是一个我和项目经理一起合作完成产品的案例。 当然大部分时候， 并没有一个专职的项目经理跟我对接， 这个时候就需要我自己身兼数职，在制定产品策略的同时也负责项目管理的工作。所以很多时候和项目经理的合作，能让我把更多的时间花在制定产品策略、做出产品决策上，这其实是我的荣幸。

总结

今天的这篇文章我主要讲解了产品经理和项目经理之间的区别。

产品经理的工作性质是能够带领一个产品的团队做出决定，开发出用户想要的产品， 这包含了产品的策略、功能设定以及执行。项目经理的工作性质是能够组织团队在有限的时间内，按期完成一个非常复杂的项目。在策略已经制定完成、想要做什么已经确定的情况下，需要项目经理把一个很大的项目分成一个个小的部分，分配给不同的工程师，能够管理各种各样的 task。

产品经理和项目经理在某些团队可能同时存在。这个时候，产品经理更多的责任是要弄清楚应该做什么，项目经理负责确保我们按时间做好。如果两者的合作非常融洽， 产品经理会有更多的时间制定产品策略。

思考题

最后，给你留一个思考题。产品经理和项目经理，你更倾向于做哪个呢？

05 | 硅谷产品经理每天在做什么？

前面的文章我讲了产品经理的工作性质和内容，但是还有一个非常重要的话题，就是：产品经理的一天是什么样子的。

有人说产品经理每天就是和工程师互撕，也有人说产品经理每天各种开会，还有人说产品经理每天就是坐在电脑前画画 UI。作为一个在硅谷工作多年的产品经理，我每天的日程其实都在变化。 下面我就通过一个真实的案例，详细说说产品经理的每一天是怎么度过的。

案例背景： 发布新版视频版权管理系统

我们要发布一个最新版的视频版权管理系统，目标群体是视频制作者， 包括传媒公司、音乐公司、电视台等。在 Facebook 上有大量用户的视频，我们需要确保视频制作者的版权内容不受侵害，并及时处理掉侵权内容。

我们的第一版产品，可以帮助视频制作者非常轻松地管理自己的版权内容，在 Facebook 上为他们寻找侵犯自己版权的内容。现在，我们需要确定下一个版本应该有什么新的功能。所以我花了大量的时间，和用户进行一对一的讨论，和市场营销经理一起做市场调研，同时和数据科学家一起仔细研究已有用户的特点。这个阶段， 一般会持续两到三个星期， 最终的结果是制定一个详细、具体的产品功能需求列表，并且弄清楚每一个需求的优先级。

我们通过一系列的市场调研和用户调研发现，第一版的产品虽然可以帮助视频制作者找到使用他们版权内容的视频，但还是需要他们手动找出哪些视频是已经购买了版权的人发的，哪些视频是侵权用户发的。然后，他们要将这些侵权视频报告给 Facebook，Facebook 才能删除。这个过程对于那些小的视频制作者来讲还比较轻松，但是那些大的媒体公司会有数以千计的侵权视频，所以手动报告对他们来讲是非常痛苦的。

其实，我们还发现了一些其他问题，比如第一版的产品只能在电脑上使用，而不能在手机上便捷地处理，这对于每天奔波在录影路上或者片场的独立视频制作人来讲很不友好。但是，这个问题与手动低效的问题相比，对用户的影响要小得多。毕竟，这个版权管理系统的用户大多来自中大型的视频制作公司，帮助他们通过最聪明的方式报告侵权视频非常重要。因此，我们决定第二版的产品主要解决这个问题。

产品经理在开发初期的日程

2 月 15 日

10:00 用户调研
12:00 团队“头脑风暴”产品功能
13:00 午饭
13:30 和其他组产品经理谈合作
14:30 和工程经理讨论产品的成功指标怎么确定
15:00 思考时间：思考一下如何整合用户调研的结果
17:00 和营销经理讨论一下市场调研的情况
18:00 晚饭
19:00 下班时间， 但是要回复一堆邮件和工作信息

这天早上，我首先完成了最后一个用户调查，其实我们已经通过之前的调查发现了手动低效这个问题是最大的痛点，所以今天的用户调查是通过采访一个中型媒体公司来确认我们的发现。

然后我就和工程师一起讨论， 有什么方式能够解决这个问题，这就是 12 点到 1 点的会。在会议开始前我需要做一些准备工作，布置好场地，提前准备好“头脑风暴”流程。

因为我们现在所想的功能需要使用另一个产品的一些功能，所以我需要和这个组的产品经理讨论怎么能够利用他们已有的资源。

之后，我马不停蹄地去了成功指标的会，讨论怎么才算解决了手动低效这个问题。 最后我们一致决定， 判断是不是能够提高效率的方式就是，对比视频制作者在有这个功能之前和现在每天举报视频的数量。如果能够提升 10% 就算成功，否则就需要修改一些产品功能，来提升这个数字。

然后我花了很多时间在思考，把前几天做的用户调研以及和大家“头脑风暴”的内容进行整合，撰写产品需求文档。对我来说每天能有属于自己的时间非常不容易，但是我只有在这样的时间里才能真正思考，所以我非常珍惜这两个小时。

最后一个会，主要是看营销经理给我的市场调查报告，然后我发现市场调查的结果和用户调研的结果非常相似，并且一个竞争对手已经有了类似的功能。

产品经理在开发末期的日程

4 月 20 日

10:00 Stand-Up 会议，也就是“站立会议”
10:30 和设计师一对一
11:00 和工程师、设计师一起决定方案
11:30 和老板一对一
12:00 和新来的同事吃午饭，介绍我们组的情况
13:30 部门产品经理组会
14:00 自由时间，和几个工程师分别讨论他们遇到的问题，帮他们和其他组沟通
15:00 讨论几个产品小功能的优先级
16:00 面试产品经理
17:00 讨论营销公关策略

这时离我们预定 5 月 5 日进行产品发布的时间已经非常近了，所以最重要的开发部分其实已经完成。 但是上周， 其中一个工程师发现已有的架构无法实现设计师的这个功能，所以需要设计师用我们能够支持的方式，修改之前的设计，这就有可能增加开发时间，发布时间有可能被拖到 5 月 8 日。

在这个背景下，4 月 20 日，我先参加了工程师的站立会议。因为我们正处在最紧张的开发阶段，所以每天早上所有工程师、工程经理和产品经理都会在一起，交流昨天完成了什么， 今天要做什么。目的是激励大家高效工作，同时也可以及时发现工程师的开发难点，并当天解决。这样的站立会议，一般都是在早晨大家开始工作的第一时间进行。

我今天最重要的任务是，帮助设计师修改产品设计方案，从而解决我们现在的架构限制问题。我先和设计师两个人坐在白板前思考有几种方案，每种方案有什么优缺点。然后，11 点，我、设计师、工程师坐在一起商量，决定哪一种方案能在最短的时间内完成。

之后，我和老板每周的单聊时间开始了。我需要和他讲讲最新的进展，有什么需要他帮助我的，有什么是风险较高的内容。一般对于比较重要的决定，我会拉他来一起参加会议。这次设计师方案修改的问题，我们自己已经做好了决定， 所以我就和老板简单地说了一下，他表示赞同。

其实产品经理还有一个重要的任务，就是帮助团队招人。我现在需要招聘两个工程师，所以我的午饭是和一个刚来公司不久正在选组的工程师吃的，目的就是了解他的情况，向他推荐我们组。一般这种对话，产品经理需要讲讲未来的策略和愿景，让新人愿意加入，并且觉得有很大的发挥空间。

下午一点半，是我们整个部门的产品经理要一起开的例会。例会一周开一次，整个部门 20 多个产品经理都要参加。具体内容是，分管我们部门的副总裁和大家讲讲公司上层近期的想法和决定；邀请其他部门的高管来讲讲他们的计划，看看有什么可以合作的；如果有什么新产品发布，负责的产品经理会和大家介绍一下。

之后我有一些自由时间，一般会找到具体的工程师，到他们的办公桌前，问问他们有什么需要我帮忙的，现在有什么风险高的问题还没有解决。我发现，这样的形式比动辄开会要高效很多。所以，如果不是需要每个人坐在一起解决的问题或决定， 我一般都会采取这种方式快速解决。

3 点我要和技术主管、工程经理一起讨论一下现在还没有完成的 5 个小功能里面，需不需要砍掉几个功能。因为发布时间近在咫尺，我们具体分析了功能的优先级。我跟大家说了说我的想法， 大家表示赞同，速战速决。最终，我们决定砍掉 2 个功能，保留剩下的 3 个。

4 点我面试了一个产品经理。因为是第一轮，所以是视频面试，主要考察他的分析能力。这个面试进行了 45 分钟，我觉得他表现一般，按能力进不了最后一轮。

5 点的这个会是临时加的，因为 5 月 5 日发布的可能性不大，所以我们想讨论一下推迟发布的事情。我现在的想法是 5 月 8 日发布，但是营销经理说他刚刚了解到，我们部门的另一个产品也要 5 月 8 日发布。如果一起发布，就需要找到一个共同的主题；否则，最后发生冲突，就会丧失宣传的好机会。所以如果不能和他们一起，他推荐我们 5 月 10 日发布。

总结

通过上面的这个真实案例，你应该可以发现以下几点。

产品经理的工作内容取决于产品发布的阶段。

开发初期，产品经理需要花更多的时间在思考上。这个阶段主要弄清楚要做什么， 所以需要花大量时间做调研、策略以及制定产品功能需求。这时和工程师交流的时间比较少，更多的是和调研、市场的同事们一起。
开发最紧张的阶段， 产品经理需要花更多时间在执行上。这个阶段需要花大量时间解决开发难点，根据困难和挑战修改之前提出的方案，并且和营销部门讨论开发的策略。

产品经理每天要开许多会，和各种人交流，目的是统一思想、快速做出决定、了解产品发布的挑战并加以解决。不同形式的会议侧重不一样，目的都是促进产品的高效开发。

站立会议让工程师们快速交流昨天完成的和今天要做的事，及时发现开发的问题并马上解决。
部门的产品经理会可以交流最新的信息，帮助产品经理从其他人身上学习经验并及时了解高层的想法。
优先级讨论会让大家讨论亟待开发的几个功能，砍掉优先级低的功能。到了开发末期，往往要面对各种挑战，需要权衡趋势，砍掉一些无关紧要的小功能，因此这样的会议经常进行。

思考题

最后，给你留一个思考题。你现在所处的团队处在产品的什么阶段？如果你是产品经理，你的日程表和我的相似吗？如果你不是产品经理，你的产品经理现在是怎么做的？

06 | 硅谷产品经理们都来自什么背景？

对于什么背景的人最适合做产品经理，一直是众说纷纭。有的说没当过工程师的“戏精”不是好的产品经理；有的说产品经理谁都可以干，只要能吹牛互撕就行了；也有的说最好的产品经理从来都是“奇怪”的人，比如贝索斯以前是高频交易的明星员工、乔布斯是个写书法的隐士等等。

今天的这篇文章，我就给大家具体讲讲硅谷的产品经理都是什么背景，以及 HR 在看你的简历时都在看些什么。

产品经理的简历背景

硅谷的公司众多，产品之间相差悬殊，公司文化更是风格迥异。下面纯粹是我的个人体验，数据不一定有代表性。

Atlassian、MongoDB 和 Docker 这种公司，用户以程序员为主，所以产品经理都要求有技术背景。如果产品经理自己都没有当过程序员，怎么好意思给其他程序员设计产品。 这里所说的技术背景，不仅仅是要求计算机专业，而且一定要真正做过程序员才算数。

Amazon，很多产品经理都是 MBA。他们 MBA 毕业后参加专门针对 MBA 毕业生的产品经理进阶项目，项目毕业后直接就是高级产品经理，最终成为产品高管。

Google，工程师文化浓厚，产品经理面试要写代码，所以一般都是计算机或者电子工程科班毕业。特别是如果你想申请 Google 的 APM（针对应届毕业生的产品经理项目），必须得是计算机专业的，而且必须得通过 Google 的代码面试。

Instagram，产品经理都是文艺范，黑白灰、爱摄影、时尚有品味。有很多人以前是在纽约做艺术、媒体之类的工作，从打扮就可以看出来他们每天都活在 Instagram 大片里。也有很多人以前是创业公司的 CEO，公司被收购或者垮掉后来到 Instagram 做产品经理。

Apple，产品经理分硬件和软件组。管理硬件功能和开发流程的叫作 Program Manager（硬件项目经理），一般是电子工程背景。管理软件的直接就是产品经理，他们有个别是 MBA 毕业的，大部分还是技术背景。

Snapchat，分产品设计师和产品经理。初期的时候，最有实权的是产品设计师，一般是由一群斯坦福、哈佛毕业的聪明绝顶、特有态度的年轻的天之骄子担当，他们很多是 CEO 的好朋友。Snapchat 现在也招收了很多产品经理，这些人大多来自业界的大公司，背景比较多样了，广告和传媒领域有不少。

Facebook，产品经理数量众多，对背景并没有一个特定的要求。有很多产品经理是文科专业、咨询公司、记者毕业，也有天体物理博士、投资银行交易员、音乐家、创业走上人生巅峰老婆说别折腾了的，背景广泛。不同背景的产品经里一般会去不同的产品线工作， 例如，广告部门的产品经理一般都是有过广告产品经验，属于技术性的人才；媒体部门的产品经理，比如视频和新闻等板块，大部分是娱乐、新闻产业有行业背景的产品经理或者前媒体人转行。

Uber、Lyft，特别喜欢从 Facebook、Google、LinkedIn 挖人。前一段时间，Uber 丑闻遍地、Lyft 成了硅谷新宠，这些曝光度也给它们吸引了大批经验丰富的产品经理。

以上对硅谷产品经理背景的汇总介绍目的是要告诉你，硅谷对产品经理的背景并没有一个特定的要求，所以并没有一个成为产品经理必须的专业或者工作背景。 对于一个产品新人来说，首先找到自己的优势，然后再利用自己之前的背景，才是最好的方式。

产品经理的软实力背景

简历、专业以及工作背景并不完全是衡量一个产品经理优劣的标准，软实力才是更重要的。软实力很多时候是通过以前的经历体现的，不仅仅是以前的工作经历，还包括在学校里得到的锻炼、平时参加的社会活动等。

在我看来，一个产品经理的软实力往往体现在以下四个方面。

领导能力： 一个好的产品经理能够领导一个团队， 可以让团队里的每个人都能发挥自己的优势， 能团结不同兴趣、不同性格以及不同利益的人。 这样的技能，可以通过学生时代的领导经验、就职于其他行业或者岗位的团队领导经验、业余活动或者参加的社会组织，甚至是创业经历来体现。
所以，对于没有做过产品经理的人，HR 一般会看之前有没有领导团队的经验；对于做过产品经理的人，HR 一般会问你领导团队的心得，来衡量你的领导能力。

沟通能力： 一个高效的产品经理应该能够进行高效的沟通，和老板以及公司高层的沟通、和其他团队的沟通、和团队成员的沟通，在团队遇到困难的时候如何激励大家，在团队成员出现矛盾的时候如何解决争端，怎么沟通坏消息等等。这些能力也是通过以前的学习和工作经验来体现的， 和具体的专业无关。所以，如果是初入产品经理行业，不妨思考一下如何在简历上体现这方面的经验。

创新精神： 优秀的产品经理虽然来自于不同的背景， 但都富有创造力和创新精神。他们有自己的专利、写诗写歌，或者是在之前的工作中提出了不一样的工作方式为公司增加了价值等等。这些经历都是体现创新能力的证据，所以在招聘的时候 HR 会非常在乎产品经理之前是否有体现创造能力的经历。

勇往直前的执行力： 在万事俱备的情况下做成事情并没有什么难度，几乎每个产品经理都需要在资源非常有限、时间很紧张的情况下力挽狂澜、勇往直前。 所以，产品经理需要具备非常强的执行力。
其实执行力可以体现在生活的方方面面，有的人立志减肥，三个月之后真的瘦下来了；有的人从零开始锻炼，参加了多次马拉松；还有的人，在之前做兼职的销售，面对一堆人的拒绝没有气馁，最终取得了优秀的销售成绩。这些都是执行力的体现。
很多优秀的产品经理虽然不是科班出身，但是具备指哪打哪的超强执行力，所以脱颖而出。

总结

今天这篇文章讲了硅谷产品经理的背景， 介绍了硅谷的不同公司对产品经理的职业背景、工作经验、学术背景的要求。

随后，我还介绍了的产品经理应该具备的软实力，包括领导能力、沟通能力、创新精神和执行力。 而软实力的重要程度绝对不亚于学术背景以及工作经验， 有很多产品经理并不是科班出身，但是因为具备了非常强的软实力，所以在产品经理的岗位上脱颖而出。

思考题

思考一下你的经历和背景，有哪些可以体现你领导能力、沟通能力、创新、执行力的实例呢？

07 | 如何寻找用户需求？

产品经理每天最常说的词是什么？那必须是用户需求啊。

一个产品存在的意义就是，能够帮助用户解决一个之前无法解决的问题， 或者提供一个比之前的解决方法要强 10、100 倍的解决方案。所以如果这个产品无法解决用户需求， 那么这个产品根本没有存在的意义， 这也就是为什么用户需求是产品开发最重要的部分。

什么是用户需求

用户需求，是大家每天最常说的词，也是误区最多的词。 一个最大的问题就是，产品经理写了几十页的用户需求文档，挂了各种各样精彩绝妙的韦恩图、曲线图、UI 图，结果却发现这个产品解决的痛点实际上根本就不存在。

用户需求一定要立足于用户，一定要验证这个痛点到底是不是真的存在。

平衡车（Segway）就是一个例子。这种靠电力驱动、具有自我平衡能力的交通工具，刚出现的时候惊为天人， 各种投资人、发明家都为这样的绝妙设计而感到震撼，但是这个被寄予厚望的发明却并没有顺利落地。平衡车需要经常充电，而且售价非常昂贵。长途、上下班开车最方便，而几公里的路程还是用更便宜更方便的自行车比较好。平衡车解决的问题，并不是一个广大用户真正存在的痛点，这也就是为什么发明了十几年之后，仍然只能在高档宾馆，或者花园景点里见到踪迹。

现在如火如荼的各种区块链、人工智能项目，也是这样的例子。娱乐界的人工智能、网红圈的区块链层出不穷等等，很多这样的项目，都强行用新技术来套用某个领域或者某个应用场景， 而没有去验证用户是不是真正有这样的痛点； 或者用户的痛点是不是足够大到让他们丢弃已有的习惯，使用一个新的产品、适应一个新的方式； 或者这个产品加上人工智能之后，是不是真正解决了一个以前解决不了的痛点。

所以，一个好的产品经理一定会先从痛点出发，确认用户是否真正存在这样的一个问题。 其实最终发布的产品和一开始的版本差的非常多，所以一开始就指望得出正确的产品结论显然是不现实的，在设计产品时还是应该先立足用户的问题，后续再通过不同版本的修正，从而更好地解决用户问题。

寻找用户需求的途径

寻找用户需求，需要做以下几点。

第一，确认好你的目标用户是谁。

一个给老年人设计的听音乐的产品和一个给 00 后设计的听音乐的产品肯定会完全不一样，因为老年人的痛点和 00 后的需求差得非常远。Facebook 刚刚创立的时候，首先定位在扎克伯格所在的哈佛大学，后来拓展到所有大学生，然后拓展到所有人。所以，在产品刚开始的时候，专注于特定某一类的用户群体才能让产品的设计更有针对性。

第二，通过数据分析和用户调查，作出关于用户痛点的假设。

当你要解决的问题已经有了一些解决方案，或者用户的基数足够大可以找到量化的数据时，可以先从数据出发，这时你可以看看行业的年报数据，或者搜索一下相关的调查研究以及市场研究。如果你的产品已经有了一些用户数据，那就要先从自己本身的用户出发。

另一个方式是通过用户调查了解问题，作出假设，具体方法我会在下一个板块详细讲解。

比如当你发现，快时尚公司的销售额最近在连年下滑，你的假设可能有以下几个：

快时尚公司的设计没有跟上形势；

用户的消费标准越来越高，越来越看不上低质量的产品；

用户花在时尚上的钱越来越少。

所以，这个时候你根据数据或者用户行为提出了一些假设，这就为你下一步做更加精准的数据分析和用户调查奠定了基础，让你大致知道下一步的调研活动应该怎么开展。

第三，进一步挖掘数据和用户反馈，验证用户痛点的存在。

比如已经有了上面的 3 个假设， 那怎么知道哪个才是真正的问题呢？或者这 3 个都不是呢。这个时候，就需要你进一步的了解数据了。

快时尚公司的设计真的没有跟上形势吗？你可以看看快时尚公司完成模仿知名时尚品牌所花的时间是不是比以前更多了。

用户在时尚的总投入增长了还是下降了？如果是没有下降的话， 那么他们单品消费的价格有没有变化呢？

另一方面，你也可以通过用户调查来验证假设，可以采访客户问问他们上一次购物是在什么地方、花了多少钱、对快时尚品牌的印象有没有变化等等，从而以最快的速度来验证你之前的假设。这一步的目的，是为了以最快的速度明确用户的痛点到底是什么，是什么原因导致的。

关于用户调查

用户调查分很多类，这取决于你要研究的问题是什么。

当你有一个大概的假设，知道用户痛点大致在什么领域，但是并不清楚具体有哪些选择，需要非常系统地深入了解具体的痛点，这个时候和用户一对一的面谈效果最好。

比如说，我已经知道微信公众号的模版不够灵活，是一个非常大的痛点。通过用户面谈，我可以了解清楚到底是哪一部分需要更加灵活。是需要更多模板？还是需要允许用户每天多发几篇文章？还是需要允许用户发更长一点的视频？

通过对用户提出问题，根据他们对问题的回答进一步提问，你可以更加清晰地知道痛点在哪里，了解在什么样的情况下痛点存在，什么情况下痛点不存在。

一对一面谈需要注意两个问题：

1. 用户样本选择要具有代表性，比如你明明想知道女性群体使用抖音的痛点，但是面谈只采访 20 岁以下的群体，那这样的样本并不具备代表性；

2. 要意识到一对一面谈的局限性： 一般采访的人数不会特别多，所以不要认为某一个用户说的某一句话就一定是真理，这就需要多找几个例子，看看这个点是不是广泛存在。

另一个常见的方式就是问卷调查。 这种情况适用于你已经有一个比较成熟的假设，有几个选项，想知道用户怎么想。 比如，我已经知道了微信公众号不灵活，我估计有模版的问题、有视频长度的问题，但是不知道哪个更重要。这个时候，通过问卷调查和统计技巧，我可以广泛采样，了解清楚在目标群体中，哪个选项的痛点更大。

当然，你也可以使用问卷调查的方式进行采访。比如，你可以在问卷中增加一个空白区域，让用户随便写。但是，在这种方式下用户可能会非常发散，得出的结论往往不够系统和专注，所以你需要引导用户在某个固定的领域进行发挥，或者在恰当的时候给用户加以限制，让他们做出一定的选择。

总结

今天这篇文章我详细讲解了用户需求对于产品经理的意义，以及如何寻找用户需求。

首先，我总结了为什么用户需求非常重要。 我以平衡车为例告诉你，产品要解决一个真正存在的用户痛点，所以产品应该从了解用户痛点出发，而不是一上来就得出产品应该长什么样子、有什么功能的结论。

然后，我讲解了寻找用户需求可以分为三步，明确用户群体、做出用户痛点假设、验证你的假设。

最后， 我介绍了一对一面谈和用户问卷调查这两种不同的用户调研方式。这是两个常见的用户调查的方式，适用于不同的场景，以不同的方式帮你做决定。

思考题

如果让你设计一个帮助上班族看新闻的产品，你会通过哪些方式来了解用户需求呢 ？你有哪些关于痛点的假设呢？

08 | 目标客户和用户画像

上一讲我分享了如何寻找用户需求，那么今天这篇文章我就来讲讲如何定义目标客户和用户画像。

首先，我先说明一下什么是目标客户，以及怎么确定目标客户。

确定目标客户

目标客户就是你的产品要针对的客户群体。一般在你刚刚开始探索产品路线的时候，目标客户可能不会太明确。比如说，你想给有相同兴趣的人做一款找朋友的 APP，此时尚未明确到底是要给什么人群做 APP。确定目标客户，就是要弄清楚到底怎么划分用户群体， 然后截取哪部分用户作为目标客户。

简单地说，弄清楚目标客户，就是一个先拓展（思考所有可能的目标客户）再专注（找到更有针对性的目标客户）的过程。

先拓展，就是要列出会对产品有需求的所有人，并尽可能地细分。再专注，就是要专注于最需要这个产品的人群，即使这个人群规模很小，但是：能 100% 解决这一小部分人的需求，远胜于只能解决一大群人 50% 的需求。

这里一定要注意，专注于小群体，并不会让你的产品丧失发展潜力。 相反地，当你非常好地解决了这一小部分人的需求后，他们会成为产品的粉丝，自然而然地自发地宣传这个产品，从而让其他用户也跃跃欲试。

事实上，一些非常知名并且取得了很大成功的公司，正是这样做的。比如，Facebook 一开始专注于大学生群体， 后来才拓展到所有人。再比如，Airbnb 一开始专注于沙发客，后来拓展到了时代旅馆、度假社区等内容，现在还推出了 Airbnb Experiences，专注于组织活动和体验。

Facebook 和 Airbnb 的成功也告诉我们，只有先解决好了某一类人的需求，让你的产品成为解决这类人需求的最好方式，然后才能再拓展到更多的人，让产品逐渐成为更多用户的选择。所以，初版产品一定不是一开始就定位在“所有人”上，先专注于某一类人，这样才会更有成效。

其实在确定目标客户时，人们往往陷入两个误区。

对目标客户群体的定位不够有针对性。比如，我在《硅谷产品经理每天在做什么？》这篇文章里讲到的视频版权管理系统。从整体数据来看，用户活跃度很高，但是仔细研究就会发现是媒体公司的活跃度提升了整个数据。在这个系统上，媒体公司的侵权视频有很多，但他们有专人负责处理这些侵权视频，所以媒体公司的处理效率非常高。相比而言，名人和小艺术家就没有那么多时间处理侵权视频了，因此处理侵权视频的效率就比较低。
因为大部分视频侵犯的是媒体公司的版权，所以整体数据很漂亮，这也让我们误以为这个产品很给力。但实际上，我们这个产品之前的功能只是适用于媒体公司而已，而并不适用于小艺术家。但我们之前定位的目标客户是所有发视频的人，因此设计了一堆对媒体公司来说太低级、小艺术家又没时间用的功能，所以产品发布之后效果并不好。

没有研究清楚目标群体最底层的需求是什么，或者说没有清楚地认识到产品到底要解决的底层需求是什么。
我通过一个成功的例子来说一下认识到底层需求的重要性。美国的健身品牌 SoulCycle 成立于 2006 年，一开始只是在曼哈顿上西区有一家规模很小的工作室、有几十辆单车，但很快就拥有了一群女粉丝，她们每周都要来好几次。
你可能会简单地认为 SoulCycle 的目标群体就是喜爱单车、要锻炼身体的人士，而且目标群体的规模也还好。实际上，虽然 SoulCycle 提供的是单车课，却有着夜店般的音乐、激励人心的教练，和一个团结互助的同好群体。因此这个单车课成了很多人解压、展示自己积极心态、打鸡血的地方。
这才是这个健身课真正要满足的用户需求，所以 SoulCycle 的目标群体不仅仅是爱锻炼的人，也包含了希望表达自我、战胜自己，和激励自己的人。这就是为什么，很多从来不健身、不玩单车的人也深深爱上了 SoulCycle。
在 SoulCycle 上市的公开募股书中，不乏“你的灵魂至关重要”和“我们渴望去激励人群”这样的表述，这来源于他们对于目标群体的精准把控和精准的产品定位。有一本书叫作《定位》，是 20 年前美国《广告时代》杂志邀请年轻的营销专家杰克 · 特劳特和艾 · 里斯联合写作的，有兴趣的话你也可以读一读。

描绘用户画像

用户画像对应的英文是 user story，或者 user profile，意思就是：生动描绘用户的特点，把这类用户抽象成一个人，然后用介绍这个人的方式来描绘这一类人。也就是说，要找到一些符合目标特点的潜在用户进行调研，然后生动描述调研用户的特点。

比如，你想先专注于运动兴趣，初版产品的目的是帮助有运动爱好的朋友们找到同好，更好地社交。那么，你需要找到这类用户，对他们的特点进行调研，然后进行用户画像。下面我说两个例子，能过这两个具体的用户画像，你可以体会一下它们如何形象地展现了产品将要针对的具体用户。

约翰是一个目标客户，他 25 岁，酷爱跑步，经常参加马拉松，每周都会跑步三四次。他经常和朋友一起跑步，喜欢买跑鞋、透气性较好的衣服，关注 Instagram 的马拉松运动达人。他最希望得到的是跑步的训练课程、贴士以及准备马拉松比赛的营养和饮食建议。

卡罗琳今年 38 岁，她有三个孩子，喜欢自行车运动。她每天上下班都骑自行车进行锻炼，周末偶尔会和朋友们一起参加 30 公里左右的山地骑行活动， 喜欢买一些适合山地骑行运动的紧身裤。她希望能够关注专业的骑行达人，看看他们有什么关于训练和装备的建议。

在我看来，用户画像主要有两方面优点。

帮助你更生动地描绘用户特点，有利于你和团队成员进行交流，帮助你解释产品的功能以及如何解决这些人的需求。

帮助你更深入地了解用户，考虑这个用户的生活方式、爱好、性格特点等，从而让你可以从更高的视角观察用户、了解用户，而不是在这个阶段过度纠结于某个小细节。

用户问题说明

在前面的内容，我分享了如何寻找用户需求、怎么确定目标客户和用户画像，那接下来讲讲什么是用户问题说明。

用户问题说明就是一句话，这句话能精炼、简单地描述你到底要为什么用户解决什么问题。

用户问题说明的常见形式为：作为 XX（什么样的用户），我想做 XX（什么事情），从而帮助我 XXXX（达到什么目的）。

这句话中的“作为 XX”： 是说目标用户。

这句话中的“我想做 XX”： 说的是用户需求。这里需要注意的非常重要的一点是，要以用户为第一人称表达，而不是以产品能够解决的问题为主语表达。
不是说“微信能够帮助你和好久不见的朋友沟通”，而应该是“我想和好久不见的朋友沟通”。别看就是几个字的差别，但是前者并不代表用户有这样的需求，而后者却是源自于用户本身的需求。这一点我是通过市场和用户调研验证得出的。

这句话最后的“帮助我 XXXX”： 是说对产品功能的预期。之所以“帮助我 XXXX”在“我想做 XX”之后，是想说明产品功能一定要解决用户真实存在的问题，也就是“我想做 XX”的这个问题。如果“我想做 XX”是不一样的，那么就决定了“帮助我 XXXX”肯定也会不一样。
比如，作为一个热爱运动的人，我想了解运动爱好知识、向运动达人学习，从而帮助我提升在这个项目上的水平。又或者，作为一个热爱运动的人，我想了解运动爱好知识、了解其他运动达人，从而帮助我结交更多有相同爱好的朋友。
这两个例子要解决的问题完全不一样， 一个是帮助我提升自己的水平，一个是帮助我结交同好，因此对产品功能的预期也不一样。

在 Facebook，我们经常要求新加入的产品经理能够用“用户问题说明”这句话，简明扼要地表达清楚产品功能，如果总结不出来，那就说明这个产品经理对用户需求和目标用户定位不够清晰。

总结

今天我主要讲述了目标客户和用户画像。

目标客户就是你的产品针对的客户群体， 需要你先拓展（思考所有可能的目标客户）再专注（找到更加有针对性的目标客户）。

用户画像就是生动描绘用户的特点，把这类用户抽象成一个人，然后用介绍这个人的方式来描绘这类人。

通过确定用户需求、目标客户和用户画像，我们可以得到一句非常清晰的表述，即用户问题说明，从而真正弄清楚到底要“为什么用户解决什么问题”。

思考题

今天的思考题是，希望你能够通过一些用户调查，来明确目标客户和用户画像是什么。如果你是【极客时间】APP 的产品经理，你的目标客户和用户画像是什么呢？欢迎给我留言。

09 | 手把手教你写用例： 优化微信加好友的功能

如果你在科技公司工作，那么你一定对“use case”这个词语不陌生。

“use case” 中文是“用例”，维基百科的解释是“软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术”。这个解释有点难懂，简单来说，用例就是描述在什么场景下用户用产品来做什么事儿。

各种各样的产品经理文章对于用例的解释说法不一，推荐使用的用例格式也有很多种，其实用例的具体格式需要根据具体的产品场景和公司文化来确定。但是，需要注意用例的目的是清晰沟通这个产品到底需要解决哪几个问题，具体是怎么解决的，以及用户为了解决这个问题需要做哪些操作。

用例可以用文字来表示，也可以用图表或者流程图来表示，能让设计师和工程师以及产品团队的其他人员清楚、准确地理解，才是最重要的，而不是要一定遵循某个固定的格式。

所以这篇文章， 我并不是要告诉你用例应该采取某一个固定的格式，也并不是要让你按照我的格式来，更不是要让你记住一些抽象的概念，比如用例具体的定义，而是要告诉你在明确了目标群体、 需要解决的用户问题的情况下，如何把解决方案清晰地从用户的角度表达清楚。

列出加好友的用例

我举个具体的例子，来跟你解释一下到底什么是用例。假如你是微信的产品经理，你现在需要优化加好友的功能，用例可能会这么写：

首先，添加好友是双向的，彼此都成为了对方的好友。

其次，添加好友有不同的途径：

第一， 通过用户名添加；
第二， 通过其他朋友分享的名片添加；
第三， 通过扫描二维码添加；
第四， 在群成员中找到该用户，点击进入这个用户的主页，从而添加好友。

以上四个用例适用于一个用户想添加另一个用户。

除此之外，还会出现一个用户想同时添加一群人的情况，比如你在同学聚会的时候想添加所有同学等，这时添加好友的途径有：

第五， 找到距离很近的其他用户，同时添加所有在这个距离之内的朋友；
第六， 同时输入相同的密码自动加入同一个群，从而在群中一个个地添加好友。

现在已经清楚罗列了所有添加好友的途径，但是这还远远不够，接下来你需要写清楚用例的条件、操作步骤和产品框架。

1. 什么情况下能开启这个功能呢？

只要用户登录了微信，在任何情况下都可以开启前四个方式。虽然这四种方式都可以帮助用户添加不在身边的人为好友，但是第 1 种和第 3 种更适用于面对面添加好友的情况。

虽然用户在任何情况下都可以开启第 5 种和第 6 种方式，但是如果没有一群人在身边，这个功能就有些小题大做了，所以这两种方式适用的场景还是一群人在一起面对面地添加好友。

2. 执行完这个操作以后，用户得到了什么呢？

用户添加对方作为好友是一个双向的过程，从此以后，你就可以查看对方的朋友圈、给对方发消息、把对方加到某一个群里。

3. 考虑一下，如何清晰地表述这个用例怎么利用已经存在的产品架构。 说白了就是，哪些部分是用户已经熟悉的、哪些部分是新的，这个问题一般适用于在已有产品上添加新功能的情况。

假设前四个用例在上一版产品中已经发布了，现在需要增加第 5 个和第 6 个用例。你首先应该弄清楚新加这两个功能， 到底有哪些部分可以共用以前的四个功能，哪些部分是需要新增加功能的。

比如说，进入添加好友的功能，即“入口点”（entry point），也就是说到底怎么开启这个功能呢？其实，新增加的第 5 个和第 6 个用例和前 4 个用例添加好友功能的开启方式都是一样的：点击“+”，然后点击“添加好友”，最后选择具体的添加方式。只不过，现在需要在这个菜单里面新增加两个选项而已。

而在这之后的功能就是新的了。前四种用例更多的是搜索和匹配，但是现在需要能让用户进行快速添加。

这个新功能的实现其实是利用了地理位置，并假设相同地理位置的用户多半是在一起聚会的。如果此时此刻这些人同时点击了“添加好友”，并且都在一个非常相近的地理位置，就可以把他们的用户名都显示出来，以方便大家添加。

找到要添加的用户名，就可以点击进入他的介绍页面，有头像、用户名、一句话的介绍，以及“添加到通讯录”的选项，其实这些功能和前四种方式是一模一样的。

在你弄清楚了哪些功能是可以共用的、哪些是需要新增加的后，就要呈现给团队的其他成员了。虽然流程图可以比较清楚地表达这些内容，但是我个人的建议是，不要过于追求复杂的图表，把大量时间花在做图上，而应该思考你表述用例的方式是不是最准确、最清晰的。

用例具体化

现在你已经列出了能够添加好友的所有途径，但是要把它转化为工程师和设计师能够进行操作的文档，还需要描述得更清楚，这时就需要把用例“具体化”。

比如说，第一个用例的具体流程是这样的：

用户点击“+” → “添加好友” → 会有个文本框让用户输入用户名 → 开启搜索 → 必须在用户名完全吻合的情况下，才能显示目标用户名 → 点击进入想要添加的用户的页面 → 点击“添加到通讯录”。

这种方式把一步一步的工作流描述得非常清楚，这其实和产品需求文档上的内容非常相似了。然而，并不是所有产品都可以用这样的方式表达，这种表达方式适用于产品已经有了很多成熟框架的情况。

比如在这个例子中， 你已经有了进入“添加好友”这个选项的工作流、显示好友搜索的逻辑，以及“添加到通讯录”这个选项。

对于一些还不存在已有框架的新产品来说，流程图看上去可能是这样的：

用户进入添加好友的页面 → 页面有一个可以搜索用户名的地方 → 显示搜索结果，但是为了避免加错人，需要有一些预防加错人的机制 → 添加目标用户。

这样可以把产品功能实现所需要的组成部分先说清楚，然后再详细思考一个个组成部分应该怎么设计。比如，用户如何进入添加好友的页面、如何避免用户加错人。你只有把这些问题思考清楚了，才能把产品需求写清楚，工程师和设计团队才可以真正开始实施。

再跟你分享一下，我在 Facebook 做产品经理的切身体验。我们产品的搜索、添加好友的功能与此类似，也更复杂一些，还涉及到了用户信息显示、隐私设置等问题。从这些具体的案例中不难看出，看似简单的添加好友的功能，会影响几十个不同的产品、上百个工程师，以及非常多的场景，因此把用例写得足够清楚是非常重要的。

总结

简单地说，用例就是描述在什么场景下用户用产品来做什么事儿，其目的是要清晰地、有条理地和工程师、设计师团队进行交流。因此，用例需要列出产品所有的情况，以及每种情况的工作流关系。

写用例时，需要写明：什么情况下可以开启这个功能；执行完这个操作以后，用户得到了什么；这个用例怎么利用已经存在的产品架构。

最后，我讲解了如何把用例具体化，这个过程对于缺乏框架的新产品和已经有框架的成熟产品是不一样的，并且分别给出了这两种情况下用例具体化的方法。

思考题

请你思考一下，微信阅读公众号文章的用例都有哪些呢？请你描述一下已有的用例，并且添加两个新的用例。

10 | 什么是最小化可行产品（MVP）？

最小化可行产品，是现在硅谷产品开发最推崇的理念，其思想来源于“精益创业”（Lean Startup），由埃里克 · 莱斯（Eric Ries）在《精益创业：新创企业的成长思维》中提出。

精益创业代表了一种不断形成创新的新方法，它源于“精益生产”的理念，提倡企业进行“验证性学习”，先向市场推出极简的原型产品，然后在不断地试验和学习中，以最小的成本和有效的方式验证产品是否符合用户需求，灵活调整方向。如果产品不符合市场需求，最好能“快速地失败、廉价地失败”，而不要“昂贵地失败”；如果产品被用户认可也应该不断学习，挖掘用户需求，迭代优化产品。

最小化可行产品 = 凤凰男

现在，我喜欢把最小化可行产品描述成一个“凤凰男”，通过这个比喻你很容易理解这个概念。

当你刚和他相恋的时候，他只是对你好，除此之外真的一无所有，但是之后他奋发图强，赚了钱买了房子买了车，后来提升了时尚品味，开始健身了，开始品红酒了，带你去世界各地游玩，最终成为了一个“教科书”般迷人的老公。

但是其实你最需要的是对你好，如果他连最基本的对你好都达不到，那你肯定是不会跟他继续交往的。

所以，最小化可行产品， 就好比一个奋斗阶段的“凤凰男”，它至少要满足你的一个需求，并且可以比较好得满足，否则你没有任何理由去选择它。所以，“最小化”在这里的意思就是，没有任何一个功能是“加上去也挺好的”，但是少了任何一个功能都无法解决用户最基本的需求。

最小化 = 降低试错成本，速度 > 完美

很多时侯，我们把一个产品做到完美再推向市场所花费的成本太高了，有可能付出了几年时间做出的产品却未能解决真正的用户需求，结果就是浪费了大量的时间和金钱。

那不如把事情简单化， 在一开始只做出一个能够解决用户需求的、最最基本的产品，然后再一步一步通过用户和产品的互动， 不断优化、不断创新，最终形成优秀的产品。

下面来看几个大型科技公司最小化可行产品的例子。

这是 2004 年的 Facebook，当时只有填写用户的个人介绍、联系方式、政治观点、个人兴趣，显示用户的朋友、加入的小组和发消息功能。这个阶段的 Facebook，还没有大名鼎鼎的朋友圈（News Feed），但是具备了为用户提供最基本的和朋友交流、看他朋友群的功能，满足了用户的窥探欲以及和他人交流的基本需求，所以大受欢迎。

这是 1997 年的谷歌， 只有简单的文本搜索功能，这时它的域名还在 Stanford 下面。你输入想要搜索的关键词，然后选择你希望显示多少条搜索结果，点击搜索后就可以看到最相关的特定数量的结果。
更有意思的是，它还有一个“I'm feeling lucky”的按钮，当你点击这个按钮的时候，它只会自动显示一条和你搜索的内容最相关的结果，这个有趣的按钮是当时谷歌的一大特色。当年雅虎还是通过运营员工的人工筛选，把网站链接加到目录上，但效率低下。而谷歌的佩奇排名（PageRank）算法则实现了规模化和自动化，能够更好得满足用户需要快速、有效地获取信息的需求。因此，谷歌大获成功。

这是 1994 年的亚马逊，内容就是一个书单，你看中了哪本书就下单，然后亚马逊帮你找到这本书寄给你，这时它连自己的物流管理系统都没有。网页中显示亚马逊有 100 万本书，并且提供了一个目录，你可以查看书的作者、简介、书名、关键词等。虽然网站非常简陋，但是可以帮助你找到书店找不到的书，所以非常受欢迎。

这些产品共同的特点是，在初级阶段的功能非常简单，但都能以最好的方式满足用户一个未曾被满足的需求，所以用户就会持续使用，形成粘性。说到这里，我就要说说最小化可行产品的另一个要素“可行性”了。

可行性 = 确保你的产品能够基本解决用户的需求

加快进入市场的速度，并不是说你的产品什么也没解决就可以进入市场。 你的最小化可行产品如果连最基本的唯一需求都解决不好， 这时你首先需要提升这个产品的体验， 看看能不能用更好的方式解决这个需求，而不是着急增加新的功能。

想一想，如果“凤凰男”在你说病了的时候，只是说“多喝热水”，而没有拿着玫瑰花和凉毛巾直奔你家，那他可能就要提升恋爱情商了，不然就算他的月薪从两千涨到三千也没什么价值。同样的道理，只有把最基本的需求解决好之后，最小化可行产品才有价值， 这之后才是你考虑新功能和新体验的好时机。

你可能会问，这个度应该怎么把握呢？我通过一个故事来讲讲这件事。

Instagram 刚刚创立的时候，只有发图片的功能，用户体验并不好。有一次，CEO 凯文 · 斯特罗姆（Kevin Systrom）和女朋友介绍自己的这款 APP，他女朋友看到图片后说了一句：能不能把这些照片弄得好看一点呢？他茅塞顿开，便和创业小伙伴们联合开发了几款滤镜，于是才有了后面的故事。

从这个角度来说，没有滤镜功能的 Instagram 不能算是最小化可行产品，因为用户的需求并不只是分享照片，而是要能够轻松分享拿得出手的照片。所以，虽然当时改进后的 Instagram 没有发消息、探索板块（Explore Tab）等功能，但是用户增长速度还是突飞猛进。

接下来，我跟你分享两个失败产品的例子，你可以体会一下“可行性”的重要性。

第一个是，Twitter 联合创始人比兹 · 斯通（Biz Stone）创立的一款叫作 Jelly 的 APP，一开始发布的时候它有众多媒体站台、头版头条呼声很大。

Jelly 的定位是做朋友互动的搜索引擎，即你可以在 APP 上提问，你的朋友登录后就可以看到，回答你的问题。然后，你就会陆续收到来自于朋友们的回答，这些回答就是你搜索的结果了。比如，你可以问我晚上去哪吃饭，朋友看到了就会给你推荐餐馆。

但这个 APP 有两个主要的问题：

它只解决了提问者的需求，但对回答问题的人来说毫无意义，因此回答问题的人并没有养成使用这个 APP 的习惯，最终的结果是回答量逐渐减少；

等到朋友的回答需要时间，而你往往没有耐心和时间等待朋友给你的推荐。

第二个是，迪克 · 卡斯特罗（Dick Costolo）离开 Twitter 后做的一款叫作 Chorus 的 APP，目的是帮助一群朋友互相监督定期健身、吃健康的食物。这个 APP 一开始有不少用户，但是一个月后就不是那么回事儿了。

主要原因是有人懒惰或者太忙没有健身，其他朋友会提醒你，但后来也就觉得没有意义了，而被提醒的人也因为感觉羞愧不再继续使用，所以这个 APP 在上线 8 个月之后就下架了。其实，这个产品并没有从根本上解决用户需求，它试图通过社交压力让大家坚持健身，但是过大的社交压力却适得其反。

上面这两个产品的失败，归根结底是它们忽视了“可行性”，并没有真正地解决用户最基本的需求，或者说没有以很好的方式解决这个需求。

总结

最小化可行产品， 就好比一个奋斗阶段的“凤凰男”，他至少要满足你的一个需求，并且可以满足得比较好，否则它的存在就没有实际意义。

第二点是，最小化可行产品要具备“最小化”和“可行化”两个要素。最小化的目的是降低试错成本，快速验证产品能否满足用户需求。而可行化是要确保你的产品可以很好地满足用户需求，而不是为了追求速度发布一个差强人意、只能解决 50% 需求的产品。

思考题

现在你需要设计一个 APP，能够帮助学生家长和中学老师联系，方便他们了解孩子在学校的情况。这个 APP 需要解决的问题是，每学期只有一次家长会， 但是家长希望能够和老师们更频繁地交流孩子的情况，知道孩子的问题。请你思考一下，这个 APP 的最小化可行产品是什么，需要具备什么样的功能。

查阅一些资料，说出以下几个产品（或者品牌、个人）的最小化可行产品是什么，以及这些产品是如何从最小化可行产品走到今天的。

王者荣耀
拼多多
Gucci
谢霆锋（他是怎么起步的，提供了什么，并满足了什么粉丝的需求，后来又是怎么发展的）

11 | 案例：产品发布之前出了乱子，如何权衡取舍？

上一次程序员和产品经理的战争中，说得最多的是：产品经理每天就知道加功能蹂躏程序员。

但实际上，作为一个产品经理，我每天做得最多的事情就是砍功能：一是，删减产品需求文档上的功能，只保留最重要的功能；二是，已经决定了要加功能，但出现了突发情况，需要临时决定到底要不要砍功能。

第一种情况下，砍掉产品的哪些功能主要考虑每个功能对总体指标的贡献有多大，以及工程难度有多大；而第二种砍产品功能的情况往往出现在产品发布之前，还可能会涉及到和其他组合作的情况，需要考虑各个方面的因素，操作起来比较复杂。

平时在 Facebook 的工作中，我最常说的一句话是“这个是不是 launch blocking？”，即没有这个功能会不会影响产品发布。我经常在以下两种情况下说这句话：

第一是，我们的产品刚刚开始内测，一般会让公司内部所有员工使用进行测试，然后再开放给一部分用户使用。如果我们收到用户反馈说某个功能哪里哪里不好用，那我们就会讨论到底要不要把产品发布时间推后，先把这个功能修复好再发布产品。

第二是，我们的产品需要和其他组合作完成，但其他组出现了突发情况，以至于产品的某个功能无法按时完成。比如，我所在的视频组要和搜索组合作，完成允许用户通过关键词搜索视频的功能，但搜索组突然出现了问题，无法按照预定的发布时间实现“自动推荐关键词”，我们现在就会讨论到底是先砍掉这个功能直接发布产品，还是等到搜索组的问题解决后再发布这个产品。

往往第二种问题会比较复杂，处理起来需要考虑的因素也非常多。所以接下来，我以一个实际产品为例给你分享一下，涉及到和不同的产品团队合作时，应该怎么处理产品发布前出现的突发情况。为了保护隐私，我稍微改动了一下产品细节，但并不会影响我要分享的要点。

功能发布背景介绍

我们产品要发布的新功能： 帮助一类明星用户宣传自己，让这些明星用户们获得更多普通用户的关注，从而提升明星用户的点击量。明星用户需要先完成一些任务，才可以得到宣传机会。所以这个新功能主要包括两部分：一是，普通用户的部分；二是，明星用户完成任务后开启这个新功能得到平台的宣传，并且可以查看因此增加的点击量。

要和我们的产品同时发布的还有其他几个针对明星用户的产品，这些产品对应的明星用户是一样的。

经历了一段时间的开发，第二部分明星用户的功能已经开发完毕，第一部分的功能也接近尾声了。突然，负责我们产品普通用户部分开发的 iOS 工程师说：“大事不好，我刚刚发现了一个 Bug，也就是说这个功能上线后，只有 5% 的 iOS 普通用户能看到，而剩下的 95% 的 iOS 用户都看不到，我也不知道原因是什么”。

那么问题就来了，iOS 一周才会发布一次新版本，新版本给到 APP Store 还要经过一周的审核，因此如果这个问题解决不了，那么这个新功能的上线就要延迟 2 周的时间。但是，这个功能在安卓平台已经测试完，并且参加测试的明星用户好评如潮。

所以，我们需要做出决定：是先解决 iOS 平台部分的问题，然后两个平台同时上线，那么上线时间就要延后两周；还是先在安卓平台发布新功能。

思考方式

现在这个问题其实涉及到普通用户和明星用户：对普通用户来说，iOS 有没有这个功能并没什么影响，因为这次的新功能只是增加了一个可以让他们看推荐的明星用户的版块；而对明星用户来说，我们需要显示这个新功能给他们增加了多少点击量，来保证他们有足够的动力完成预设的任务。

因为要同时发布的这几个产品对应的明星用户是一致的，所以如果我们产品的这个新功能在所有平台都晚发布两周，那么其他几个产品的功能就会不完整。但是，现在公关方案已经接洽好了，如果把这几个产品全部延后两周发布，那必然损失惨重。这是把安卓端和 iOS 端全部延后发布的风险。

如果只有安卓端的用户可以看到推荐并点击，那这个明星用户的总体点击量会因为 iOS 端的用户无法看到并点击而降低，而最先发布的两周时间里用户点击量的增加量，是明星用户评价这个功能好坏的关键。所以，如果这些明星用户看到点击量并没有因为这个新功能增加多少的话， 他们就会觉得这个功能不实用，以后也就不会用这个产品了，更不用说持续完成任务了。这就是提前给安卓普通用户发布这个功能的风险。

针对我们产品现在的情况，以及上面考虑到的风险，我们讨论出了三个方案：

方案一： 我们产品的普通用户部分的功能，先在安卓平台发布，而 iOS 平台晚两周再发布，明星用户部分的功能发布日当天全部发布；其他几个产品正常发布。如果采用这种方案，我们需要考虑两个问题：
第一个问题是，要和明星用户解释一下，普通用户部分的功能现在只有安卓平台发布了，iOS 平台两周后才会发布，所以两周后的数据才是最有说服力的；
第二个问题是，这个方案是有风险的，虽然我们已经跟明星用户做了解释，但毕竟数据不好看， 明星用户依然会对我们的产品丧失信心。

方案二: 先发布其他几个针对明星用户的产品，而我们产品在安卓端和 iOS 端的发布全部推后两周。这个方案的风险是，因为我们产品延后发布，导致其他几个产品缺乏完整性、用户体验不连贯。

方案三： 所有的产品全部推后两周调试完美后再发布。这样做的风险是，全部计划包括公关计划都会受影响，损失惨重，其他的组不会同意。

其实，上面三个方案都不理想，我们需要思考一些更好的方法。所以，我们换了一个思考问题的角度：iOS 平台的普通用户点击量对整体点击量的影响有多大？

针对这个问题，我们专门做了用户调研。用户调研结果显示：有些明星用户高达 80% 的访问量来自 iOS 平台，而有些明星用户的很多粉丝都在用安卓系统。

于是，我们针对调研结果，把明星用户根据大部分访问量的来源分成了两类，并提出了两个比较“聪明”的方案：

第一个方案是：我们产品普通用户部分的功能先在安卓平台发布，而明星用户部分功能，选择先发布给大部分点击量来自安卓平台的部分明星用户；其他几个针对明星用户的产品，也先发布给安卓粉丝量占比较大的明星用户。这样一来， 对外的新闻搞，可以把“今日发布给所有人”改成“今日开始发布”。两周后，我们把 iOS 端的问题解决了，再做如下操作：在 iOS 平台开放我们产品普通用户部分的功能，同时把其他几个针对明星用户的产品开放给全部的明星用户。

第二个方案是： 其他几个针对明星用户的产品，以及我们产品的明星用户部分的功能，正常发布；我们产品的普通用户部分功能先在安卓平台发布，但是等两周后 iOS 平台发布这部分功能后，再向明星用户显示点击量提升的数据。

这样，明星用户可以先在这个两周的时间里做任务，毕竟做任务也需要时间，等所有的平台都发布完成之后，再给他们显示包含了所有 iOS 和安卓用户的数据，“好看”的数据可以激励他们更好地完成任务。

因此，先让明星用户形成使用习惯，再用数据激励他们继续使用，也不失为一个好方法。

这两种方式，我们产品的团队成员都可以接受，但是因为涉及到要和其他几个产品同时发布的问题，需要选择一个最优方案。其他产品的产品经理，希望他们的功能一步到位， 同时发布给所有的明星用户。

经过各种讨论、思考，最终我们愉快地决定， 选择更灵活的第二种方式：除了我们产品在 iOS 平台推迟两周发布普通用户部分的功能、并且在两周后才向明星用户显示增长的用户点击量外，其他产品照常发布。

总结

我通过一个具体的案例，跟你分享了如何权衡取舍，以及在产品发布之前部分功能出现问题时如何统筹。

通过这个具体的案例，我要表达的内容包括以下四个方面。

第一是，要明确功能造成问题的风险以及受影响的人群，这个案例里涉及到了三类人群：使用我们产品新功能的普通用户、使用我们产品新功能的明星用户、使用其他产品的明星用户。

第二是，要列清楚所有可行的选项， 以及对每个群体的影响。

第三是，分析各个选项之间的风险。

第四是，要有大局观，选择最合适的方案。在这个案例里，我们最终考虑了其他产品想要完整体验、准时发布的要求，选择了最灵活、代价最小的处理方式。

思考题

针对本文案例的情景， 你还有什么其他的解决方案？欢迎你给我留言。

12 | 制定产品成功指标

约翰 · 道尔（John Doerr）是硅谷最牛的风险投资人，是谷歌、亚马逊、网景、升阳电脑等公司的早期投资人，更在 1999 年投资谷歌时，教给了创始人成功指标（OKR）的概念，帮助谷歌达到了今天的高度。2018 年 4 月，他出了一本叫作《以你在乎的作为衡量指标》（Measure What Matters）的书，专门讲成功指标这件事。

他在书中指出：指标是为了定义你想要完成的目标，需要表达清楚在什么期限之内、要达到什么具体的、可衡量的结果。 换句话来说，一个好的指标应该是像“2018 年底之前实现 100 万日活”这样的，而“让用户多花时间在 APP 上”、“争取用户规模达到 100 万”都因为缺少了关键信息不能算是一个好指标。

我们经常会说，作为一个产品经理，当你确定了正确的成功指标，你就成功了一半。

比如，你是电商，你的成功指标应该是下单用户数，而不是总的用户数量。因为，你可以让大家下载 APP 抽奖赢取福利，但是大家下载后并没有下单，那最后即使你成功积攒了千万用户这个公司也依旧无法做下去。因此，制定了错误的成功指标，进而导致了后续的产品策略失误，最终的结果就是产品的失败。

假设微信朋友圈的成功指标是，用户在微信朋友圈花的时间。为了达成这个目标，微信向你推送了更多花时间的内容（例如，文章、视频），却减少了你所关注的朋友发的文字状态或者图片内容。这样看似增加了你在微信朋友圈花的时间，但是却忽略了你使用朋友圈的目的是和朋友互动。

那么，当你的需求得不到满足时，你就会减少在微信朋友圈花费的时间，甚至放弃微信朋友圈，所以单纯采用用户花费的时间多少作为成功指标最终起到了反作用。这也恰恰说明了产品的成功指标要和实现的用户需求相契合。

其实，有的时候产品所要满足的用户需求并没有改变，只是产品阶段不同指标也会不一样，那么你应该怎么判断制定的指标是否正确，又怎么用指标作出产品决定呢？

接下来，我用这个微信朋友圈添加新功能的例子来跟你解释这个问题。

案例： 如果你是微信朋友圈的产品经理，现在你要在朋友圈加一个可以用表情包评论的功能，你需要通过制定这个功能的成功指标、进行 A/B 测试，来确定这个功能到底值不值得发布？

首先，明确产品的成功指标是什么。

第一步，弄清楚整个产品的最高目标。

如果我是微信朋友圈的产品经理，我会从微信的核心指标开始，毕竟朋友圈是微信的一个功能。假设微信的核心指标就是用户的活跃程度，包括用户评论、分享、发消息、发图片等用户行为。

这实际上是一个非常复杂的指标，需要考虑每项用户行为的权重，比如评论相当于几分、分享相当于几分。假设，我们已经通过用户数据、调研等方式确定了这个衡量指标是： 用户的总活跃分 = 评论×1 + 分享×0.5 + 发消息× 1。

朋友圈的设计初衷也是希望用户通过这个平台分享自己的生活、增加朋友间的互动，以此来增加用户的活跃程度，从而提升整个微信的总活跃分。

第二步，思考你的产品功能还有哪些指标需要注意。

我们已经明确了朋友圈的核心目的是为了提升微信用户的活跃度，增加微信的总活跃分。另外，微信朋友圈正计划增加在用户发的状态间穿插广告的功能，即每隔几个状态就穿插一条广告，所以我们希望用户可以多刷几条朋友状态，以提高穿插广告的曝光量，所以用户浏览朋友状态的数量也是一个指标。

第三步，思考新功能可以解决的问题和上面列出的几个指标有什么关系。

比如，在朋友圈加了一个可以用表情包评论的功能，以降低朋友间互动的门槛，帮助用户更方便地发表评论。

通过表情包评论的功能，发表评论的用户可以通过一个有意思的表情，表达用文字无法传达的情感，这对他们来说意义非凡。

而对于发表状态的用户来说，以前一条状态可能只有两条文字评论，但现在因为表情包降低了回复门槛，评论数增加到 10 条甚至更多了。这样，发表状态的用户会感觉到朋友们都很关注他，这也会激发他再次发状态的激情，最后的结果就是增加了微信的总活跃分。

第四，思考反指标是什么。

反指标（counter metrics）是指你的产品带来的负面影响。 假设微信还会对朋友圈的内容质量打分，那么这个使用表情包评论功能的反指标就是降低了朋友圈内容质量分数。

因为以前大家使用纯文字交流时，都比较“走心”，交流的内容也很有深度，而现在几个简简单单的暴走漫画、卖萌表情就可以代替语言， 反而让交流流于表面，丧失了原本的厚重感，所以就会降低整个朋友圈的内容质量分数。

通过对成功指标的分析， 我们明确了这个新功能的成功指标和反指标：

成功指标是：提升微信的总活跃分和用户每天浏览朋友状态的数量；

反指标是：降低了朋友圈内容质量分。

然后，进行 A/B 测试验证新功能对产品的影响。

我们设置了实验组和对照组，实验组增加了这个功能，而对照组没有，其他条件一样，然后观察两组成功指标和反指标的变化情况。

如果实验组的成功指标增加显著，而且反指标被控制住了，说明这个功能起到了我们想要的效果。

一般情况下， 我们会设定一个指标提升的具体目标，比如 5%，这个量化标准是非常重要的。如果新增加的功能对成功指标的提升低于这个目标，那这个新功能是不能算作成功的，是没有必要添加的。

比如，我们花了两个月的时间只提升了 0.1%，那么就应该认真考虑有没有必要继续花 1 个月优化这个功能。这时，我们通过数据分析和估算发现，继续优化这个功能并不能达到提升 5% 的目标，那后续的优化就根本不值得了，需要当机立断砍掉这个功能。

这里需要注意两个问题:

如果你的产品有多个指标想要提升，你需要将这些指标按照重要性进行排序，方便出现问题时权衡取舍。
以微信朋友圈添加表情包评论功能为例，通过分析已经明确了成功指标和反指标，如果你的测试结果发现，成功指标中的微信总活跃分下降了、用户每天浏览朋友圈状态的数量增加了，那你应该怎么权衡取舍呢？
一般情况下，我们会确保新添加的功能不会影响整个产品的总指标，选择放弃这个新功能。但是，这个案例并没有这么简单，因为我们的假设是：广告穿插在朋友圈的状态之间，用户浏览朋友状态的数量增加了，也就意味着用户浏览的广告数量增加了，那无疑将会带来更多的广告收入。所以，这在这个案例里面，产品经理需要权衡是整个产品的成功指标重要，还是通过广告获取更多的利润更重要。
往往这样的决定已经超出了产品经理所能处理的范围，需要公司最高级别的领导来决策了。公司高层可能会说，我们现在的收入一直上不去、股票大跌，我们必须赶快扭亏为盈，那广告带来的收入就更重要了；公司高层还可能会说，我们要以用户为第一原则，不能为了短期利益损害用户的信任，那整个产品的总指标就更重要了。当然，如果你是创业公司 CEO，这样的决定就需要你自己做了。

A/B 测试的时间需要根据具体的产品情况而定，过短的测试时间得到的指标不具有稳定性，需要等数据稳定后再做决定。
比如表情包评论的功能， 可能大家一开始因为新鲜使用频率比较高，各项指标都非常好看； 但是过几天用户发现朋友圈的评论全都是各种表情包，并没有实质内容和有价值的讨论，所以逐渐丧失了兴趣，导致指标大跌。那就需要延长 A/B 测试的时间，等指标稳定后再做决定。

总结

今天这篇文章我以微信朋友圈添加使用表情包评论的功能，跟你分享了制定产品成功指标大致可以分为 4 步：

明确整个产品的最高目标；

思考这个新功能的小指标有哪些；

明确这个功能是如何提升整个产品的总指标和小指标的；

明确反指标是什么。

确定了产品的成功指标后，需要进行 A/B 测试，这里还有两个问题需要注意：

在指标之间进行权衡取舍；

要注意 A/B 测试的时间，需要等数据稳定后再做决定。

思考题

如果你是抖音的产品经理，现在想加一个加强版的美颜功能，你应该如何制定产品的成功指标？欢迎你给我留言。

13 | 如何撰写产品需求文档？

很多产品经理给人的印象就是每天开会，开完会就趴在桌子上写产品需求文档。上次和国内的几个产品经理交流时，有的产品经理告诉我说花好几个星期写的一份产品需求文档，工程师没看完就扔一边了；有的产品经理和我说， 他们的产品需求文档非常精确，每个小细节、每个逻辑都讲得清清楚楚， 流程图也画得非常清晰， 工程师照着这个文档一行一行地写代码就可以了。

我在硅谷认识的很多产品经理，包括我自己，都不喜欢把大量的时间花在写产品需求文档上。我们认为，应该直接和工程师、设计师面对面地沟通，当面把东西讲清楚， 而不是写一摞文档，最后工程师、设计师根本没时间看，或者一看这么多内容随便瞟一眼就扔一边了。

这样做的好处是，我们做决定的速度非常快，当面开完会，马上就开始干活，而不需要把每个细节都写得清清楚楚。

这样做的缺点是，如果你的团队成员还不具备自己做一些小决定的能力，或者公司对于一些基本的 UI 部件没有固定的标准（在大公司，按钮、配色都有相应的设计准则），那么很有可能出现产品的功能和功能之间不协调的问题。尤其是当一个成员辞职后，整个产品组需要花很长时间来填补这个空缺。所以，我理解有些公司的产品经理会在产品需求文档里面，事无巨细地把所有细节都写得清清楚楚。

所以，我们还是要写产品需求文档，只不过在产品需求文档中只写清楚最最重要的内容就可以了。可能你会说我这样的方式更适用于硅谷、适用于大型公司，并不符合我的现状。但这篇文章并不是要“教条式”的向你传达如何做产品经理、如何写产品需求文档，更重要的目的是带给你一个新的思考方式，把可以借鉴的方法应用到你的实际工作中，相信会起到事半功倍的效果。

明确产品需求文档的目的

撰写产品需求文档是为了和工程师、设计师、数据科学家等团队成员清晰的沟通产品蓝图， 讲清楚产品要解决的问题、 实现的场景、成功的标准等等， 并有据可查。所以，产品需求文档需要具备以下三种功能：和团队成员高效沟通，用他们能够看懂的方式清晰地表达你的想法，让他们清楚什么该做什么不该做；记录之前的问题是如何解决的；明确列出产品功能的短期目标、长期目标，绘制一个从短期到长期的产品蓝图。

在我看来，产品需求文档并不需要面面俱到，写清楚所有的事情，重要的是写出团队成员真正感兴趣的、对他们有帮助的内容。

产品需求文档需要包含哪些内容？

我的产品需求文档一般会包含以下内容：

第一，要解决什么问题。

工程师、设计师等对产品解决的问题都有自己的理解，而且根本不在一个频道，这个情况在产品经理的工作中非常常见。

比如，我要在直播上增加一个给主播唱歌打分的功能，工程师们认为是为了让主播提高唱歌水平，而设计师们却认为是让粉丝们在主播换歌的空当不会感到无聊，按照这个思路设计的产品必然不会成功。但实际上，问题是出在了产品经理身上，他没在产品需求文档中讲清楚到底我们要解决的问题是什么。

所以，如果我是豆瓣读书的产品经理，要添加一个图书推荐的功能， 我会先讲清楚这个功能要解决的问题是什么，这也是我作为产品经理必须要跟大家说清楚的。比如说，用户现在已经可以通过豆瓣来浏览评价高的图书，也可以通过豆列找到自己感兴趣的书，我要新增加的图书推荐的功能是进一步解决用户渴望通过个性化的方式、找到自己感兴趣且评分比较高的书。

在产品需求文档中明确了新的功能或者产品需要解决的问题是什么，可以让团队成员明确为什么要做这个产品。相信我，让大家对产品要解决的用户痛点保持一致，可以避免以后无数个日日夜夜里的争论不休。

第二，论证这个痛点问题到底是不是存在（这个坑我踩过，大家一定要注意）。

在很多工程师的眼中，产品经理只会吹牛、瞎扯，我也确实见过不少产品经理随随便便地就写出了用户痛点，而并没有验证过这些痛点到底存不存在，产品要解决的问题到底存不存在。

比如，给主播唱歌打分功能的这个例子，到底粉丝们在主播换歌空档期有没有闷、闷到什么程度，或者到底主播有没有必要提升唱歌质量、粉丝们在不在乎主播的唱歌质量，我们应该先验证这些问题是不是真的存在，然后再去谈论具体怎么设计这个功能。

所以，我上面说到的豆瓣读书的例子，如何验证用户是真的有寻找读书建议的需求呢？我们可以通过数据来验证，如果我们发现 35% 的豆瓣用户已经习惯通过豆瓣找书阅读，特别是通过豆瓣来探索刚刚推出的新书，那我上一步提出的问题就是真实存在的。

第三，写清楚这个功能的成功指标和反指标是什么。

这个功能的成功指标应该是，通过这个功能用户在豆瓣下载或者购买图书的次数。

如果使用豆瓣图书推荐这个功能的用户数量非常多、频率非常高，可以说明这个功能有人用；如果用户通过图书推荐的功能找到书后，通过豆瓣下载或者是购买图书的次数也增加了的话，那就说明这个功能对豆瓣有好处。

这个图书推荐功能的反指标，是指增加这个功能后用户使用其他豆瓣产品的频率。如果因为这个图书推荐的功能， 豆瓣的其他产品（豆瓣电影、电视剧等）的用户数量和使用频率降低了，那这个功能对于整个豆瓣产品来说到底是不是好功能就有待进一步研究了。如果一项新功能的成绩会挤占原有产品的成绩，这就叫做侵蚀效应，来源于生物界的自相残杀（cannibalization）这个词。

第四，讲清楚要解决的用户场景。

这个功能的使用场景可以包括 ;

用户已经选择了一本书，我们自动推荐给他和这本书类似的其他图书。

用户选择了自己感兴趣的主题，我们推荐书单。

用户刚刚进入豆瓣读书页面，自动根据他之前读的书以及喜欢的作家推荐书单。

从产品的角度来看，这三种场景的差别很大。

第一种情况下，用户已经给了我们非常明确的信息，表明了他此时此刻找书的意向。比如，用户说：“我刚看了《钢铁是怎么炼成的》，给我推荐一本相似的书”。
我们需要做的是根据已知的用户意向准确推荐，要着重推荐的准确和相关性，难点是怎么推荐和《钢铁是怎么炼成的》最相关的一本书。
这就像我们走进商场， 对售货员说：“我要买一条和这个笑脸包搭配的丝巾”，这时售货员就需要赶紧帮我找到很搭的丝巾，快、狠、准最要紧。

第二种情况下，用户只给了我们一点点暗示，有点“犹抱琵琶半遮面”的意思，他说：“我喜欢科幻小说，给我推荐几本”，这时我们需要根据这些信息，进行推荐。但是，可以推荐的科幻小说有很多，用户此时此刻也没有具体想要哪一本书的想法，更多的时候只是在探索。
所以，我们的难点是：第一，给用户推荐各种各样的科幻小说，方便他们选择；第二，科幻小说有几万本，我们怎么决定推荐书单的排序；第三，如果给所有人都推荐《三体》这样的书单，难免有些单调，而且我们也不能确定用户会喜欢《三体》这个风格的图书，所以就需要注意科幻小说书单的多样性。
这种情况就很像我们走进商场，跟售货员说：‘’我要买一个包包”，然后售货员直接给你介绍了三款最新流行的网红包，他们也不知道你到底喜不喜欢这个风格。

第三种情况下，我们并不了解用户使用图书推荐的目的，只能根据他以前的习惯进行推荐。 他以前喜欢过《哈利波特》、《百年孤独》，也喜欢过《从零到一》，涉猎广泛，那我们可以推荐的书就实在太多了，并且我们并不知道用户此时此刻想看什么。
用户刚进入豆瓣图书，可能只是想随便看看，或者找一本好书，或者找一个热销的书单，所以这时最重要的不是帮用户找到具体的某本书，而是要激发他们的兴趣，把他们引到更深层次的读书需求上，那就需要让他们多看看、多逛逛。
同样是逛商场的例子，我刚刚进入商场，应该是鼓励我多逛几个店，并通过明亮的灯光、热情的音乐等方式激发我的购买欲望，而不是在门口直接拦住我给我推荐一款笑脸包。

第五，解释清楚产品功能方案。一般包含以下六个方面。

如何开启这个功能。

这个功能的流程图是什么样的，这是最重要的部分。
你需要针对每一种场景画出流程图，目的是让团队成员有一个清晰的认识。这个流程图，并不一定是经过精心雕琢产生的精美图表， 也可以用第 1 步、第 2 步、第 3 步等方式来表达。

这个功能哪些部分可以使用已有的架构或者产品流，这样可以在已有基础上稍作修改，而不用重新开发，可以大大节约产品开发时间。
比如， 豆瓣已经存在电影推荐和音乐推荐功能了，所以图书的推荐列表可以参照以前的产品流。
再比如，我们已经推出了让用户选择自己喜欢的音乐类型的功能，根据用户做的音乐类型测试的结果，向他们推荐音乐。同样的测试流程，我们可以直接应用在图书推荐上。

如果涉及到和其他组合作时，我需要先和其他部门沟通好，方便我们组开展工作。
比如，我们这个功能会和其他组的产品功能在 UI 上有一些冲突，他们可能要修改“推荐”这个总菜单， 这个总菜单包含我们的图书推荐功能，那就需要在产品需求文档里面记录这个情况。

有些情况下这个功能可能无法达到预期效果，那么这时的解决方案是什么。
比如，用户没有任何图书浏览记录， 那我们可能就无法提供个性化的图书推荐， 这时我们要么随便推荐一堆书，要么直接导入畅销书单。
再比如，图书推荐的功能是通过分析用户看了图书 A 后还喜欢看什么书来推荐的，但是有些英文新书，这个功能会因为没有足够的资料而无法生成推荐， 这时我们需要告诉用户这本书不适用于图书推荐这个功能。

往往事先没有想清楚的地方都可能会出现问题，导致整个产品设计和开发都得从头来，这也是一个坑。
一个推荐系统经常会出现的问题是，重复推荐的现象。造成图书推荐系统重复推荐的原因，可能包括：不同出版社的同一本书，或者同一个出版社、同一个作家的 2014 年版、2015 年修订版、2016 年再版。如果一个书单里 10 本书，有 3 本是重复的，那体验就太差了，所以我们需要找到一个可以去掉重复书名的方式。
如果这个问题在之前数据提取的时候就已经考虑到了，那么我们训练的机器学习模型的结果就会比较准确。可是，如果事先没考虑到这个情况，那就需要在发现这个问题后，从头开始了。
比如，《爱的教育》这本书，有无数个版本（宝宝版、小学必读版、人生成长版、精编版、简化版），相关的推荐系统的数据就很容易分散。如果销量或者评论数是推荐系统的一个重要指标的话，那么本来《爱的教育》这本书所有版本加起来有 1 万条评论，但因为系统默认是不同的书，就导致每个版本的几百个评论在推荐系统的畅销排名都很低，所以这本书压根儿就不会出现在书单上。发现这个问题之后，就要重新处理数据、重新运行训练环境、更新畅销排名等工作，非常容易推迟产品的发布。

总结

这篇文章我和你分享了产品需求文档需要包含五大关键内容：解决的痛点问题是什么，论证这个痛点确实存在，说明如何衡量成功，要清晰描述场景，并解释清楚产品功能方案。

成功的产品需求文档，可以让团队成员都明确要解决的痛点以及解决的方式，让大家对产品从策略到执行都清清楚楚，从而实现团队成员之间的高效沟通。

另外，我还跟你分享了两个可能会踩的坑：一是，没有论证这个痛点到底是不是存在，而是想当然认为用户肯定有这个痛点；二是，没有提前考虑到产品可能出问题、实际执行影响预期功能计划的情况，导致产品发布时间推后。

思考题

如果你是微信公众号的产品经理，现在要添加一个粉丝可以和偶像互动的功能，你会怎么设计？你的产品需求文档会包含哪些内容？有哪些需要注意的地方？欢迎给我留言。

14 | 如何用数据做出产品决定？

今天这篇文章我用一个增长日活数的案例，跟你分享一下如何用数据做出产品决定。

案例背景：通过提高新用户的留存率来提高日活数

我们希望能够把不同活跃程度的用户区分开来，于是就发明了一个指标：七天活跃天数。我们用 D7 表示这个指标，直观体现留存率：D7=1，代表用户在过去的 7 天只使用了这个 APP 一天；D7=7，代表用户在过去的 7 天中每天至少使用这个 APP 一次。D7>4 代表高活跃度用户，2<D7<4 代表中等活跃度用户，D7<2 代表低活跃度用户。

通过对已有数据的分析，我们发现很多低活跃度用户并没有关注其他用户，他们的朋友圈根本没有任何内容，只能通过搜索来看内容。因此，我们认为用户关注其他用户的数量会影响到用户留存率，此时我们并不是非常清楚其他因素是否会影响留存率，所以我们可以先假设，关注其他用户对提高用户留存率非常重要。

形成假设

第一个问题是，影响用户留存率的原因是什么。

这个问题需要考虑以下两种情况：

第一种假设是，用户没有关注其他用户（或关注的数量非常少），他们的朋友圈里没有足够的内容，因此在 APP 里停留的时间也就非常短。

第二种假设是，用户没有被其他用户关注（或关注他的人非常少），他们的朋友圈虽然有内容，但是他们自己发出内容时很少会有人回复，久而久之丧失了对 APP 的激情。

我们假设这两种情况都会影响用户的留存率，但是影响留存率的原因并不一样。所以我们需要弄清楚，哪种情况发生的频率更高、对用户留存率的影响最大、应该先优化哪部分。

第二个问题是，用户的关注数量到底会不会影响留存率。

当用户关注 100 个人、1000 人和只关注 1 个人时，对留存率的影响是同一个级别的吗？用户自己的粉丝数量会不会影响留存率？当你有 100 个、1000 个和只有 1 个粉丝的时候，是不是也会不同程度影响你的留存率呢？

形成假设时要避免的坑是，切记要分情况考虑。不能简单地归类为增加关注数，而是要考虑清楚增加关注数其实影响了两类人，一类是关注别人的人，一类是被关注的人，这两种情况很有可能带来的结果完全不一样，所以要分开考虑、分开假设。

解决问题

第一个问题，影响用户留存率的原因是什么，我们通过 A/B 测试的方式来解决。 我们需要设计两组独立的实验来区分关注和被关注对用户留存率的影响。

关注其他用户与否： 我们给实验组用户的朋友圈推荐好友关注，他们可以直接一键关注所有人。这个推荐内容在用户每次打开朋友圈时都出现在第一条状态的上面，以增加用户使用这个功能的概率。对照组用户的朋友圈没有添加这个功能，只显示已经关注的朋友的内容。

被其他用户关注与否： 我们把实验组用户的账号作为推荐放到其他用户朋友圈的第一条，增加他被其他用户关注的概率。对照组用户的账号，我们会避免它们被推荐给其他好友。

我们通过两组实验对比发现， 当我们帮助用户关注更多其他用户后，他们的 D7 增加了 6%；而当我们帮助用户获取更多粉丝后，他们的 D7 增加了 4%。这说明，帮助用户关注更多人或者帮他们吸粉，可以让增加他们的留存率。

我们还设置了一组对比实验，分别在用户使用 APP 的第一周、第二周、第三周和第四周帮助他们关注其他更多用户。通过实验数据，我们发现，在用户开始使用的第一周时就让他们关注更多人，否则他们非常容易流失，而且再也不回来了。

除了帮助用户尽快关注别人，也要考虑尽快帮助用户吸粉，为此我们对比了第一周帮他们吸粉和过几周后再帮他们吸粉的数据，结果发现虽然第一周帮他们吸粉的效果会好一些，但是影响没有很明显。

通过上面的分析过程，我们制定了产品策略：增加一个“你可能想关注”的版块，在新用户第一周使用 APP 时，向他们推荐其他用户，并在这个板块里预留几个名额给其他的新用户。那么，这个版块既可以帮助新用户关注更多其他用户，又可以帮助新用户吸粉，相当于一箭双雕。

之后我们又做了一些优化：推荐什么用户才能帮助新用户提高留存率呢？为此，我们增加了推荐系统，根据新用户提供的个人信息进行推荐，或者根据新用户所在的位置、年龄、手机类型等进行推荐。

第二个问题，用户的关注数量到底会不会影响留存率，我们用统计图的方式来解决。

针对帮助用户关注更多其他用户的假设，统计图的横轴设置为新用户第一个周内关注其他用户的数量，纵轴为 D7。
我们发现，当用户关注的其他用户数量在 20 个左右的时候就到了所谓的临界点，也就是说，D7 逐渐趋于平坦，增速显著放缓。因此，我们发现了“20”这个魔法数字。所以我们把“帮助新用户在第一周内关注更多的其他用户”的策略，调整为“帮助新用户在第一周关注 20 个其他用户”。
通过上面的数据，我们做出了另一个重要决定，我们需要开发一系列功能，来帮助新用户快速发现、搜索其他用户，探索值得关注的主题以及每个主题对应的活跃用户，最终达到一周关注 20 个其他用户的目的。

针对用户粉丝数量对留存率的影响，我们做了同样的统计图：横轴设置为用户的粉丝数量，纵轴为 D7。
通过数据，我们发现用户的粉丝量不在多，如果有几个特别忠实的粉丝给你评论、发消息，你照样可以坚持在 APP 上发状态，增加 D7。所以，我们需要帮助你的忠实粉丝找到你，让你的忠实粉丝在你刚使用 APP 发东西时就能找到你、关注你。

这里需要注意的是，当你验证了某个指标对你的成功有影响时（比如用户关注其他用户的数量对于产品留存率有积极作用），不要仅仅停留于此，还要更深入的研究这个影响是正面的还是负面的、到底有多大、在什么情况下影响最大。你要找到那个可以发挥最大影响力的点，比如这个例子中的“20”，否则就会出现效果未达到预期或者事倍功半的结果。

产品决定

根据上面的数据分析，我们决定做以下的产品功能：

将“你可能想关注”板块作为重点，特别是针对第一周使用 APP 的新用户。

“你可能想关注”板块中，涵盖高质量老用户以及其他新用户。高质量老用户用来帮助这个新用户找到有意思的内容，推荐其他新用户是为了帮助他们增加粉丝量。

除此之外，想尽可能多的方式帮助新用户在第一个星期内关注 20 个用户。我们可以通过优化搜索推荐的方式，给这些新用户推荐更有价值的用户，并引领他们到广场上发现有意思的内容从而增加他们关注其他用户的数量等。

总结

这篇文章我用一个增长日活数的例子跟你分享了如何用数据做决定。

首先，要形成具体的假设，注意要把不同的假设分开写，而不是合起来写一个泛泛的假设。

其次，可以通过 A/B 测试的方式验证假设，每个假设需要单独设置对比实验来验证。

然后，验证完了某个变量对总体的成功指标有积极影响后， 需要找到这个变量影响整体指标提升的规律。

最后，要通过验证的假设决定产品功能，这才能保证你的产品可以真正能提升成功指标。

思考题

如何增加抖音用户的留存率？你有哪些假设，如何验证这些假设？

15 | 如何组织有效的会议？

产品需求讨论会对产品经理来说是家常便饭。

当产品经理对我们应该解决什么痛点、有哪些功能有了一个计划，接下来就需要组织产品需求讨论会了。我会和工程师、设计师等团队成员坐在一起讨论对这个功能的看法，跟他们讲讲这些功能一步一步的体验是什么样的：设计师是不是觉得这个设计是以人为本的；工程师会不会说我们的底层结构不支持，这个根本做不了。

简单地说， 产品需求讨论会目的是要明确我们的功能、量化成功的标准和时间表，团队成员达成一致意见后就开始撸起袖子努力干了。

首先，我跟你分享一个失败的产品需求讨论会，通过这个例子让你明白会议低效的几个常见原因，以及组织会议的几个误区。然后，针对这个案例的具体情况，我会告诉你怎么才能提高产品需求会的效率。最后，我会结合以前自己踩过的坑（说多了都是泪啊），跟你分享几个组织高效会议的独门秘诀。

案例：一个失败的产品需求讨论会

前段时间，隔壁组的产品经理组织了一个产品需求讨论会，讨论一个由他们主导的新功能，因为这个功能需要和我们合作才能实现，所以我们组也被邀请去开会。这个产品经理写了一本厚重的产品需求文档，组织大家每天一个小时讨论这个文档。

这个会议共有 21 人参加，包括：我们组的产品经理、工程经理、工程负责人和运营经理，他们组的产品经理、高级工程经理、工程经理、工程负责人、5 个工程师、2 个律师、设计师、设计师经理、数据科学家、用户体验调研师、运营经理、运营专员。

如此多的人员每天聚在一起一个小时，逐项地讨论这个需求文档，进展非常慢。在第五天的时候，他们的高级工程经理忍无可忍，当场问责：“每天在这里浪费时间，结果什么都没有讨论出来，这个模式根本不行”。这个产品经理瞬间不知道该怎么办了。

这次的产品需求讨论会，可以说是我在 Facebook 三年多以来开过的最杂乱无章的会。那么，我来给你分析一下这个产品需求讨论会失败的原因，其实这些原因都源于对产品需求会认知的误区。

以为开会要让全组的人都有参与感，所以邀请了所有人，导致参会者众多。这个新功能是针对众多媒体公司的，有点类似企业软件。它是一个复杂的工作流，涉及非常多的情况，每种情况对应的逻辑都不同，而且要符合对应的法律、政策等要求。
其实真正懂这个功能的也只有三四个人，但是团队其他成员都想参与进来，可以对产品功能做一些决定，而这个产品经理也希望可以讨好团队的每个成员。所以，会议的大部分时间都花在给这些不懂产品的人解答最基本的问题上，因此效率非常低。

以为多开几次会，多聊聊，效率会很高，但是大家都有很多会议要参加，因此每次开会都有不一样的人缺勤，导致会议效率低下。 每次开会都要跟上次缺席的人同步进度，往往会议开始的前十分钟甚至更长的时间，都浪费在这里了，这就导致了会议效率特别低下。

以为开会的目的是要从头开始逐项讨论，并得到大家一致的认同，所以细节讨论占据了会议大部分时间，反而来不及做重要的决定。 会议的模式决定了，如果一个成员有疑问，大家就都要停下来解决这个问题，一个小时很快就过去，于是未来得及做的重要决定又要第二天的会议来讨论。

那针对这样的情况，通过怎样的方式才可以避免呢？

一鼓作气 ，并设定一个需要作出决定的时间。
比如，这个复杂功能的需求讨论会可以把大家集中在一起 5 个小时，将 100% 的精力投入到整个会议中，一次搞定而不要分散成多次进行。如果这 5 个小时讨论不出结果，可以设定一个截止日期（比如周五之前），如果讨论不出来就加班继续讨论。
人类其实是一个很有意思的物种，没有截止日期的话，大家就会觉得有的是时间，拖来拖去；如果设置了截止日期，大家就会觉得工作压力大，最终争分夺秒赶在截止日期的时候完成。
所以，即使不知道这个会议需要多久才能开完，也一定要设置一个截止日期，哪怕到时候没能完成，往后推两天也比没有截止日期的效果来得好。

分工明确，减少参会人数。
可以先开一个项目启动会议。你可以邀请团队所有成员参加这个启动会，告诉他们这个产品开发的背景知识、调研结果、核心原则等战略和原则性的内容。比如，对于网红新的赚钱方式的讨论，你可以告诉大家一定不能允许网红自行植入软广，这样才能保证我们可以控制营销内容和普通内容的比例。
按照工作内容划分小组，并确定每个小组的成功标准、具体负责人，然后每个小组分别开会。这个小组划分的工作可以在项目启动会上完成。在这个案例里，你可以成立一个小组专门负责法律问题，小组成员包括律师、运营人员；再设置一个小组负责帮助网红适应和开启新的功能，小组成员包括用户体验分析师、负责增长的工程师、数据科学家等。
每周召集所有成员开一次会，有每个小组的负责人汇报工作进度，并解决他们遇到的问题。这样既可以满足其他成员了解整个项目进展的需求，增加他们的归属感，又可以减少每个决定需要的人员数量，提高会议效率。

组织成功产品需求会的秘诀

根据我自己的工作经验，以及所见所闻，我给你总结几个产品经理组织高效产品需求会议的秘诀。

精准管理开会的时间。在会议开始前，做好会议时间规划文档，精准到分钟，你可以采用上周数据更新（3 分钟，张娜）、产品测试结果（5 分钟，小王）这样的方式。
比如，第一部分由某工程师介绍功能开发计划，你给他规划的时间是 5 分钟。如果大家讨论无足轻重的细节问题或者快要到 5 分钟的时候，你可以礼貌地提醒大家注意时间。虽然这种方式打断了大家的讨论，但会议非常有效率，会后也没有人因为被打断觉得不被尊重。
以前我没有做会议时间规划时，不好意思打断别人，结果每次开会都有二十分钟甚至更长的时间在讨论无关紧要的问题，而且往往只有两个人针对这种问题争论不休，其他人都无所事事。但是，自从有了精确管理开会时间的文档，我可以非常礼貌地打断这种无关紧要的争论，并且他们会非常自觉地把这个问题留到会后单独讨论解决。

如果无法做出统一的决定，那就统一大家做决定的思考方式。这是一个可以让团队意见统一的迂回战术。
比如，开会的时候大家一直在争论到底是做 A 决定还是 B 决定，这样的情况我们可以先不讨论到底是选 A 还是 B。我们可以约定用更多的数据或者用户反馈来做决定，并统一做下一步决定的思考方式：如果数据达到 X% 我们就选择 A， 否则就选 B。
通过约定统一的思考方式，可以让僵持不下的两方取得统一意见，这种公允的决策方式可以取得两方人的信服。
我以前就遇到过这个问题，设计师、工程师虎视眈眈，公说公有理，婆说婆有理，谁都不肯让步，即使我更认同工程师的想法，也不能在这个时候直接怼设计师，否则这场争论不但不会停止，反而会扩大。但是，我采用“统一他们思考问题的方式”的迂回战术，那双方很快就点点头表示认可，问题随之解决了。
原因是什么呢？两个人的看法可以说都是对的，因为他们看重的情况不一样。但是，看完数据后，我和设计师说：“你的假设很有道理，但是通过数据我们发现，这种情况并不多见，所以综合考虑，我们决定做 XXX”。这时，设计师会点点头，表示认可。最终，和平就这么来了。

会议开始时先说明会议要达到的目的。
比如，在会议开始时，告诉大家未来的 30 分钟我们需要一起做出什么决定。那么当会议开始后，大家一般都会直奔主题，可以非常有效率的得到你想要的结果，会议成员也会觉得这三十分钟没有白白浪费掉。
我刚开始做产品经理时，就犯了一个错误。我组织了一个确定成功指标的会，但是没有和参会者说明会议目的，最终三十分钟的会议什么问题都没有解决。会后就有人跟我的老板反映，白白浪费了三十分钟，什么问题都没解决。被老板大骂一通后，我认识到了问题出在哪里，所以吃一堑长一智，在每次会议开始时先说明要达到的目的，这种问题就再也没有出现过了。

总结

接下来，我给你提炼一下本篇文章的要点。

我从一个失败的产品需求讨论会为切入点，跟你分析了造成会议低效的原因往往是：每次都邀请所有人参会，并让细节的讨论占据了太多的时间。因此，针对比较复杂的产品需求讨论会，你可以这样做：1. 一鼓作气，尽量通过一次会议解决，如果解决不了，就设置一个截止日期；2. 按照产品内容分成小组，然后各小组讨论，最后汇总。

我还跟你分享了我踩坑之后获得的独门秘诀：1. 精准管理开会事项，管理时间到分钟；2. 如果无法做出统一的决定，那就统一大家做决定的思考方式，尤其适用于两方僵持不下，各自都非常往心里去的紧张情况；3. 会议开始时先说明会议要到的目的，比如设定出产品路线图，或者确定产品成功指标，一定要明确这个目的。

思考题

回想一下，上一次你组织的或者参加的失败的产品需求会议，你认为会议效率低下的原因是什么？如果可以重新来一次，你会在哪些方面进行改进？欢迎你给我留言。

16 | 如何和工程师有效沟通？

工程师和产品经理之间的恩怨情仇，一直是科技圈茶余饭后久盛不衰的一个话题。“产品狗”摧残“码农”的故事、或者工程师吐槽产品经理什么也不懂只会乱提需求的段子屡见不鲜。那么，产品经理和工程师到底能不能和谐共处，成为一个战线上的好伙伴？

其实，一个优秀的产品经理不仅能和工程师有效合作，甚至可以让工程师觉得跟定了你，没你不行。

在硅谷，我们常说一个顶尖的产品经理每次跳槽，都能拉走一堆优秀的工程师，究其原因：一是，这样的产品经理确实不多见；二是，遇到一个好的产品经理，工程师可以把更多精力花到他们感兴趣的、有巨大影响力的方面，可以更有效率地做出优秀的产品。

优秀的产品经理能激发工程师的能动性

在硅谷的很多顶尖科技公司，都是 “工程师导向”的文化，也就要求产品经理不能像监工一样告诉工程师应该做什么。如果产品经理对工程师指手画脚，那工程师会顿时失去工作的兴趣，吵着嚷着要换组、换产品经理。

但是，一个真正优秀的产品经理能够让工程师兴奋起来，满腔热情地投入到产品开发中；而这种热情一旦被激发出来，产品经理就再也不用担心工程师会拖延工期、消极怠工，相反工程师甚至会比你更积极。

那怎么才能激发工程师的能动性呢？我至少和百位不同背景、不同资历的工程师工作过，在无数次“踩坑”后，我总结了下面的这些建议。

第一，作为产品经理，你应该知道这个工程师在乎的是什么。

他是一个刚毕业不久、满腔激情、想赶快升职加薪的工程师？还是一个想解决最高难度的技术问题，哪怕产品没人用，只要解决的问题难度足够高就高兴的工程师？还是一个满肚子主意，极其讨厌产品经理告诉他该做什么的“点子大王”？还是一个有些害羞、很多想法都憋在心里，但其实特别希望自己有存在感的人？

知道了他在乎什么，你才能知道怎么激发他的能动性，以及该让什么人做什么样的项目。

想升职的工程师肯定喜欢做老板能看得见的项目，哪怕这些项目没有多高的难度，帮助这些工程师在老板面前“出出风头”，他们肯定对你死心塌地。

技术宅？那你就给他们强调一下，这个项目的哪些技术问题是其他工程师想想就头疼、根本解决不了的，满足他们的虚荣心。

“点子大王”？那就找机会表扬他的点子又多又好，就算这个想法是你先想出来的，你也可以在和他交流时循循善诱，引导他说出你的想法，然后赞叹他的想法真厉害。
比如，如果你认为应该在视频平台上做一个让用户发弹幕的功能，不要直接和“点子大王”说：“你负责做弹幕”，而是要从问题出发，你可以说“我们的视频互动性太差，用户都不喜欢发评论”，然后引导他说出做弹幕的主意。

至于害羞的工程师，你可以在开会的时候刻意给他们表达自己的机会，他们绝对对你感激涕零，期待和你继续合作。

知道工程师要什么，想办法在现有的项目里给他们相应的机会，会让你们之间的合作事半功倍。 至于怎么知道工程师要什么，你不如和他约个时间喝杯咖啡私聊一下，了解他的个人情况，你甚至可以直接问他：“你是如何决定自己做的事情有没有价值的，你在乎的是什么？”

第二，产品经理应该知道怎么和工程师沟通最有效率。

很多工程师最讨厌的就是开会，因为 30 分钟的会议打断了他们的思考时间，拖慢了他们写代码的进度。

所以作为产品经理，虽然你每天要花很多时间在开会上，但是要考虑一下这个会到底有没有必要让工程师参加，可不可以安排到这个工程师其他会议之前或者之后的时间， 这样尽量少地打断他们的思考，以便于他们有效率地编程。

你还需要思考，除了开会之外，还有没有其他可以高效做决定的方式，比如发个邮件。

第三，产品经理要弄清楚什么决定需要自己领导大家做，什么决定可以放心地交给工程师们自己做。

比如，某个按钮是 100 像素还是 120 像素，类似这样的决定，是不是可以让工程师和设计师自己决定？

很多产品经理常犯的错误是，自己做出所有的决定，和工程师交流时只是要求他们按照指定要求来做，但实际上有些要求根本就不切实际。 更或者，按钮是 100 像素还是 120 像素，可能对于产品的成败来说，并不是最重要的决定， 你完全没必要在这种决定上花时间。

还有些产品经理只告诉工程师要做什么，从来不解释产品的目的、成功的标准，工程师完全不知道这些决定背后的策略和思考过程， 结果就是事事都需要产品经理告诉他们要怎么做。

其实，一个好的产品经理一定会清晰表达产品要解决的问题、如何衡量成功、需要最先解决的用例以及原因，让产品团队的工程师、设计师、数据科学家等都有足够的背景信息。 这样，很多的小决定完全可以让团队成员自己做，从而既可以大大提高产品效率，又可以提高团队成员的能动性。

当然，这并不是说产品经理什么决定也不用做，一个优秀的产品经理，会确保自己的时间花在“非我不可”的事情上，其他决定都会交给他人。设想， 如果一个产品经理把每天的时间都花在解决按钮是 100 像素还是 120 像素这种问题上，他们哪还有时间去和客户做一对一交流、制定产品战略、思考“脑洞大开”的新功能。

第四，产品经理应该帮助工程师解决开发过程中的一些困难。

很多工程师在开发过程中会遇到一些困难，比如因为其他组工程师进展缓慢而导致开发工作停滞，因为开发的新功能被律师认为风险太大而面临一些质疑，等等。因此，产品经理应该积极询问工程师：“你需不需要我为你提供一些帮助”，帮助工程师解决开发过程中遇到的障碍。

因此，帮助工程师扫清开发路上的各种障碍，可以提升你的产品开发效率，而这正是优秀的产品经理需要做的事情。 比如，我常常对工程师说：“现在有哪些工作是你不喜欢做的，告诉我，无论是脏活累活，我来帮你做”。其实，这也是一个帮助你和工程师建立信任关系的过程。

怎么催工程师加快进度？

这个问题是很多刚入行的产品经理最担心的，我的建议是，让工程师先自己估计需要的工期，然后再设定截止日期。如果他们预估的工期太长，我可能会提出一些问题，弄清楚为什么需要这么长时间，看看哪些部分可以砍掉，到底值不值得为截止日期砍掉这些功能。

工程师估计完自己需要的时间后，我会和工程师说明我们的发布计划， 比如某月某日营销团队会开始宣传产品功能、 某月某日我们需要开始运营工作等等，这样可以让工程师了解其他部门的进度，增强他们的归属感。

刚入行不久的工程师估计工期的能力比较差，如果他们的工期估计得太长，我就会想方设法让他们告诉我工期是怎么估计出来的，然后跟他一起讨论，哪些部分可以用现成的 API，哪些部分可以少花一些时间。

如果遇到确实要将截止日期提前的情况，我会告诉工程师需要提前的详细原因。这样做的目的是，让工程师觉得你和他是一起的，让他感觉到你的信任、你在思考如何一起解决工期提前的问题。

所以，我一般不会直接说要花多长时间，而是让工程师先估计工期，如果我觉得估计得过长，我会诚恳地告诉他我们需要加快进度，看看有没有什么方式能够重新组合一些计划，以加快工期。

在这里，一定要让工程师觉得自己是有掌控权的，而不是产品经理一拍脑袋，就决定个截止日期。 就算这个截止日期是你自己拍脑袋决定或者老板要求的，在表达日期的时候也要尽量体现出对工程师的尊重，用问问题的形式表达自己的看法，积极地和工程师一起寻求提前工期的方式。

产品经理常见的棘手问题：需要改需求怎么办？

改产品需求是一个非常常见的过程，有些时候前期计划做得很好，开始 Beta 测试时却发现，用户对某个功能根本不理解，还是需要改动。

其实，开发本来就是一个不断迭代的过程，所以应该首先认识到，产品开发不是产品经理闷头花几个星期写一个文档， 然后再抛给工程师让他们按照这个文档执行的过程。

但是，改需求并不代表产品经理可以在产品需求文档上胡写乱写，做出一些不靠谱的决定，这是在浪费工程师的时间。这里我就跟你说说有哪些方式能够避免在开发后期改需求，如果真的要改需求，如何和工程师有效沟通。

** 尽早和工程师进行产品功能设计的讨论，让他们提前了解各种背景信息。 **
我平时的工作方式是，先在产品需求文档中写明需要解决的问题、如何判断成功，并写几个产品方案的初稿，和工程师、设计师们进行讨论，回答他们的问题，让他们一开始就参与进来。
通过这个讨论过程，我可以知道有什么技术上的局限性，然后根据大家的反馈修改产品需求文档。这样可以避免在工程师花费大量时间后才发现问题，然后重新来过，导致工程师做无用功。

如果确实需要让工程师们重新写已经写好的东西， 或者砍掉他们已经写好的东西，一定要积极承担责任。
这种情况，可能是因为你作为产品经理少考虑了某些情况，也可能是突然发生了一些变故，比如公司改变了策略、竞争对手突然“搞事情”。虽然这并不一定是你的责任，但是这时你还是应该积极和工程师交流，主动承担责任，告诉他们：“这个赖我，辛苦你了”。
其实很多时候，就算产品经理自己主动承担责任，工程师也不会“顺杆爬”埋怨你，他们反而觉得你是个靠得住的好产品经理，甚至会过来安慰你。
积极承担责任，说句“抱歉，辛苦了”，虽然对你来说就是一句话的事儿，但这可以很好地安抚已经努力工作了一个月、每天加班加点儿的工程师。很多时候，给工程师们一些鼓励和温暖，虽然看上去微不足道，但却能让他们干劲儿百倍，对你死心塌地。

总结

最后，我来给你提炼一下今天的要点。

要做到和工程师的有效沟通，你作为产品经理需要做到：第一，知道这个工程师在乎的是什么；第二，知道怎么和工程师沟通最有效率；第三，弄清楚什么决定需要自己领导大家做，什么决定可以放心地交给工程师们做；第四，帮助工程师解决开发过程中遇到的困难。

接下来，我还跟你分享了怎么催工程师加快进度，以及怎么处理改产品需求这种常见的棘手问题，归纳起来不外乎这几点：第一，尽早和工程师进行产品功能设计的讨论，让他们提前了解各种背景信息；第二，积极承担责任，把过错往自己的身上揽，而不要抛给工程师；第三，要让工程师觉得自己是有掌控权的，而不是产品经理一拍脑袋就决定了截止日期和产品的需求。

思考题

你的一个工程师平日少言寡语，从不会主动表达自己的想法，会议的时候也不怎么发言，但是你在产品开发的过程中发现，他并不完全同意大家的决定，所以也不能很顺畅地执行，那么你作为产品经理应该怎么做？

你的一个产品功能，因为测试的体验太差，有被砍掉的风险，而这个主意是你自己提出来的，你会怎么和工程师沟通这个糟糕的结果？

你的一个工程师鄙视你没有工程背景，在做决定的时候并不信任你提出的建议，你该怎么取得他的信任？

欢迎你给我留言。

17 | 如何与设计师有效沟通？

虽然，产品经理和工程师之间的恩怨情仇是科技圈讨论得最多的话题，但实际上，我刚入行时和设计师的关系是最有挑战、最让我最头疼的。

在和设计师交流这件事上， 我花了很多精力、也得罪了不少设计师。痛定思痛，我总结出了一些可以和设计师高效沟通的方式，希望这些建议可以成为你和设计师们沟通的“润滑剂”。

设计师的艺术家型人格

我刚入行时，有个设计师对我的意见很大，他认为我每天风风火火、节奏太快，让他感觉太紧张、工作压力太大；而我却觉得这个设计师慢慢悠悠，在很多根本不重要的小事儿上浪费了太多时间，影响了整个团队的进度。

后来，老板对我说：“设计师是艺术家，艺术家都是完美型人格。他们在乎的是用户体验，而不是具体的数据指标提升了几个点，你要试着和他们换位思考。”这句话点醒了我。

之前，我对设计师的方式和对工程师一样，简单粗暴、直戳要害，直接告诉他们我要什么、为什么要这么做、提升的是什么数据、增长的是什么指标。在这件事之后我意识到，很多设计师并不在意具体的数字指标，在他们看来，提升了 5% 又怎样，这个按钮的配色有问题，看着别扭就绝对不可以用。

其实，很多优秀的产品设计大都源于设计师的艺术家型人格，这也就决定了设计师的角色在产品团队中不可或缺。因此，作为产品经理，时刻谨记“设计师都是艺术家”，实现和设计师的高效沟通是非常重要的。

然而，在和设计师沟通时的方式，也要具体情况具体分析。在我看来，和设计师新人、老手打交道是很典型的两种不同方式。

设计师新人和设计师老手的沟通技巧

在一个产品团队，设计新人一般只负责产品具体的一个功能，产品经理要把产品要求甚至每部分做成什么样都写得一清二楚。这样，设计新人才能把产品经理制定的产品计划、产品体验，转化成具体的设计图。

和设计师新人打交道时，需要注意以下三个问题。

他们不具备产品思考能力，也不能从头设计一个产品。
产品经理需要帮他们理清头绪，最快的方式就是直接告诉他们要做什么，让他们照着做。但是这样的问题是，设计新人总是需要成长，总是需要具备从头开始思考产品和体验的能力，所以你也需要给他们成长的空间，比如选取一部分时间不紧张的功能让他们从头开始设计，然后积极地给他们反馈。

如果不把产品功能的范围讲清楚，他们会抓不住重点。
比如，明明一个按钮就可以解决的问题，他们会设计得过于复杂，导致工程师工期太长；再比如，他们设计了太多的功能，然而这些功能我们都可以先不做，产品发布后，看市场的反应再决定需要增加哪些功能。
所以，对设计师新人来说， 产品经理应该尽量帮助他们弄清楚这版产品应该涵盖哪些功能，哪些功能现在是不必要的。这样的沟通，最好在他们设计过程中进行，而不是等他们花了几个月、设计了一堆功能之后，才发现大部分功能现在看来都是不必要的。

他们估计工期的能力非常差。
比如，他预估一个星期可以完成这个功能，但在设计时总感觉哪里不够完美、哪里又需要增加一些功能，导致一个星期的设计工作却拖了好几个星期没能完成。
所以，对于新人来说，产品经理需要提前告诉他：“这个设计一定要在一周之内完成，你可以在开始设计前，先写一个设计场景列表，我可以帮你看看，咱们确定好列表内容后你再开始。”

相对于没有经验的设计师新人来说，老练的设计师可以设计范围很广的产品或者产品线。 比如，他们可以设计一套从头到尾的用户体验，甚至设计一系列产品，或者完成公司全部产品的系统设计概览（比如，Facebook 中朋友圈和视频里的评论，就是一套设计体系）。

设计老手可以解决模糊的产品问题， 比如你告诉他，我们得设计一个面对面加好友的新方法，他就会设计出具体的功能和应用场景，而无需特别强调用二维码加好友的方式。

因此，设计老手在你的团队，就意味着你无需把产品需求文档写得非常详细，比如不用具体说明某个按钮应该是什么样子的，但是你一定要写清楚产品要解决的问题、衡量成功的方式、第一版和第二版产品功能之间的路线图，这些内容适用于所有设计师。

设计师和产品经理发生矛盾的常见原因

设计师喜欢连贯与和谐，产品经理却要考虑开发效率，需要分析具体场景下连贯性是不是重要。
有一次，我需要设计师重新设计所有的菜单列表，这个菜单列表涉及到三个场景，每个场景的样式都不一样，但只有一个场景的用户浏览量比较高。﻿
在设计师看来，需要统一这三个场景下菜单列表的样式，这需要花费很多的时间。而在我看来，不常用的两个菜单列表可以直接砍掉，根本不值得浪费时间。
于是，我试图用这个菜单列表在三个场景下的用户浏览量数据来说服设计师，结果他很生气，认为数据不能代表完美的用户体验，为此我和设计师闹得很不愉快。
后来，我针对三个菜单列表的样式需不需要统一的问题进行了用户调研，用户直接说：“那两个场景我都不用，我不在乎它们的样式统不统一”。我把用户反馈告诉设计师后，他就很痛快地采取了我的意见。
从这件事中，我得到的启发是：作为产品经理，你要清楚设计师的完美型人格，他们往往更看重功能间的和谐、连贯，所以你需要主动地思考他们敏感的点是什么，比如用户反馈往往比数字更能让他们信服，以掌控产品的设计进度。

不同风格的设计师，针对不同的项目，对产品经理的期待不一样。
同样一份产品需求文档，有的设计师认为功能描述太具体，限制了他们发挥的空间；有的设计师却认为不够具体。这是我刚做产品经理时感觉非常苦恼的一个问题，在和设计师打了多次交道后，我才明白了“众口难调”的原因，以及怎么处理这种情况。
在我看来，处理这种问题最直接、最高效的方式是，和你的设计师搞好关系，问问他们是喜欢文档中功能描述写得清楚些，还是只要给出策略性的建议就可以了。
你可以在每个项目的文档中先写策略性的内容，然后对设计师说：“这是咱们产品的策略和大致想法，你先看看有哪些部分不够清晰，我来写得更具体一些。”只有多沟通，才能更高效。

出于工期等原因，产品经理不得不砍掉设计师的完美设计蓝图中的一些功能。
我们的一个产品，计划用一周的时间设计，两周的时间开发。但是，设计师灵感大发，从现在到未来，设计了一大堆现在不必要的功能，因此我不得不砍掉设计图中的大部分功能。
这时，我就很直接地跟设计师说：“你这个设计图中的功能太多了，我们现在只能实现里面的 2 个功能，其他几个功能的设计都要砍掉”。结果设计师非常生气，觉得自己的“完美设计”没有得到应有的尊重。
总结一下，作为产品经理，我在这里踩了两个坑：第一，我应该在设计过程中多和他沟通，这样就可以避免他在不必要的功能上花费过多的时间；第二，我和他的沟通欠缺技巧，让他感觉自己的努力没有得到尊重。
设计师的完美型人格，往往会让他们的设计过于理想化，而且他们的自尊心和对自己作品的保护意识都比较强。所以，一定要在设计中多沟通，而且沟通时要站在设计师的角度考虑充分。
因此，如果是因为没有及时、充分地和设计师沟通，导致他花了很多精力、做了很多不必要的功能，那在砍掉他的设计时，一定要注意沟通方式。你可以先感谢他考虑充分，完成了产品短期和长期的蓝图，然后告诉他我们现在工期紧张，只能先完成其中两个功能，剩下的功能要等产品发布之后再实现了。

总结

通过今天的文章，我希望告诉你和设计师沟通的有效方法。

产品经理和设计师的很多冲突来源于不同的价值观，设计师是艺术家型人格，他们更在乎功能间设计的连贯性、对数字不是特别敏感，而产品经理大多雷厉风行、结果导向，所以二者自然就存在一些冲突。

要解决这样的冲突，首先是要意识到设计师菜鸟和老手之间的区别：对于设计师菜鸟，要帮助他们弄清楚要解决的问题以及产品功能的范围，控制设计的工期长度，并提前告诉他们哪些功能不重要可以先不设计；对于设计师老手，更多的是要给他们发挥的空间， 但是同样要沟通清楚产品解决的问题以及成功指标。

最后，我跟你分享了产品经理和设计师冲突的主要原因。设计师追求完美、和谐，产品经理要和设计师多沟通，控制好他们的设计范围，帮助他们避免设计太大而导致无法按期开发的情况，需要砍设计时更要注意方式方法。

思考题

你身边的是设计师都有哪些特点？在和这些设计师沟通的过程中，你都踩过哪些坑？

欢迎你给我留言。

18 | 如何搞定A/B测试？

A/B 测试，是用两组及以上随机分配的、数量相似的样本进行对比，如果实验组和对比组的实验结果相比，在目标指标上具有统计显著性，那就可以说明实验组的功能可以导致你想要的结果，从而帮你验证假设或者做出产品决定。

小到一个按钮用红色好还是用黑色好，大到有没有朋友圈这个功能对微信日活数的影响，都可以通过 A/B 测试来解决。

你可能会认为，A/B 测试很简单啊，只要需要对比一个功能添加前后的指标变化，我就可以进行 A/B 测试。但是，错误往往隐藏在你认为最不容易出错的地方，因此如果你想最大程度地发挥 A/B 测试的作用，你就需要绕过一些“坑”。

那么，今天这篇文章的目的，就是结合我在硅谷做产品经理的经验，帮你绕过这些“坑”。

进行 A/B 测试前，你必须明确要测什么、如何测的问题

无论采用哪种测试方法，你都必须在产品测试前弄清楚要测试什么、如何测，这就要求你在设计产品时要先从问题出发做出假设。

比如，你可能会说：“微信中‘加好友’这个按钮不好找，导致用户加好友的次数不够，我认为把这个按钮从屏幕上方改到下方，可以让体验更顺畅，以增加用户加好友的次数”。

这时，你已经明确了需要测试什么、如何测，以及用什么指标来衡量的问题，那接下来就可以进行 A/B 测试了，通过对比“加好友”这个按钮在屏幕上方和下方时，用户使用次数的数据指标，来验证你观点的正确性。如果把这个按钮改到屏幕下方后，用户使用频率增加了，那就可以说明这样的改动达到了目的。

但是，如果你还不能 100% 清楚你要改变的是什么、提高的是什么，以及用什么指标来衡量，那么 A/B 测试并不适合你。

验证因果性的唯一途径是 A/B 测试

这里，首先需要明确相关性和因果性是两个不同的概念。

因果性是指，因为有 X，才会有 Y。比如，因为用户没有内容可以看，所以他们流失了。而相关性是指，X 变化会导致 Y 变化，但是不能明确 Y 的变化是由 X 的变化引起的。比如，你发现没有内容可以看的用户，流失的比例更高， 但是你不能确定是因为没有内容可以看，所以他们才流失的。

下面，我就通过一个实例给你讲解一下，A/B 测试是如何验证因果性的。

我们做了一款 APP，数据显示启用了“隐私设置”的用户中，活跃用户的比例比较高。单单这个数据，只能说明用户活跃程度和“隐私设置”功能具有相关性，而不能说明这二者之间的因果关系。

这里的相关性是指，启用“隐私设置”功能的更可能是活跃用户，而不能确定说“隐私设置”功能可以提升用户的活跃程度。而因果性，就是明确了用户开启“隐私设置”功能后，就可以提升他们的活跃程度。

你可能会问，这个因果关系是怎么形成的？那我给你举个例子，比如用户启用了“隐私设置”功能后，他们可以控制谁能看到他们的内容，而不用再担心被不相关的人看到，所以他们会更放心、更大胆地发新内容，也就变得更活跃了。

那如何通过 A/B 测试，验证用户活跃程度和“隐私设置”功能间是否有因果关系呢？

你可以这样设计实验： 实验组用户可以使用“隐私设置”的功能，而对照组用户无法使用这个功能，其他实验条件完全一致。结果，A/B 测试显示，“隐私设置”并不能提升用户活跃程度，二者并没有任何因果关系。而活跃用户启用“隐私设置”的比例比较高，原因竟是这个按钮不好找。

在这个例子中，如果你没有进行 A/B 测试，而草率地下决定，把“隐私设置”的按钮做得非常大， 鼓励更多用户启用“隐私设置”以提升他们的活跃程度，那最终的结果就是花费了大量的时间改设计、重新开发，却是“竹篮打水一场空”。

但是，如果 A/B 测试的结果证明，用户活跃程度和“隐私设置”有因果关系，那么你就可以很自信地把“隐私设置”的功能设计得尽可能得显眼，以提升用户活跃度指标。

通过这个例子，我想告诉你，某些功能的优化可能需要整个产品团队花费很多的时间、精力去改设计、重新开发，但是优化后并不能达到预期的效果，这种情况下，你可以先进行 A/B 测试，验证这个功能的优化与指标提升是否具有因果关系。在我看来，这就是 A/B 测试的魔力，它可以帮助你做出科学、合理的产品决定。

明确到底需不需要 A/B 测试

A/B 测试适用的场景是，你的产品功能有多种选择，而你需要通过数据做出选择，这也就意味着并不是所有功能上线前都要经过 A/B 测试。现在，我就跟你分享两种不适合 A/B 测试的情况。

第一种情况是，无论新功能上线后的数据怎么样，都要发布这个新功能，这时你要做的是如何优化用户体验，而完全没有必要进行 A/B 测试。 比如，一些功能是法律规定的，或者是属于公司策略性的，这些功能无论如何都要发布。

第二种情况是，样本数量太少，不能通过 A/B 测试得出合理、科学的结论。

比如，你要测试某个按钮的颜色设置为红色、绿色、蓝色，还是紫色的效果好，那么进行 A/B 测试时，你就需要至少 4 组对比实验，而且要确保每一组实验都有足够的样本数量来保证对比结果具有统计显著性。

如果这个按钮一共才 20 个人用，每组只有 5 个用户，那么得出的实验结果必然带有很大的偶然性，你无法根据这个实验数据做出科学的结论。这种情况下，你如果还要通过 A/B 测试做产品决定，那你就必须增加样本数量。

那么需要达到什么样的实验样本规模，才可以进行 A/B 测试呢？ 这个问题没有一个明确的答案，往往取决于你的产品实验组和对比组之间的区别到底有多大。

比如，Facebook 的朋友圈（News Feed），它是世界上最大的信息流产品，如果增加一个新功能可以让日活数增加 1%，那这个功能就是巨大的成功。这时，A/B 测试需要的样本数量就非常大，才能保证这 1% 的进步具有统计显著性而不是误差。

但是，很多创业公司，它们的产品思路还没有定型，产品功能千变万化，有时一个新功能的发布可以将产品指标提升 100%。这种情况下，即使没有那么多的样本数量，你也可以肯定这个新功能可以给产品指标带来质的飞跃。

短期数据 vs 长期数据

如果微信的“摇一摇”突然出现在了微信开启页面里，那我可以肯定，“摇一摇”功能的用户使用量会直线上升。

这时，设置一个 A/B 测试。实验组的“摇一摇”设置在微信开启页面，而对照组的“摇一摇”依然保留在“发现”页面，短期内肯定是实验组的数据更好看。但是，如果你根据前两天的数据，就直接得出“摇一摇”在微信开启页面的效果会更高的结论，那我会觉得你这个产品经理是不可信的。

为什么呢？因为你没有意识到新功能的短期新鲜感和长期的生态系统影响。微信开启页面突然出现“摇一摇”的功能，用户使用数据会因为刚开始的新鲜感而非常好看，用户这时正在劲儿头上。但是，这个“好看”的数据可以延续么？

在我看来，并不是每个新功能或者产品都可以延续这样的势头，大部分产品的新鲜感只能持续一个星期，最多一个月。新鲜感的劲儿头过后，产品的数据会直线下降，可以说是成了“扶不起的阿斗”，再也提不上来了。

很多产品经理就是踩了这个坑，因为前几天“好看”的数据过早的下了结论，最终产品发布后的表现远不如预期得好。

所以我的建议是，在判断一个功能是不是值得发布时，你应该等至少一个星期、短期的新鲜感褪去后， 再衡量是否值得发布。

另外，如果你通过 A/B 测试的结果决定要发布这个产品，我还建议你应该留一个长期的对比实验组，比如 1% 的用户无法使用新产品，来观察这个产品对整个生态系统产生的影响，并适时作出调整。

我给你举个简单的例子，假如 Instagram 要增加一个给好友点“超级赞”的功能，目的是提高用户分享的频率。刚开始用户的活跃程度确实提高了，因为有了“超级赞”， 他们发新鲜事倍儿有精神，分享数量大幅度提升，短期数据棒极了。

但从长期来看，增加了“超级赞”的功能后，用户会因为只是得到了“赞”而没有获得“超级赞”，而感觉自尊心受损，最终不愿意也不敢分享了，所以从长期来看是数据下降了。

总结

今天我跟你分享了 A/B 测试需要注意的问题。

首先，你要弄清楚要测的是什么，并且要 100% 清楚可以用什么指标衡量两组实验的区别。

其次，验证因果性的唯一途径是 A/B 测试。

再次，要判断是不是需要 A/B 测试，如果每一组的样本数量不够，或者这个功能无论如何都要发布，那么 A/B 测试并不是最好的方式。

最后，A/B 测试需要考虑短期新鲜感和长期的生态系统影响。你可以保留一个长期的对比组，这样可以在产品发布之后也有较长的 A/B 测试时间，从而观察产品的长期表现，适时作出决定。

思考题

你有没有经历过哪些产品（或者功能）的短期数据很好看，而长期数据却不好看？出现这个问题后，负责的产品经理是怎么处理的？

欢迎你给我留言。

19 | 增长黑客的核心公式

作为即将开始的产品增长系列的第一篇文章，这篇文章的主旨是如何利用增长黑客实现产品的增长。

“增长黑客”这个词最近特别火，这个概念最初是由互联网创业者肖恩 · 埃利斯（Sean Ellis）提出的，他希望能够做到“把钱花在刀刃上”，创新性地实现增长。近几年，硅谷的各大公司都已经建立了自己的增长黑客部门。

很多人听到这个词，觉得既然是“黑客”，一定是潜入什么神秘的系统，利用看不见摸不着的、神秘的方式实现增长，事实是否真是如此？今天我们就一起来看看到底什么是增长黑客，以及如何利用增长黑客实现产品增长。

什么是增长黑客

以前的产品增长主要靠砸钱，而增长黑客是用技术和数据来分析如何增长，找到影响增长的切入点，然后精确执行，从而实现病毒式增长。

在硅谷，不同公司的增长黑客团队的规模不同，部门划分也不同。

比如，我之前工作过的 Atlassian 把负责增长黑客的专家划分到了市场营销部门；而在 Facebook，我们有很多的增长黑客专家，他们中有些人做的工作很像数据科学家，所以就和数据科学家并到了一起，另外的增长黑客专家则并入了专门的增长团队，他们直接汇报给增长团队的领导。

但是，无论部门怎么划分，增长黑客团队的任务，都是和产品团队、营销团队、数据团队并肩作战，通过分析数据趋势找到产品方向，利用营销技巧实现产品增长。

增长黑客的核心公式

增长黑客的方式有千万种，但是万变不离其宗，它的本质就是下面这个核心公式：

增长 = 新增 + 留存 + 挽回（Growth = Acquisition + Retention + Resurrection）

这个公式可以套用到很多场景中，最典型的两种应用就是，提升产品的用户活跃指标和规划大型公司的增长团队的架构。下面我将针对这两种典型场景，分析一下这个公式的使用方法。

提升产品的用户活跃指标
如果你的目的是增长 APP 的活跃用户数量，那么让更多的用户下载这个 APP，就是新增；让已经下载的用户能够继续使用，就是留存；让已经删掉 APP 但是注册过的用户重新下载并使用，就是挽回。
如果新增的数量非常多， 但流失的数量却远远超过新增的数量，那么不管你通过什么方式（比如，优化搜索引擎，或者赞助更多广告位来扩大宣传力度）让更多的用户下载这个 APP，最终的活跃用户数都不会好看。
所以，作为产品经理，如果你发现产品的用户活跃指标就是上不去，你首先应该分析新增、留存和挽回这三个方面， 看看短板到底在哪里，从而制定出不同的策略。

规划大型公司的增长团队的架构
如果你的公司已经很大了，现在要建立自己的增长团队，你也可以按照增长黑客的核心公式来规划增长团队的架构。
我在 Instagram 工作的时候，它的增长团队的架构就是按照增长黑客的公式进行划分的，包括了新增团队、留存团队和挽回团队，每个团队各司其职。
新增团队，主要负责搜索引擎优化、APP 下载广告，鼓励用户分享给其他朋友下载 APP。
例如，Instagram 以前通过 Facebook 引流，用户通过 Facebook 可以直接获得 Instagram 的下载链接。Facebook 还开通了一键邀请通讯录好友的功能，帮助 Instagram 吸引更多的新增用户。
另外，许多明星特别喜欢使用 Instagram，所以很多娱乐新闻都是由 Instagram 曝出的，这些新闻也激起了用户下载 Instagram 看原文的兴趣，这种方式也为 Instagram 带了很多新增用户。
留存团队，主要负责研究用户为什么会在使用一个月后就流失了（比如，可能是这些用户没有关注其他内容，或者他们的朋友没用这个 APP 所以他们用起来也没意思），通过找出用户流失的原因来提升用户的留存数量，让更多的用户在使用一个月后可以持续使用这个 APP。
挽回团队，负责让不再活跃的用户重新下载或者重新开始每周登录 APP，他们通常采取的方式是给用户发消息、邮件，或者举办一些用户活动等。
之前交友 APP Tinder 刚起步时，就是通过办派对的方式，让每个学校最好看的姐妹会成员们加入 Tinder，漂亮女生来了，就不用再发愁男生不来了。

明白了什么是增长黑客，以及它的三大要素，那么如何才能将“增长黑客”这一武器应用到实际的产品中呢？

增长黑客实例

现在，我给你举几个例子，你可以从中思考一下，“增长黑客”的理念如何应用到具体的产品上。这些案例的目的，不是要给你提供几种可以直接借鉴的产品增长方式，而是要让从中体会增长黑客的核心公式的用法，授人以鱼不如授人以渔。

我先给你讲讲领英是如何通过新增、留存和挽回来实现产品增长的。

因为工作关系，我经常使用领英。领英也会时不时地给我发消息，告诉我最近谁又浏览了我的主页，但是只给我显示三个人， 如果我想看到所有浏览我主页的人， 我就需要购买它们的会员。这就是领英的新增团队在发挥作用了。

当我花钱买完会员后，领英会每个星期给我发邮件告诉我谁浏览了我的主页，这些人来自什么公司；最近哪些公司的人看我的主页比较多，他们是 HR 还是产品部门的负责人；以及，我在这个圈子里的被浏览次数是什么水平等等。这些信息，让我体会到了成为会员可以享受的增值服务， 这就是领英的留存团队负责的内容了。

之后我发现领英的会员太贵了，而且我感觉享受到的服务不值这个钱， 于是我就不再订阅了。随后的几周时间里， 我收到了很多来自领英的邮件，告诉我可以打折购买会员，或者他们正在举办什么活动，如果我现在马上加入会员的话可以得到很多福利。每当看到这些邮件，我就知道领英的挽回团队又在加班了。

如果你认为，成为了会员，领英增长团队的工作就结束了，那我会觉得你这个产品经理还欠缺点儿火候。接下来，你可以看看领英是如何吸引已有会员升级的。

我刚刚购买了领英会员不久，领英就给我发了一封邮件，鼓励我从月度订阅升级到年度订阅，并且开始向我推销更贵的会员服务，这就是它们的新增团队瞄准了已有客户之后，刺激用户增加消费。

仔细看这封邮件的界面，你可以看出领英做了些功课，它有意把后两个升级选项设置成了按钮的形式，让你升级为更高级别的会员。所以，产品细节上的优化，往往可以提升整个产品的体验，从而促进产品的增长。

我再给你举个 Netflix 的挽回团队工作方式的例子。当用户停止使用 Netflix 后，它会给用户发邮件，说我们新增了很多获奖影片、电视剧，你都看不了好可惜啊，我们让你免费再使用一个月。

这其实就是一个不错的挽回策略，很多收到邮件的用户都会选择继续使用，这部分用户中又有很多会继续花钱购买会员。

其实，领英和 Netflix 采用的产品增长策略，是一些比较常规的方式，效果也是中规中矩。还有一些产品采用的增长策略，采用了一些创新型的“野路子”，达到了事半功倍的效果。下面，我就给你分享几个利用“增长黑客”的理念实现产品增长的小技巧。

社交推荐
拼多多就是一个典型的例子，它的新增团队利用微信群实现了病毒式增长。
前段时间火热的百万英雄，你如果成功推荐了新用户，它就会送你一条命，这一招的效果非常好。它是抓住了用户在“Game Over”的情况下，想要续命继续的心理，所以采用这种“雪中送炭”的方式可以刺激他们推荐给其他朋友。
另外，【极客时间】APP 有一个功能，就是可以把你付费购买的课程中的文章分享给朋友，上面会写“曲晓音花钱请你看××××（某篇文章）”，这样你的朋友觉得占了便宜，你自己也会觉得有面子。
如果你的朋友读完了这篇文章，觉得不错，自然就会购买课程了，这种方式就比普通的“推荐好友，给你打折”这样的手段要高明得多。
所以，你可以思考一下，有哪些方式可以让用户有动力把你的产品推荐给自己的好友，这个推荐方式可以让用户解决燃眉之急，或者让他们觉得倍儿有面子。

互相借流量
美国的很多网红惯用的方式就是互相分享彼此的视频，你如果让一个百万粉丝的网红分享你的视频，你就有可能增加百万级的流量。新浪微博的转发，就是利用了互相借流量的方式。
关于这一点上，你也可以思考一下可以和哪些 APP 互相导流，促进双方的增长。但是，这种方式对引流增加新增用户有很大帮助，但是并不怎么适用于留存和挽回的情况。

集邮
集邮是一个很好用的留存技巧。我记得小的时候，我会为了集齐水系小精灵买各种各样的宠物小精灵的卡，相信你也有过这样的体验。
之前火遍美国的 Pokemon Go，就是利用了这样的方式。你如果想要集齐宠物小精灵，就要不断刷不断玩。 玩了很久之后，你会发现还差两个小精灵就集齐了，于是只能继续拼命玩，并祈祷上帝可以让你拿到缺失的两个小精灵。

另外，集拉环中大奖，也是采用的同样的方式，目的都是为了增加重复消费，提高留存率。这样的方式是利用用户想要尽善尽美的心态，让他们存有抱憾感，他们就会一直尝试一直尝试，从而增加活跃度和留存率。

抽奖
这是一个屡试不爽的招数，既可以用来增加新用户，又可以增加留存率，甚至可以挽回用户。抽奖规则是由你制定的，你可以根据产品目标量身定制规则，所以这种方式可以满足不同的增长需求。
比如，王者荣耀的抽奖活动。它们的规则是：你在邀请朋友后，可以获得抽奖机会，这样做的目的是为了提高“新增”；也可以让你在连续玩 10 天后抽奖，这种方式就是通过提升“留存”的方式提升整个产品的用户指标了。

社交推荐、互相借流量、集邮和抽奖，是目前比较有效的几个实现产品增长的方式，你也可以灵活运用到你的产品中，但我更多的是希望可以起到抛砖引玉的作用，拓展你的思路，帮你想出更有意思、效果也更好的产品增长策略。

总结

从这篇文章中你可以看到，增长黑客其实就是围绕着增长 = 新增 + 留存 + 挽回，这个公式展开的。

有了这个公式以后，当你发现产品增长乏力时，就可以分析产品增长停滞具体是由哪个方面引起的，然后对症下药，制定高效的产品增长策略。

另外，很多大公司都会按照这个公式把自己的增长团队划分为新增、留存和挽回三组，各个团队可以针对明确的目标，制定自己的增长策略，促进产品增长。

如果你在小公司，增长团队没有这么大的规模，你也可以借鉴这种方式把你的增长工作分成新增、留存和挽回这三部分，明确你制定的每一项增长策略分别可以从哪个方面实现产品增长。

思考题

抖音在增长方面都做了哪些工作，分别属于增长黑客核心公式的哪一部分？

欢迎你给我留言。

20 | 想要增长，你的团队需要高效的工作流

产品增长是产品成功的必经之路，也是最最重要的部分，而迅猛的增长离不开优秀的增长团队。

但是，并不是只有专门负责增长的产品经理或者增长黑客专家才能帮助产品实现增长，每个产品经理都有责任让自己的团队具备产品增长的能力。所以，我会在这篇文章中，给你分享如何设置团队的工作流程，才能最大化团队的增长能力。

让团队的所有人都明确要增长的指标什么

让团队成员明确要增长的指标到底是什么，这个问题看似容易，但即使是硅谷顶尖科技公司的产品团队，都没有做到这一点。特别是在大型公司，每个团队负责一个细分领域，很多时候大家各自专注于自己的日常工作中，往往会忽略了思考自己的工作到底是提升了公司的什么指标，是如何帮助公司的。

比如，你的团队在视频部门负责捕捉违规内容，那么你们要提升的指标可能是捕捉的准确率，也可能是对捕捉内容类别（成人内容、诈骗内容、违法内容等）的覆盖率，这个时候团队成员很可能就乱了方向，不清楚要增长的到底是什么指标。

这个时候，就需要你对大家说：“现阶段我们需要提升捕捉的准确率，提升我们的监管能力，这样才能确保其他团队把更多的网红吸引到我们的平台上。但是，我们现在只是吸引美女网红， 所以成人内容可能需要多加注意。” 这样的方式，既明确了团队的增长目标，又可以提醒团队成员要兼顾的问题，从而实现产品健壮有力的增长。

在这里，产品经理需要注意的是，不要怕啰嗦，可以重复重复再重复，一定要达到任何一个团队成员都可以不假思索就能回答出来的程度。

组织专门的增长讨论和分享会议

如果你的团队经常通过 A/B 测试来决定发布哪个版本，那么你就需要一个增长实验讨论会。

这种会议常见于负责核心体验的团队，比如 Facebook 中负责信息流核心体验的团队，他们稍微把新鲜事的行距改一改，都会影响用户的使用产品的时间，所以每个新功能都需要 A/B 测试，这时组织一个增长实验讨论会就非常必要了。

一般这样的讨论会用一个 Excel 文档，记录所有的小实验，比如按钮颜色的改动，行距的改动，甚至信息流推荐算法的每一个新版本，对应负责人，实验发布时间，实验涉及百分之多少的哪个国家的用户，实验结果是什么，实验界面的链接等等。

你可以在这个 Excel 文档中，用颜色表示实验成功与否，一目了然。我比较喜欢用绿色表示实验成功，可以发布给所有用户；黑色表示实验失败，肯定不能发布；黄色表示实验正在进行中；红色表示实验正在开发中。

这样的增长讨论会，我们每周开一次，讨论上周发布的实验的结果，本周开发完毕的实验该发布给哪些用户进行测试，计划下周应该做什么新的增长项目。

这里有一点需要注意，很多产品的功能虽然很酷炫，但就是对用户指标没有积极作用，所以注定了实验会失败，这个功能会被砍掉。

但是，有些工程师和设计师不能正视这些不理想的实验数据，他们会想方设法地掩盖或者编造数据企图蒙混过关。但是，进行 A/B 测试的正确心态是，要像科学家做实验那样严谨，只有这样才能找到真相，实验失败也可以帮助团队成员找到新的、更准确的方向。

除了增长讨论会，我们还会组织分享增长的会议，因为有些增长方法可以举一反三，应用到其他场景中。这个会议上，大家可以分享每个实验的具体数据，也有数据科学家分析从最近发布的几个实验中找到了什么共同点，以及其他部门的增长实验有什么心得。

比如，当你发现在推荐算法中增加用户最近浏览内容的权重，而不只是关注用户一共看了相关内容几次，可以增加用户的使用时间。信息流推荐系统的工程师发现这个方法管用的时候，可以推荐给其他团队。

这种分享的好处是可以节省大量的试错时间，一个“坑”只由一个团队趟一次就够了，整个公司的所有团队都可以借鉴经验，以免多次重复同样的错误。

总结一下，增长讨论会和分享会的目的是，和团队成员高效地评阅实验结果，砍掉表现不好的功能；对于表现好的功能，一起制定下一步发布计划；对于一些需要权衡取舍的问题，比如一个核心指标上升了，但是另一个指标却下降了的情况，给团队成员讨论的机会，一起作出产品决定。

为团队配备增长大屏幕

在 Facebook，每个团队都配有一个大屏幕（一般就是一个巨大的显示屏），上面会显示我们最在乎的数据是什么。这样做的最大好处是，吸引团队成员的注意力。试想一下，你每天上班都看到你最在乎的是什么数据，那就相当于每天都在你的潜意识里强化这个关键点，无形中就提升了整个团队的工作效率。

另外，大家每天开站会时都会看到这个大屏幕，了解我们的核心数据表现如何，有没有什么奇怪的现象。比如，某个数据突然暴跌，是不是出现了 Bug；又比如，某个数据今天突然暴涨，是不是因为今天是节假日，大家都在家，所以使用 APP 的用户一下子就多了。

我们还有增长报警系统，如果数据暴跌的情况超过了某个限定值，那么系统就会自动给对应的工程师发邮件警报，大屏幕的字也会变为红色大字。这样做的目的是，方便大家第一时间注意到问题，并灵活安排手头的工作，优先解决这个新问题。

给团队成员培训增长基本功

所有的设计师都应该了解基本的增长技巧， 比如按钮设计成什么样用户更容易点击，怎么设计提醒消息用户更容易注意到。所有的工程师也应该知道基本的增长公式，即使他们不在增长团队。

我之前负责的产品团队，重点在开发新产品，还没有把产品增长作为重点。这时， 我发现不懂增长的工程师不知道如何权衡取舍自己手头的任务，不懂增长的设计师只追求好看，不在乎也不知道如何提升用户体验。而且，我给这些工程师、设计师提意见时，他们也不能充分理解为什么要按照我的方法来。

后来，我邀请了增长团队的专家给他们讲授增长经验。在这之后，我发现他们工作起来更能关注用户体验，更能思考如何一步步提升产品指标，我跟他们交流起来更顺畅、工作效率也更高了。

因此，我给你的建议是让团队的每一个人，包括营销人员、设计师、工程师、用户体验调研师等等，都上一堂增长课。因为增长是每个人的责任，不能仅靠产品经理一人“瞎吆喝”。

总结

今天，我主要跟你分享了如何设置工作流程，让你的团队成员高效地为产品增长而服务。

首先，产品经理要让团队的所有人知道要增长什么，并且每周重复，直到让他们倒背如流。

其次，建立专门的增长讨论和分享会议，鼓励分享和尝试，要有条理地管理好所有的 A/B 测试并记录结果，和团队成员一起讨论作出权衡取舍的决定。这种方式可以有效地管理团队同时进行的多个实验，也是团队成员通过看其他人的实验成败避免再次踩坑的最好方式。

再次，增长大屏幕可以让大家每天都看到产品数据，潜移默化地提升整个团队的产品增长能力。

最后，要注意培训你的团队成员，不管他们的本职工作是什么，让他们都具备增长基本功。

思考题

在这篇文章中，我提了很多提升团队增长能力的建议，哪些建议不适用于你的团队，哪些建议是你马上就可以尝试的？

21 | 换个按钮颜色， 就能增长百万用户？

作为今天文章的开始，我先给你分享一下，硅谷最神奇的产品经理是什么样子的。他们喜欢摆弄数据、喜欢把玩产品，然后就随手指了一下，说：“咱们需要优化这个地方的体验”。然后呢，团队成员按照他的想法实施后，没几个星期，数据就直线上升了。

其实，这样的产品经理每天都会思考已有的产品工作流和用户体验，考虑优化哪一步的工作流，可以促进更多用户向好友分享产品，从而实现产品的病毒式传播；思考优化哪一步的用户体验，可以让用户使用得更顺畅。这样的产品经理，又叫增长黑客（Growth Hacker），是不是听起来就非常厉害。

他们就好比奥运会上的金牌游泳教练，知道如何优化一个动作，就可以让金牌选手打破世界纪录。他们的工作看起来，可能就是改改按钮的颜色，给用户发一个提醒消息，增大一个字体，改改对话框之类的琐事，但实际上这些微小的改动却有非常大的效果。

顾客就是上帝，但这种上帝是非常非常懒的。他们不愿意多做一件事情，不愿意多看一句话，不愿意多按一个按钮，所以做增长的产品经理需要思考：如何让产品的体验简单简单再简单。

世界上最值钱的按钮肯定是 Amazon 的“一键购买”（Buy now with 1-Click）按钮，只要你以前在 Amazon 下过单，它就会自动记下你的名字、邮寄地址和信用卡号，当你下次购买的时候，可以直接选择“一键购买”，就可以完成下单了。

这个发明，至少帮 Amazon 赚了 10 亿美元。想想有多少冲动消费的“单身党”，因为“手贱”点了一下，立马就完成了几百元的订单。而如果让用户，先加入购物车，再下单、再填写或者确认邮寄地址和信用卡号，至少要多五步操作，而这时，Amazon 的用户都已经下完五单了。

另外一个例子是，美国的个人财政公司 NerdWallet 的信用卡推荐页面，它的盈利方式是靠向用户推荐信用卡来赚取佣金。本来“现在申请”（Apply Now）这个按钮并没有“锁”的图标，加上这个锁的图标后，点击量一下就增加了 10%。

为什么？其实它抓住的是，用户希望有一个安全保密的信用卡申请体验，他们用一个锁的小图标“聪明”地满足了用户需求，申请人数自然就蹭蹭蹭地往上涨了。

上面的这两个例子看上去像是魔法，但实际上都是经过科学实验一步一步迭代过来的。想拥有这种点石成金的能力，靠的绝不是拍拍脑壳儿，而是科学实验的过程。下面，我就来说说这样的奇思妙想，是怎么通过科学的方式想出来的。

1. 了解清楚你要优化的是什么指标

以 NerdWallet 的信用卡推荐页面为例，它要增加的指标就是通过网站提供的链接申请信用卡的次数。

2. 了解已有的产品工作流

首先，你要思考现在整个网站有多少种方式能够把用户引流到申请信用卡的页面。比如，有三个：一个是信用卡推荐页，一个是刚登录网站时的右侧广告，一个是在博客文章中嵌入的链接。

然后，了解通过哪一步申请信用卡的人数最多。你可能会发现，虽然信用卡推荐页占的篇幅很大、很显眼，但是还不如博客文章嵌入的链接点击量高，这让你感到很奇怪。

另外，还应该对进一步细分，对比不同用户群在每一步的使用情况。比如，你可能会发现，用户终于点击了链接、填入了个人信息，在点击“申请”按钮时，女性用户的点击量远远低于男性，年长用户远远低于年轻用户。

这个过程， 你不需要急着马上找出原因，而是要全面了解整个产品的体验信息，思考用户能够进行目标动作的所有途径。

3. 深挖找出最有价值的机会

经历了对目标指标和已有产品工作流的思考，你已经发现了几个奇怪的点，下面就要开始权衡取舍，从而筛选出你认为最有价值的机会，提出合理的假设了。

比如，通过上面的发现，你的假设是信用卡申请安全性和保密性是关键，所以把信用卡申请链接放在一个随随便便的推荐页里的时候，用户可能会怀疑这个链接的安全性和可靠性。而在博客文章中嵌入链接的话，博客的作者已经取得了读者的信任，所以他们更有可能点击作者提供的链接。

在信用卡的推荐页面，女性用户点击“现在申请”的数量远远低于男性，年长用户远远低于年轻用户，你分析原因可能是女性对财政相关的问题更加谨慎，而年长用户更怕受骗，所以对于这两类用户来说，设计时的重点是获得他们的信任，给他们一种踏实的感觉。

与此同时，信用卡推荐页的浏览人数远远高于其他两个部分，所以你认为应该把重心放在，怎样能把信用卡推荐页设计得更能取得用户信任上，这才是现在最应该抓住的机会。

4. 头脑风暴，想出尽可能多的解决第三步所提假设的方法

现在已经得出了，信用卡申请的安全性和保密性是关键的假设，那怎么才能获得用户更多的信任呢？

你可以加一行字告诉用户，所有的信用卡推荐页都是官方的信用卡申请页面；或者，你可以在信用卡申请这个按钮上增加一些表示安全的图标；又或者，你可以在信用卡申请这个按钮旁边写上多少人已经通过这个链接完成了申请，从而增加用户的信任。

5. 快速执行，高效比对各个实验的结果，发布表现最好的实验组

最后一步就是，你要激励团队快速动手，把第四步的三个想法尽可能快地设计开发出来，并发布给少量的用户进行 A/B 测试。对比这几组实验组和对照组的数据，如果实验组比对照组的数据更好， 那起码说明你的假设是正确的。如果实验组 1 比实验组 2 强，那么就发布实验组 1。

事实上，亚马逊的“一键购买”按钮和 NerdWallet 的信用卡推荐页面，这么天才的想法，其实经过了非常多的测试，经历了无数次的失败后才有了现在的成功。

对于产品经理也是一样的道理，只有经过无数次科学的测试迭代，你才能拥有这样点石成金的本领。

总结

今天，我首先跟你分享了，类似亚马逊的“一键下单”按钮的天才想法， 并不是产品经理偶然拍脑袋想出来的，而是通过不断的思考、科学的迭代，才能找到这种机会，实现点石成金。

然后，我和你分享了科学的测试迭代都有哪些流程：第一步，了解清楚你要优化的是什么指标；第二步，了解已有的产品工作流；第三步，深挖找出最有价值的机会；第四步，头脑风暴，想出尽可能多的点子；第五步，快速执行，高效比对各个实验的结果，发布表现最好的实验组。

最后，在进行科学的测试迭代时，有两点需要特别注意：第一，你一定要系统地过一遍整个产品的工作流，弄清楚用户可能会在哪一步流失，什么用户在这一步更容易流失，而不是一上来就提出假设；第二，迭代的过程重在试错，所以可以多做几次实验，每次试验设置多个对照组，从而找到最正确的方式，而不是指望一次就可以成功。

思考题

随便打开一个你今天用过的 APP，如果你是这个 APP 的产品经理，你可以在哪些地方稍作改动，就可以达到点石成金的效果呢？

欢迎你给我留言。

22 | 硅谷高管的UIE（Understand, Identify, Execute）增长论

在我刚刚进入 Facebook 做产品经理时，干劲儿很足，经常会跟我的导师（现在已经是 Facebook 的高管了）说：“我想到一个方法，我觉得非常靠谱，肯定可以帮助咱们的产品实现增长，我们试试吧”。

我这样跟我的恩师说了几次后，他跟我说：“我发现你经常会有一个新想法，然后找证据证明这个想法是对的。但是，你并没有全盘考虑所有可能的机会，而是直接跳到了这一个想法上。”

接着，他向我介绍了“了解，找到，执行”（Understand, Identify, Execute）这个增长理论。

了解：就是要综合理解用户体验的每一步，然后深挖每一步中每一类用户群体的数据。

找到：就是在了解之后，找到有意思的数据点，挖掘出具体的想法，并且选定最重要的想法。﻿

执行：就是设计开发，然后进行实验验证，如果实验结果靠谱就发布。

用我导师的话说就是，我的问题是只做了“找到”和“执行”，但是没有“了解”。如果没有充分了解产品每一步用户流的表现情况，就不能找到最具价值的想法。结果是，这样做可能会对产品指标有积极影响，但却忽略了更好的主意。

这个增长理论，点醒了我，使我受益匪浅，到现在我都以此为警钟。

“了解，找到，执行”增长论

接下来，我通过一个具体的案例，给你讲讲如何把“了解、找到、执行”这个增长理论，应用到实际的产品增长中。

先给你推荐一个，我现在最喜欢用的、也是最好用的“了解”的方法，那就是产品流程的每一步完成率的表格。

也就是下面的表格，它描述的是刚刚下载了 APP 的新用户如何开启使用 APP 的体验，包括了注册账号、设定密码、关注朋友等， 也就是说当用户完成了最后一步，他们就完成了新用户的设定，可以开始使用 APP 啦。

新下载用户工作流 | iOS | 安卓 | 网页
点击“注册” | 80% | 75% | 80%
使用 Facebook 登录 / 新建用户 | 30%/55% | 55%/42% | 40%/56%
输入密码（同时确保密码符合安全规定） | 80% | 89% | 90%
绑定手机 | 88% | 66% | 20%
开启提醒消息 | 50% | 70% | n/a
搜索好友来关注 / 导入好友 | 20%/75% | 45%/50% | 40%/20%

但是，如果用户没能坚持到最后一步，那么每一步都会降低用户的活跃度。比如，如果用户没有注册成功， 后面的体验就无法开始；再比如，如果用户没有开启消息提醒功能，我们就没有通知用户新消息的途径；再比如，如果用户没有得到其他好友的关注，他就无法真正体会到这个 APP 的价值。

表中的每一列，代表了不同的平台，因为 iOS、安卓和网页版的设计界面是不同的；表中的每一行代表进行到这一步的用户中，百分之多少完成了相关操作。因为隐私原因，我改动了表格中的一部分数据和信息，但这并不会影响你对今天内容的理解。

比如，80% 的 iOS 用户下载之后点击了“注册”按钮，在点击了“注册”之后，30% 的人使用 Facebook 登陆，55% 新建用户名，剩下的 15% 流失了。我们这里假设，在所有用户中，iOS 端用户占 50%，安卓端用户占 45%，网页端用户占 5%。

有了这个完成率的表格，接下来，你就可以分析表中的数据，利用“了解、找到、执行”理论实现产品增长了。

第一步，了解。

了解的意思是要把整体的产品流程按一定的逻辑结构划分，分别看各个步骤的数据，从而了解产品的哪个部分有进一步增长的机会。

通过上面表格中的数据，你发现了下面三点：

用户在网页版“绑定手机”这一步流失极其严重；

用户在 iOS 版开启提醒消息的比例非常低；

用户在 iOS 版点击注册以后，使用 Facebook 登录的比例非常低。

接下来，你需要分析一下出现这三种现象的原因，并试着提出解决方案。

通过用户调查，我们发现使用网页版的用户一般都是使用电脑或者 iPad 登陆，这个时候手机不一定在身边，“绑定手机”这一步需要他们找到手机，进行验证，所以比较麻烦。
针对这一项内容，我们尝试增加“邮件验证”的功能，这样可以方便他们在同一台设备上完成验证。

通过调查分析，我们发现 iOS 版用户开启消息提醒的比例较低，原因是 iOS 系统在开启消息提醒功能时，会询问用户是不是愿意开启这个功能。这时，大部分用户并不了解产品，而我们也没有给他们介绍产品的功能，所以大部分用户都会选择不开启这个功能。
针对这一项内容，我们的想法是，要么在用户刚开始使用时就向他们介绍产品的功能，要么等到用户体会到 APP 的价值、建立了对 APP 的信任后，再询问他们是否要开启消息提醒的功能。

对于 iOS 用户使用 Facebook 登录比例较低这一项，我们发现 iOS 使用 Facebook 登录时，系统会跳转到 Safari 浏览器， 打开的是网页版的 Facebook。这时，很多用户还没有登录网页版的 Facebook，所以他们需要重新登陆一次，而安卓用户可以直接跳转到 Facebook 的 APP，无需重新登陆。
针对这个问题，我们要么修改一下 iOS 的逻辑，让它跳转到 Facebook 的 APP 而不是网页，要么就在网页版增加根据 APP 自动同步用户名、密码的功能，从而实现自动登录。

第二步，找到。

首先你要知道你们在乎的最高层指标是什么，找到最重要的问题，然后设定相关的产品功能，这就需要我们先估测每一个新功能可能带来的价值有多大。

网页版用户在所有用户中的比例非常低，只有 5% 左右，大部分用户直接使用安卓或者 iOS 平台的 APP。所以，网页版的功能优化的价值一般。

打开消息提醒和新增用户无关，更多的是留存。那么，开启消息提醒对用户留存有什么作用呢？假设我们发现，开启消息提醒功能的用户比例提高 20%，可以让用户的 7 天留存天数（过去七天中使用了这个产品几天）增加 5%。现在只有 50% 的用户开启了消息提醒，所以这一步的优化可以提升的极限 50%（也就是 100% 用户开启提醒消息功能）。

“使用 Facebook 登录 / 新建用户”这一步，目的是让用户创建用户名。如果，用户点击“使用 Facebook 登录”这个按钮可以直接创建新账户，那就比让用户想一个别人没有注册过的用户名，体验要好得多。
如果能让更多的用户轻松使用“Facebook 登录”来创建用户名和账号，也就是可以提升新增用户的数量。现在 85% 的用户能够完成新增用户名这一步，所以我们其实就需要让剩余的 15% 的流失用户完成这一步，这是这一个功能的最大潜在价值。当然因为这个功能只有 iOS 才适用，而 iOS 端用户占用户总量的 50%，所以你需要综合考虑这个数量的提升对总指标的贡献是多少。

完成了对这三个问题的分析，我们需要找出那个是最重要的。很显然，第一项没有那么重要，因为 5% 的比例实在太低了。

接下来，我们需要着重分析第二项和第三项，对比优化哪个功能的价值更高。通过上面的分析，你可以看到一个是通过留存帮助增长，一个是通过新增帮助增长，那么到底哪个对产品增长的贡献潜力更大呢？

注意这里用的是“潜力”，因为没人能在这一步确定我们新的产品设计，对总指标的影响到底是多少，所以这一部分其实需要在做好潜力计算之后再做出产品决定。﻿

比如，你现在无法确定，优化“使用 Facebook 登录 / 新建用户”这一步后，用户的完成率可以从 85% 提升到百分之多少，那最好的情况就是假设可以让所有用户都不流失，来判断到底能够增加多少，这也就是“潜力”的一个估计方式。

第三步，执行。

假设这个产品的薄弱环节是新增用户量，所以通过上面的判断，你决定先优化“使用 Facebook 登录 / 新建用户”这一步，因为它可以直接提升产品的新增用户。

我们设计的解决方案是，在用户点击“使用 Facebook 登录”后，新增了一个功能：用户可以直接跳转到 Facebook 的 APP 中，而不用再去 Facebook 网页版重新登录 Facebook 账号。

这时，我们需要明确这个新功能的成功指标是什么。很显然他的成功指标就是用户在这一步的完成率，以及新增用户数量。明确了这些问题后，我们就可以针对这个新功能，进行设计和开发了。

接下来，你就可以按照上两篇的增长黑客和优化产品团队工作流程的方式，来实现产品增长了。

“了解，找到，执行”增长论的重点

尽可能多地了解要优化的用户体验的一步步过程，我们在这里只是分成了安卓，iOS 和网页版，但是实际上我们还可以分为不同的国家、不同年龄层、付费或免费等。
比如，在印度，女性对隐私的保护比较重视，一开始就让她们通过通讯录加好友，她们可能会有所顾虑，不如先给她们推荐比较火的印度账号，先提起她们的兴趣，让他们了解产品是怎么用的。
我也在自己的一个产品中按照国家划分过一次，虽然当时这样划分的结果不是特别理想。但重点是了解的这个过程，要把可能性想的更全面一些，一点点地分析机会在哪里。

通过了解到的数据进行“找到”的时候，要注意怎么看的问题。
第一，左右对比，是要看不同平台的用户流失的情况。 如果知道了 iOS 在某一步的流失率高于安卓， 那就可以仔细研究两者之间在这一步体验有何不同，包括设计、产品运行速度、语言、产品流程的系统区别等等。
第二，上下对比，看的是产品流中每一步的用户流失情况。 如果某一步的流失率非常高，一方面考虑是不是可以想办法提升，比如我上文说的增加提醒消息的开启率，一方面可以考虑这一步到底值不值得，或者是不是可以换顺序。
比如，如果增加好友更重要，开启提醒消息流失得最多，那你是不是可以让用户先加好友，再让他们开启消息提醒功能？或者，去掉提醒消息这一步，对用户体验会有什么损害？
第三，要看整体的数据。 我们写了从这一步到下一步的完成率，但是整个产品体验的完成率，是要把每一步的完成率做乘法，那么最终的完成率就会是一个非常非常小的数字了，也就说明大部分用户都在一步一步中流失了。
所以，我们是不是应该把某几个步骤整合成一个，或者直接让用户选择“默认”，然后我们把该做的都做好，整体看可以让你不拘泥于每一步的优化，而是整个产品体验的优化。

总结

“了解，找到，执行”增长论是硅谷顶级科技公司的增长方法论，屡试不爽，其核心在于先“了解”。

“了解”可以建立一张用户流程步骤图，一步步列出用户的完成率和流失率，再通过分析不同平台、国家、用户群体之间的关系，了解尽可能多的潜在机会。

“找到”就是要通过估测我们上一步了解到的机会到底有多大，制定应该做的产品功能，判断哪个产品功能作用最大， 我们优先处理。

最后，就是“执行”，是指通过上面的分析，进行设计和开发，做 A/B 实验看结果，不断优化功能，从而发布新功能促进增长的过程。

思考题

请你思考一下，腾讯微视增长的“了解”图，应该怎么画？

23 | 增长的核心在于减少用户阻力

相信通过前面的几篇文章，你已经掌握了“了解、找到、执行”增长理论，也优化了你团队的增长工作流，你甚至知道现在的数据哪步不好看，但是却还不知道如何解决。

一个产品的用户数量，往往取决于以下三个方面：

产品的质量是不是满足用户的需求；

用户是不是知道如何使用；

用户为了使用产品所花费的时间和他们得到的价值是不是匹配。

如果一个产品没有证明满足了用户需求， 用户对产品没有忠实度，我们一般不推荐增长团队进行产品增长。 一般我们会先组织一个非常小的团队试水，重点看产品的留存率怎么样，也就是看产品的质量是不是满足了用户的需求。如果留存率非常高，就可以证明这个产品能满足用户的需求，我们才会进行专门的增长工作。

对于用户是否知道产品如何使用，以及用户为了使用产品花费的时间是否和他们得到的价值匹配，这两个问题，增长团队就能起到很大作用。

增长团队可以帮助用户更轻松地了解产品的使用方法， 并且可以从一开始就培养用户的使用习惯，更好的新用户体验，用户教育贴士等方式都可以达到帮助用户了解产品的目的。增长团队还可以让用户体验更加连贯，让用户利用更少的时间得到更多的价值，从而减少用户流失。

问题分析到这里，你很容易就可以看出，你产品的体验要尽可能地减少用户学习如何使用产品、操作产品的阻力，从而才能实现高速增长。

那么，我今天跟你分享的主题，就是教你如何减小用户阻力。这里需要特别注意的前提是， 你已经证明了这个产品可以满足用户的需求，这时讨论减小用户阻力才有意义。否则，你应该先把产品的价值弄清楚，把用户需求弄明白，而不是把时间花在促进用户不需要的产品的增长上。

什么是用户阻力？

要减少用户阻力，那你必须先要明确用户阻力到底什么？所有在用户享受到价值的同时，需要用户做但他们不想做的行为都是用户阻力。

举个简单的例子，便利店之所以火爆就是因为用户以前需要走 15 分钟才能到超市买一瓶橙汁，但现在家门口就可以买到了。 这 15 分钟的步行对用户来说就是阻力，现在家门口的便利店就可以买到这个橙汁，那为什么还要付出步行 15 分钟的代价去超市呢？

如何减少新用户使用体验的用户阻力？

对于互联网产品来说，也是同样的道理。在我看来，一个产品的登录和注册流，是痛点最多，用户最讨厌的，也是用户最容易流失的部分，这部分的用户阻力对产品增长的伤害也是最大的。

那么，我接下来就重点跟你分享下，如何优化产品的登录和注册流，才能最大程度地减少用户阻力。

比如，你刚刚下载了一个 APP，不记得自己是否注册过，所以当 APP 让你选择是“注册”还是“登录”时，你抱着试试的心态选择了“登录”。

接着，你输入了一个常用邮箱，APP 却提示你“查不到此邮箱”，这时你需要先退出登录界面，重新找到选择“注册”还是“登录”界面，然后选择“注册”，才能创建账户。

那么此时，这个 APP 在你心中的分数还能剩下多少？

接下来，你要思考应该怎么优化这个产品的注册和登录流了。在我看来，可以这样稍作修改：当系统找不到用户输入的邮箱时，询问用户“是不是想注册”，用户点击“注册”，这个邮箱会自动填入注册申请表，这样就把本来需要三四步才能完成的动作一步完成，也就减小了用户阻力。

其实在我看来，用户想尽快使用 APP，整个注册和登录的过程其实都算是用户阻力，每减少一个步骤，都可以降低用户流失的可能，从而提升用户的注册完成率。

下面，我再针对如何优化新用户使用体验的部分，跟你分享几个经验证有效可以减少这部分用户阻力的方法。

自动推荐用户名： 有些 APP 要求用户名是独一无二的，如果用户尝试的好几个用户名都被注册过了，这就是一个非常糟糕的体验。 这个时候，你可以根据用户输入的用户名，自动推荐没有被注册过的用户名，目的是减轻用户的注册成本，方便他们进行到下一步。
比如，我的用户名“xiaoyin”被注册了，那么“xiao_yin”“xiaoyin111”“xiao.yin”都可以推荐给我。

把必填项放到前面： 很多产品的用户注册流有很多项，但必填项也就是邮箱、密码、用户名。所以如果把必填项设计到前面的话，用户更有可能完成注册。
这样，即使用户在填写选填项想要放弃时，你也可以告诉他们：“你的必填资料已经完整了，你可以完成注册了，你真的要放弃么？”用户可以选择“退出注册”或者“完成注册”，这样你很可能就成功挽回了一个马上就要流失的用户。

告诉用户你会发什么样的提醒消息：对很多产品经理来说，让用户开启消息提醒是个巨大的挑战。
我见到的做得比较好的 APP， 会清晰的告诉用户会发什么样的提醒消息，以及为什么这些提醒消息对用户有帮助。有一个好办法是告诉用户“打开提醒消息以后，你随时都可以在 APP 上设置“关闭消息提醒”，加上这句话会让用户更容易开启消息提醒，现在已经有不少 APP 开始这么做了，效果非常不错。
我还见过一个 APP，让用户开启提醒消息这部分做得非常精致，他们做了一个小视频：美女微笑着用手指着“开启消息提醒”的按钮，引导你开启。
还有一个比较好的方式是，告诉用户如果他们没有开启消息提醒，会错过什么样的消息。比如，Instagram 告诉用户，你将错过朋友们的回复，Uber 告诉用户，你将错过司机到了的提醒，而这些都是足够的痛点。

如何减少电商购物流的用户阻力？

另一个用户阻力造成巨大危害的部分是电商的购买流，也就是用户下单购物的部分。购买流部分的用户阻力，直接伤害的就是电商的收入，那可是真金白银啊。

针对电商购买流的优化，你可以从以下三个方面的用户体验入手，减少产品的用户阻力。

自动纠正邮寄地址：这个部分看似容易，但是很多产品都没有做好。那应该怎么做呢，接下来给你分享下我的经验。
如果我以前下过单，系统应该自动显示我上次的邮寄地址，让我确认即可；如果我新输入的地址格式不对，系统应该自动推荐一个合理的地址，让我一键修改；或者我曾经输入过多个地址，那么系统可以让我选择一个地址，还可以考虑分别显示每个地址对应的邮费，这样我就可以轻松地做出选择。

购物车没转化：Facebook 推出了一个智能广告，可以在用户信息流上显示他们还没有下单购买的产品图片，然后用户可以点击图片直接进入购物车完成购买。后来的数据证实，这个广告的转化率非常高。
同样的道理，如果用户把商品放到了购物车而没有买，过了两天他回到了网站，你是不是可以考虑用一个小窗口显示他上次没买的东西，然后给他一个折扣券，让他们直接转化？或者，告诉用户在过去的两天，多少人买了这件商品，或者这件商品的库存还剩几件，通过这样的方式刺激用户购买的欲望。

第一次购买： 如果用户是第一次购买，在下单的过程中用户已经提供了邮箱，那么是不是可以直接存储邮箱信息，帮助用户自动创建一个新账户，这样用户只要加个密码，点下“确认”就完成了账户的创建工作。
这样做对你的好处是，你不仅得到了一个新订单，还多了一个以后可以发邮件，宣传打折新品的回头客。

减少用户阻力的三个原则

上面，我针对新用户体验和电商购买流的优化，给出了几个小建议，来帮你减少这两大关键场景的用户阻力。其实从这些小建议中，你可以发现减少用户阻力的原则，一般可以归纳为以下三个。

自动完成。 这主要包含两个方面：
第一，同样的信息一定不要问用户第二遍，比如用户输入过邮箱，那么自动记录，不要让用户填写两次。
第二，可以推导出来的信息要自动完成，让用户修改即可，比如用户输入了邮政编码，那你就应该自动完成城市和省份的填写；比如用户以前买的是 38 码的皮鞋，那么你就可以自动给用户推荐这个号码的鞋。

告诉用户他们会失去什么。有意思的是，告诉用户他们会得到什么，他们可能不在乎。比如，当你说“今天有 15% 的折扣，点击这里购买”时，用户可能不为所动。但如果你说“明天 15% 的折扣就过期了”，用户的欲望就会变强。
所以，作为产品经理，不仅要考虑产品应该怎么设计，更要考虑什么样的文字更能打动用户。
比如，“如果不打开消息提醒，你可能会错过朋友的评论”“如果你今天没有发抖音，朋友们就会看不到你今天的新鲜事”，这样的方式对用户的活跃度的积极影响会更大，因为遗憾相比惊喜，总是更加厚重。
在美国，有一个专门的词语描述这样的情况：FOMO（fear of missing out），也就是害怕错过。所以，如果你能帮用户减少 FOMO，那你就赢了。

聪明的整合。能三步完成的，一定不要做成五步。所谓整合，就是把相关的步骤用逻辑清晰的方式整合起来，即使只是视觉上没有那么多步骤了，对于转化率的增长也是惊人的。
比如，如果第一步让用户输入邮箱，第二步输入用户名，那完全可以合并为一步，用户输入邮箱后，你可以直接自动完成用户名；或者，如果有一步要用户通过搜索添加好友，还有一步需要用户同步通讯录添加好友，那你完全可以在用户刚刚进入搜索框还没搜索的时候，加一个小按钮让用户一键同步通讯录。
这样的方式，都是把逻辑相关的步骤整合，在产品设计上让用户觉得眼前的工作很容易，不用花多少时间，从而提升产品的转化率。

知道了减少用户阻力应该遵循的几个原则，那么当你想减少产品阻力时，你就可以想出更多、更适合具体产品的主意了。

总结

今天，我主要跟你分享了几个减少用户阻力的方法，帮助你更好地推动产品增长，减少用户流失率。你需要特别注意的是，这些方法的前提是验证了产品可以满足用户需求。

我给你总结了，用户阻力对产品增长伤害最大的两种场景：新用户体验和电商的购买流，并针对这两个关键场景，我给出了一些方法，也告诉了你减少用户阻力需要遵循的三个原则：

自动纠正和自动填充，绝对不让用户重复劳动，比如自动提供用户以前输入过的信息；

告诉用户不这样做会失去什么，让他们感到遗憾，从而推动转化；

整合逻辑相关的步骤，最少让用户在视觉上觉得产品的流程非常简单，从而提高转化率促进产品增长。

思考题

极客时间 APP 哪些部分有用户阻力，你有什么想法？

欢迎你给我留言。

24 | 产品增长的代价，如何权衡取舍？

我今天要和你分享的这篇文章，已经是产品增长系列的第 6 篇文章了。通过之前的文章，你应该已经掌握了增长黑客的核心公式，知道了如何优化产品团队的工作流，了解了产品增长“天才想法”源于科学的迭代，也明白了产品增长的核心在于减少用户阻力，有没有觉得很有收获？

今天我要和你分享产品增长系列的最后一个问题：产品增长的代价，应该如何权衡取舍？

产品增长的代价

产品增长的代价是指，为了实现短期增长目标采取的措施对产品长期发展造成的不利影响。

Yik Yak 曾经是很厉害的匿名社交 APP，2013 年发布，2014 年的估值达到了 4 亿美元。它提供的是一个匿名社区，用户可以匿名发帖并且查看来自他们好友的匿名帖子，曾经是最受美国学生欢迎的 APP，显赫一时，产品增长就像坐火箭一样。但在 2017 年，Yik Yak 却以 100 万美元卖给了 Square，关门谢客。

一开始用户们疯狂地使用 Yik Yak 谈天说地，他们可以做真实的自己。但是，之后 Yik Yak 的产品经理进行了疯狂地增长行为，却忽视了开始出现的各种校园暴力和欺凌内容，任何人都可以用 Yik Yak 匿名发帖毁掉他人的名誉。

于是，学校开始阻止学生使用 Yik Yak，用户们也觉得它不再是一片“净土”，而成了消极内容泛滥成灾的烂摊子，最终用户都流失了，产品也只能以关闭告终。

Yik Yak 本可以在初期就做一些净化社区的工作，比如捕捉暴力和欺凌内容的人工智能系统，比如屏蔽发布不良内容的用户，比如投资更多时间和人力在社区运维的工作上。

但是它没有把时间花在这方面，而是花在了增加下载量和用户活跃程度，以及加快下一轮融资上。因为，在 Yik Yak 看来，把本应花在增长上的时间和精力，用于社区净化，怎么看都不值。

其实，这是很多产品团队的通病。他们往往迫于增长指标的压力，并不愿意把时间花在虽然长期来看有很多帮助，但是短时间内不能带来价值的地方。于是，他们大多会选择短期利益，却忽视了长期利益。

这样做的结果就是，这个产品今年的数据好看了，但几年之后却变了味，产品打造的社区环境被破坏了，用户对产品的信任也没有了。

明确产品的长期使命宣言和原则

因此，如果你想做一个可以长期为用户带来价值的产品，首先要让你的团队明确长期的使命宣言是什么，并制定出产品长期发展的原则。

使命宣言（mission statement）用一句话概括，就是：产品为用户提供了什么价值。 好的产品经理一定会让团队的所有成员不断重复产品的使命宣言，让所有人烂熟于心。

产品原则是根据使命宣言制定出的核心指导思想，不管增长的指标有多么激进，都要确保符合这个原则。

比如，Waymo 无人车的使命是让人和东西能够安全便捷地移动（make it safe and easy for people and things to move around）。而 Lyft 无人车项目有着不一样的使命，它希望为无人驾驶汽车的软件系统设定标准，让人工智能技术尽可能地普及。

这也就是说，和 Waymo 做专有系统不同的是，即使 Lyft 可以通过做专有系统垄断无人驾驶汽车系统，实现收入的增长，他们也不会这么做， 因为这有悖于他们的使命宣言和原则。

再比如，Facebook 的使命是让人与人之间的距离更加紧密，这意味着我们希望产品功能能够帮助用户更好的和朋友互动，而投放广告也不能违背这样的原则。

Facebook 投放广告的原则是，只做高质量的对用户真正有帮助的、和用户需求相关的广告。在 Facebook，我们有一个专门的产品团队把控广告系统的质量：一方面，坚决不做黄赌毒、成人内容等低质量的广告；另一方面，如果某类用户看到某个广告后不愿意点击的话，就会有系统和专门的团队来控制这类广告向该类用户的推送。

即使这种严格的广告质量审查，意味着 Facebook 将会损失推送这些低质量广告的收入，它也绝不会为了短期的增长去忽视产品长期的使命。所以，Facebook 推出广告产品以来，也一直屹立不倒，并成就了 5000 亿市值。

通过这几个例子，我想要告诉你的是，作为产品经理， 在制定增长指标和产品策略前，一定要明确产品的使命宣言和核心价值，明确什么事情是一定不能做的，并且让整个团队的成员都百分之百遵守这些原则。

反指标

在“制定产品成功指标”这篇文章中，我给你分享了“反指标”是指产品带来的负面影响，是一个非常重要的指标。当你确定了产品长期的使命和原则后，在制定增长指标的同时，应当同时制定反指标。

比如，对于 Yik Yak，增长指标可能是日活的数量和每日新增发帖数，反指标可以是用户举报不良的内容 100% 在 24 小时内删除，或者通过抽样调查确定不良内容的比例低于 1% 等。也就是说，即使某些增长策略，达到了增长指标，但没达到反指标，也视为失败。

对于一些比较大的产品团队，还会包括两个具体的增长团队，一个负责增长指标，一个负责反指标，这样可以确保团队不会因为一味追求增长数据好看而丧失了对反指标的关注。

这样的团队结构可能导致的结果是，增长团队和反指标团队经常意见不和，但是总体来看确实对产品的长期质量有非常大的帮助，那么团队之间的这些小争论也就不是问题了。

如果你不想让产品的增长影响长期的发展，那么反指标就不能只是嘴上说说，而必须要落实成为产品最核心的数据之一，产品负责人也一定要在每周检查增长指标的同时，检查反指标。

当反指标没有达到时，要让所有的团队成员意识到这是一个失败， 并且要不惜一切代价降低反指标对产品的影响。只有把反指标作为公司的核心数据，才能让团队的人真正投入工作，而不是流于表面。

这里还涉及到一个权衡取舍的问题，如果 A/B 测试的结果显示某个新功能可以增加 X% 的日活数，但是也会增加 Y% 的不良内容比例， 这时就需要有一个方式来量化这个功能对产品整体的影响，来决定是否发布新的功能。

比如，我之前负责过的一个产品，我们的反指标是一定不能让低质量广告的比例高于 5%，如果发现某个新功能让低质量广告的比例增加到了 6%，那么不管这个功能多么给力，也不能发布。

明确了反指标后，产品经理要能说服老板和团队， 短期利益的牺牲是值得的，以及清晰表达短期的不惜代价对长期发展的影响，并制定具体的量化标准。

因为，如果没有具体的数字来量化，反指标就会流于表面，产品增长的代价也就成了说说而已的假把式，就会牺牲产品的核心原则，最终导致产品背离再满足之前雄心勃勃的使命，失去用户。

总结

接下来，我给你提炼一下今天内容的要点。

为了达到产品的短期增长指标，而不择手段，会导致用户丧失对产品的信任，产品最终会被用户遗弃，走向失败。

我通过 Yik Yak 的失败和 Facebook 广告的成功案例，给你揭示了产品增长的短期利益没有把控好，会对产品长期的存亡产生直接影响。

接下来，我给你分享了对产品增长的代价，应该如何权衡取舍：

第一，在制定产品增长指标的同时，制定产品的使命宣言和核心原则，使命和原则要不断重复，让整个团队烂熟于心，是绝对不可以违背的最高戒律。

第二， 要制定反指标，并且明确到具体的量化指标，使之成为 A/B 测试判断产品可否发布的核心标准。

作为产品经理，你一定要把产品增长的代价摆在和产品增长同样重要的位置，这样才能真正打造一款世界级的产品。

思考题

趣头条模式的增长代价是什么？如果你是产品经理，该如何设定反指标？

欢迎你给我留言。

25 | 三分靠策略 七分靠执行

在产品增长系列文章里，我给你分享了很多制定产品策略、制定增长指标的经验，但仅是制定了这些策略和指标还远远不够， 最重要、最关键的是执行。

在硅谷，很多著名的风险投资人，衡量一个公司是否值得下一轮投资的标准，更多的是看团队执行的能力，即在有限的时间内到底能取得多大的进展，而不只是看创始人如何口若悬河，或者团队背景多么高大上。

可以说，一个团队的成功，三分靠策略，七分靠执行。所以，对于一个成功的产品团队，高效的执行力是关键。那么， 作为产品经理，怎么才能打造一个高执行能力的产品团队呢？

要在团队中培养结果导向、责任分明的团队文化

很多团队的策略听上去非常靠谱，但到具体执行时却杂乱无章：群龙无首、内部斗争不断，需要花费很多时间在内部事务上，团队效率低下，从而导致产品开发停滞不前。

其实，出现这种问题最根本的原因是，衡量团队成员工作表现的标准出了问题，给了不做事只吹牛的人太多“偷奸耍滑”的机会。

我之前合作的一个团队，有一个工程师非常擅长在大组开会时口若悬河，但是实际操作时却极其不负责任、能推就推，到头来却抢别人的功劳。

但是，他们的团队领导和产品经理并不怎么关注工程师的开发工作，这样的情况一直没有被注意到，所以这个工程师可以为所欲为。这样不仅让其他工程师非常不爽，还大大拖延了整个团队的效率。

那到底怎么才能避免这种情况呢？

作为产品经理，应该和工程经理一道，确保每个工程师、设计师的工作表现有明确的量化标准。这就要求：

每个人有自己负责的部分，并且其他人都知道是这个人负责这部分，对这部分的成绩负责；

工作效果有一个具体的衡量方式，是可量化的，有时间限制的；

这个人遇到困难，可以向他人求助，他人应该帮助这个人，如果困难解决不了，这个人有责任及时汇报给产品经理。

说白了就是，要让每个工程师和设计师觉得自己是这个部分的负责人，引导他们的主人翁意识，这样才能真正推动他们的能动性，并让他们真正在乎自己所做工作的结果。

当你发现有抢别人功劳的事情发生时，绝不能手软，要明确说明这样的行为不被允许，从而保证不会因此影响团队士气。

有了明确的量化标准和责任范围，抢功劳和碌碌而为混日子这样的行为就没有了滋生的土壤，这对提高团队的执行力非常重要。

要把控团队做决定的速度

很多科技公司的文化是希望每个人都有主人翁意识，所以做决定的时候也希望能得到大家的一致同意。 这么做的好处是，团队的每个人都觉得自己受到了尊重，激发大家的积极性，增加团队的士气；而潜在风险就是，要花太多的时间做决定， 增加了执行成本，延长了产品开发时间。

但是，并不是每个决定都需要每个人一起做出。所以，什么样的决定要快很准地做出，而什么样的决定要积极听取大家的意见，就需要产品经理来把控了。

每一个决定都有一个对应的可争论时间，时间长短由这个决定的重要程度决定。最重要的决定可以多花一点时间，积极听取团队成员的意见，让他们每个人都参与讨论，三思而后行。而不太重要的决定，可争论的时间要尽量短，目的是快速得出结论，马上开始执行。

给你举一个简单的例子，我们之前做了一个帮助网红赚钱的产品，需要对这个产品的具体问题进行讨论，然后做出产品决定。你可以先思考一下，在这个产品中，什么决定是最重要的，而什么样的决定是可以快速做出的。

对于什么样的网红有资格使用这个产品的决定，会关系到产品的发展模式、网红的运营模式等，所以非常重要。对此，负责网红关系运营的同事们、法律和支付部门的同事都参加了讨论， 我们花了几周的时间才制定出了策略。虽然这个决定花了很多时间，但让每个部门的同事都有参与讨论的机会非常重要。

但是，涉及到这个产品的某一个小细节，比如新用户体验的第一步和第二步的顺序应该是什么，如果大家喋喋不休，无法取得统一意见，而工程师在等着这个决定进行下一步的开发时，就需要产品经理出面解决了。

当时，我对大家说：“这个决定并不是最重要的，不应该花这么多时间讨论，我们可以先按照原来的顺序，后期根据用户反馈，我们还有修改的余地”。

我这么一说，既让大家意识到时间不多了，我们得赶快开始，又给持不同意见的人留了面子，这样大家就可以很愉快地推进产品进度了。

这个道理非常简单，但是我见过很多被无关紧要的决定浪费大量时间的情况。某个领导突然对某个小细节有意见了，或者两个设计师对某个按钮的样式不能统一意见、开始针锋相对了，在不值得的决定上浪费了太多时间，是我见过的执行能力差的团队的通病。

作为产品经理， 确保产品的执行效率是首要责任，而把控团队做决定的速度是最重要的一环。敢于对团队成员说“这个决定我们讨论的可以了”，并且能够说服他们赶快行动，是衡量一个产品经理能力水平的一根准绳。

明确产品功能的优先级

每个设计师和工程师都有做不完的任务， 写不完的文档和代码，以及加不完的班。所以，指望大家能把所有的工作都做完，不切实际。

我刚入行时，发现一些工程师总是慢吞吞的，他们总加班但产品开发工作就是做不完。后来我发现，他们的时间全花在改一些无关紧要的 Bug 上了，而重要的产品开发工作却被扔在了一遍，拖慢了产品开发进度。

首先，你必须意识到，不能假设工程师和你对优先级的把控是一样的， 在优先级的问题上一定要重复重复再重复， 明确明确再明确。

在这里，我跟你分享一个好方法：明确告诉你的团队成员，哪部分工作是优先级较低的。 你可以向团队成员说明产品优先级时，顺道说说哪些工作确定不是优先级高的；你还可以在路线图（roadmap）上说明哪部分是明确不做的。这样做，可以让工程师排除不重要的工作，减少浪费时间的情况。

优先级高的内容毕竟有限，但很多时候工程师有非常非常多的任务需要处理，经常一投入到代码中就忘记了产品优先级、指标，或者别的组的人一催，就忘记了什么工作是最重要的。

所以，如果你能清楚的告诉工程师什么内容是不重要的， 这些内容出现的时候可以忽略， 别的组的人催的时候可以拒绝，就可以帮工程师减少很多分散精力的工作。

其次，你需要注意的另外一个问题是，产品的优先级要每周至少沟通一次，这可以强化团队成员的优先级意识，让他们更好地规划自己的时间。

我的团队每周都有一个工程师优先级会议， 会把所有的产品功能一个一个地捋一遍，明确优先级，如果有突发情况需要修改优先级也会在这个时候告诉大家。这样的优先级会议，我一般选在周一召开，以方便工程师和设计师合理分配他们一周的时间。

最后，只有团队成员都了解了其他人的优先级，才能更顺利、有效率地合作。

比如，工程师 A 和 B 都需要我做代码评审，如果我们都知道工程师 A 这部分的内容优先级更高，对产品更重要，我就可以先帮工程师 A 评审，而工程师 B 对此也不会有怨言。

因此，清晰沟通了产品优先级，团队的合作和执行就成功了一半。

总结

今天，我跟你分享了高效执行对产品团队的重要性，并跟你分享了三个提高团队执行力的方法，希望你可以把这些方法用到日常工作中。

第一，作为产品经理要在团队中培养结果导向、责任分明的团队文化，杜绝抢功劳的情况，让每个工程师明确自己的任务是什么、责任是什么，以及对团队的贡献是什么。

第二，要把控每个产品决定值得花费的时间，对于在不重要的决定时花太多时间的情况，要适时果断地给出方向， 让大家先执行，避免浪费太多的时间。

第三，要定期召开优先级会议，让每个成员明确自己的优先级，了解他人的优先级，不只是告诉大家什么工作重要、值得做，更要明确什么内容不重要、不值得做。

思考题

你的团队在执行上遇到的最大问题是什么？

欢迎你给我留言。

26 | 为什么加班很久但是没成果？产品开发流程有问题

在刚入行做产品经理时，我工作过的一个团队每天都在加班，工程师叫苦不迭、设计师焦头烂额、产品经理也忙得像“热锅上的蚂蚁”，但就是做不出产品，最后的考评成绩也明显配不上整个团队三天两头加班的付出。

后来，我在几个高效率团队工作过以后，终于总结出了团队加班很久但是没有成果的几个共同特点，我也是在踩“坑”无数之后，掌握了团队执行的黄金宝典。

接下来，我就跟你分享一下低效团队三个常见的“大坑”。

第一个“坑”：需求变变变，但新需求并不是来自于用户反馈。

工程师最讨厌的就是产品经理改需求，但是产品经理会理直气壮地说，我的工作是要做对的产品，改需求的目的就是为了更好的产品体验。公说公有理，婆说婆有理，最终就剩吵架了，啥也没做成。

在这里，我并不是说产品经理不应该改需求。相反，我认为产品经理一定要根据用户反馈不断优化产品体验，这也正是迭代化产品开发的核心，即从最小化可行产品（MVP）开始，逐步优化产品体验，作出越来越完善的产品。

而我见过包括工作过的很多团队改需求的原因，往往是因为某个领导觉得不够好，其他组的某个人觉得有问题，或者产品经理改主意了。又或者，产品开发时，产品经理和工程师间缺乏交流，结果开发了一大半才发现已经脱离了原来的产品计划，所以工程师要按照原来的需求重新开发。

但是，在理想情况下，只有有来自用户的最新反馈时，才会改变需求。

比如，我们通过用户调查发现用户对现在的设计缺乏信任，或者认为现在产品的体验很差。这个时候修改需求或者产品决定，我认为是非常必要的。

而如果没有用户反馈，修改产品需求就会比较盲目。某个没有经过市场验证的假设，很有可能就会推后整个产品接受市场反馈的时间，而这并不一定值得。

这个时候，产品经理需要勇敢的站出来，告诉他：“我们可以先选定一部分用户进行产品测试，看看他们的反馈如何，然后再决定是否要修改需求，这样的效果会比推迟整个产品的发布时间更好”。因为一般情况下， 产品发布前都会有一个测试期，根据用户反馈做出下一步的产品决定。

当然，这种情况并不适用于所有产品。有些产品的前期投资会比较大，等到产品发布前再测试的风险会很高，所以需要在产品开发阶段就经过层层审批、不断调整产品需求，以确保产品一炮而红。

第二个坑： 做决定的人太多，做决定的速度太慢，工程师上班在等产品决定

在前面的文章中，我给你分享了一些产品决定的内容，今天我就跟你分享一下做决定的流程：我认为，每个决定，都应该弄清楚到底需要什么人、几个人来做，以及为什么需要这些人。

产品方向策略的决定，我一般会和工程经理、设计主管一起制定方案，然后向上层领导汇报，达成一致。而对于基层的工程师，我会给他们提意见的机会，也会考虑根据他们的意见修改方案，但并不会等到他们同意之后再做决定。

产品优先级的决定（先做什么功能），我一般会和工程经理、技术主管一起做，然后制定整个产品团队的开发时间表。对于每个工程师，我会和他一起商量他负责的几个项目中哪个更重要。

产品功能实现方法的决定，我会和具体负责这个功能的同事一起做。如果这个决定有法律或者政策方面的问题，我会再拉上法律、政策部门的同事一起决定。敏感的功能我会向上层汇报， 涉及和其他团队合作的功能，我会和对方的产品经理沟通。

明确每个决定需要什么人来做，如果这个人无法改变决定，那就可以不叫他来，这样可以减少做决定的时间，以最快的速度达成统一意见，提高开发效率。

这里的难点是，产品经理很多时候根基不够硬，或者经验不够多，不敢告诉对方这个决定不需要他做，即使为了礼貌也要把他找来，严重拖慢了做决定的速度。

我的建议是，你可以和团队成员一起商量讨论制定一个做决定的流程，做什么样的决定需要什么人来做，提前把规矩定好，就可以避免这种尴尬情况了。

综上所述，把每个决定结果记录下来，及时和团队成员汇报，并给他提建议的机会，而不是让所有人都参与到做决定这个过程中，可以在兼顾团队成员的主人翁意识的同时，对团队的执行效率产品积极影响。

第三个坑： 产品开发计划没做好。

有些团队比较理想主义， 每一步都拖来拖去， 但是却认为到截止日期那一天产品就会像变魔术一样变出来。这是非常幼稚的想法，最后产品往往不能按预期发布。

产品的开发计划一定要非常精准， 我的建议是至少以星期为单位，每周都要明确每一个工程师和设计师要达到什么样的结果。

在刚刚决定做一个产品时，产品经理都会先写产品需求文档， 分别给工程师和设计师制定工程计划和设计计划，这个时候你可以把要达到的目的精确到每个星期。

这里需要注意的是，在制定产品开发计划时，你需要和团队的工程师和设计师商量，看这样的计划是否可以顺利执行，有没有哪些不合理的地方，然后根据他们的意见适当调整。

如果工程师觉得这一部分需要先拿到设计图才能做，你可以适当调整设计师的设计计划，以确保设计师和工程师之间的合作最优。 如果工程师认为， 设计师得在第三周时告诉他是用行表还是用纵栏，因为两者的数据结构不同，那你就要确保设计师的计划能符合这样的要求。

这些都是在产品开发之前就已经提前计划的， 而不是让设计师和工程师各做各的， 遇到问题以后才修改。好的产品计划可以减少加班，这句话一点都不假。因为产品开发计划精细准确，确保每一步都是最优的，可以大幅提高产品开发的效率。

我给你分享的产品开发流程中的三个“坑”，都是我自己亲身踩过的。把这些内容分享给你的目的，就是希望达到“我试错，你绕坑”的效果，提高你的产品开发流程。

最后，针对现在的“加班文化”，我想告诉你的是，不要让团队成员把加班时间长作为一种光荣，这是一种很危险的文化。这样的文化会助长庸人，让团队不再是结果导向。

比如，工程师开发做得一塌糊涂，但每天在办公室加班上演“苦肉计”，考评时直接说：“我工作这么辛苦，难道不应该给我好评吗？ ”

但我并不是说不能加班， 而是永远不要以加班时间作为衡量团队成员工作质量的标准，否则团队一定无法在规定时间内交付高质量的产品。

总结

加班很久但是没成果，是一件非常悲哀的事情，也是产品经理的失误。我给你介绍了三种提高工作效率的方式，来减少无谓的加班时间，确保产品有结果：

第一，要杜绝根据假设以及个人的意见改需求，用户反馈才是修改产品需求的依据。在确保产品的代码质量有保证的前提下，提前发布让更多的用户看到，远远好于因为某个人的临时起意而耽误产品接受市场反馈的时间。

第二，要把每个产品决定需要几个人、什么人参与弄清楚，确保不让不直接相关的人耽误做决定的时间，不要出现工程师干等产品决定而无法开始写代码的情况。

第三， 在产品开始开发前制定出精准的产品计划，工程师、设计师等各部门同事提前计划、提前预估风险、提前调整工作计划。

最后，我要和你说的是， 要倡导结果导向而不是以加班时间为导向的团队文化，这样才能让团队成员把精力花在做事情上， 而不花在“苦肉计”上。

思考题

请你思考一下，你团队的效率低下是踩了哪个“坑”？你打算如何解决？你是否还经历过因为其他原因造成的团队低效？

欢迎你给我留言。

27 | 如何激励和管理比你资深的工程师、设计师？

我开始做产品经理时， 还是一个二十出头的黄毛小丫头，大学刚毕业踌躇满志，顶着“经理”的头衔和高级工程师开会，他们直接给了我一个“下马威”。原因很简单，高级工程师做过很多产品，有很好的产品感觉，根基也非常扎实，这个时候你想领导他们谈何容易。

其实，很多产品经理都会遇到比自己资深的工程师、设计师， 他们聪明绝顶、深受尊敬、连领导都会问他们的意见。就算是经验丰富的产品达人，进入新的团队，也应该马上和这个团队的灵魂人物搞好关系。如果他们如果带头对你的方案提出质疑，其他的团队成员肯定会跟风不再信服你，那么你这个产品经理可就难当了。

接下来，我就根据自己在产品经理道路上“摸爬滚打”的经验，跟你分享几招同资深的工程师、设计师友好相处的“必杀技”，希望能够帮你更好地激励和管理他们，最大限度地将他们的聪明才智用到你的产品中。

第一招，建立信任从帮忙打杂开始。

进入一个新的产品团队， 一定不要一开始就指手画脚， 这个时候大家对你的能力还不清楚，团队的利益关系你也还没看清，甚至你对产品所处的环境和策略都还不熟悉，这个时候，帮团队做一些简单的小事， 比一开始就直抒胸臆、指点迷津强得多。

当你觉得跟工程师还不熟，或者他们对你爱答不理时，我最常用的方式就是跟工程师约个咖啡， 告诉他们我是新来的，对咱们团队的事情还不懂， 你有没有什么“脏活累活”，我先帮你干吧。

还有一个小技巧，开会的时候，你不要想着一上来就发言，主动做会议记录的效果来得更好，然后通过邮件把会议记录发给大家。

这样，一方面团队成员会觉得你来是帮助大家的，另一方面通过会议记录，你可以更好的了解产品现在所处的环境和策略，并和大家讨论会议的细节。

恭喜你，这种自然地过渡，可以帮助刚来的你取得团队成员的信任。

另外，如果你的产品经验并不是很丰富， 一定不要装出一副经验很丰富的样子，因为你的“表演”并不能骗到大家。

这个时候，你应该放低姿态、踏踏实实地做工作，表现出你的努力和进取心，让大家觉得你是一个年轻有为的、充满朝气的、有潜力的领袖，而不是夸夸其谈，会更容易得到其他成员的认可。

当你肯放低姿态不把自己当回事，不摆经理架子，并愿意帮助大家完成会议记录等琐事时，你就已经比大部分产品经理更受团队欢迎了。

第二招，建立和资深成员的信任关系。

每个团队总有那么几个资深的、深受大家尊敬和爱戴的人，这样的人产品经理切记不能得罪，否则整个团队都会不待见你，推进工作会遇到重重阻碍。但是如果你能和他们建立良好的关系，团队其他成员也自然不敢给你难堪。

可见，和团队资深成员搞好关系，可以让你的工作事半功倍。那怎么才能和“高高在上”的他们，建立良好的信任关系呢？

我的建议是，你可以是虚心请教的态度，问问他们对团队有什么期许，和之前的产品经理合作有什么样的问题，自己如何做才能避免出现这些问题、更好地帮助他们。

你也可以和他们讲讲自己的故事、以前的经历， 像交朋友一样和他们沟通，让他们信赖你，真正成为你的左膀右臂。

这里，你需要明白的是，只有让这些资深成员信任你，他们才会帮助你，其他的团队成员才能更信服你。

第三招，弄清楚资深成员想要什么。

资深成员已经取得了大家的信任和支持，领导也非常重视他们，他们已经不在乎你是不是经常表扬他们，或者老板怎么看他们。所以，你平时的表扬和鼓励对他们不一定管用，但他们一定有想要的东西，这个时候你就需要仔细观察，了解他们下一步想要达到的目标。

弄清楚资深成员的需求，才能和他们建立信任之上的更深层次的关系。

比如，有些资深成员想要独立发起项目，和团队推销自己的新想法，如果这个时候你能够帮他们更好地推销，给他们“站台”，支持他们的新想法，就会比较容易得到他们的心。

还有些资深成员希望能做最有挑战性的工作，并且让其他成员都知道这些工作是多么有挑战。这个时候，你给他们一个展示自己工作的机会，并强调他们做的东西难度多么高，能做出来多么不容易，这对他们来讲意义非凡。

资深成员到了这样的职场阶段，在乎的是自己的口碑，自己的工作是不是对公司有价值、符合自己的价值观和野心，而不是今年的考评是不是够好、是不是能升职。所以，激励他们要有针对性，了解他们想要什么，并最大程度地满足他们，才可以让他们更信服你。

第四招，你的“必杀技”就是把事情干成。

一个产品经理， 就算你有厉害的学历或者丰富的经验，但你就是没法把产品干成，没法把执行做好，那么你再精彩的简历都是白搭。

这个道理很简单，作为团队成员，你在乎的是每天加班加点的工作，能够做出一个满足用户需求的产品，而不是瞎忙活，做了半天啥也没有发布。

所以，如果你是一个产品新人，没有产品成功的案例，那么你现在最需要的是尽快发布一个产品，并取得好的成绩，用成绩证明你的能力，让大家信服你。

一个真正能够推动产品进展的产品经理，在工程师和设计师，尤其是见惯了只耍嘴皮子、不做实事的高级工程师、设计师眼中，比什么都强。

只有以身作则拿出成绩，大家才会真心的服你，愿意跟从你、响应你， 这一点对产品新人和资深的产品经理同样重要。虽然资深产品经理，可能不会亲力亲为了，但是遇到事情能顶上，同样非常重要。

综上，激励和管理比你资深的工程师设计师的方法，可以概括为四个词：放低姿态、建立信任、成人之美，和踏实做事。

总结

今天我跟你分享的主题是，很多产品经理，尤其是产品经验不丰富的产品经理最头痛的问题，怎么才能让比你更资深的工程师、设计师信服你，激励他们把自己的才华最大限度地应用到你的产品中。我通过个人“摸爬滚打”的经验，和你分享了四招：

第一招，建立信任从帮忙打杂开始，从一开始就帮助大家做实事，宁可踏实做“脏活累活”，也不夸夸其谈、装模作样。

第二招，和资深成员建立信任关系，虚心请教，让他们帮助你成长。

第三招，弄清楚资深成员的需求，无论是引领创新还是做最有挑战的事情，成人之美，尽可能地满足他们的需求。

第四，靠产品成绩说话，尽快做出结果，高效执行，只有真正能够推动产品进展 ，你才会得到大家的支持。

思考题

你和团队中的资深成员相处时，遇到了哪些挑战？你是如何做的？ 效果如何？

欢迎你给我留言。

28 | 产品经理的晋升秘密

在硅谷的顶级公司，产品经理一般分为很多不同的级别,，是一个可以通到公司最高层的职位。比如，在谷歌或者 Facebook 这样的公司，产品经理可以做到副总裁的级别。

有些公司喜欢把产品经理的等级分得很清楚，比如微软，但是像 Facebook 这样的公司都叫“产品经理”，从职称来看根本分不清楚谁是高级的、谁是新人，但事实上通过产品经理所管理的产品的工作范围，你就可以非常清楚地知道他是什么级别的。

那么，首先我来跟你分享一下不同级别的产品经理都在思考什么、做什么。

一个刚刚入行的初级产品经理，他们管理的产品范围会比较小，一般是一个具体的产品功能。比如，负责 Facebook 的头像功能。 初级产品经理的另一个特征是，他们管理的产品在策略上一般比较明朗，公司已经基本上明确了要做什么，只是一些具体的小细节需要他们自己研究。

所以，对于一个初级的产品经理来说，最重要的是有很强的执行力、权衡取舍分清主次的能力，以及能够快速引导产品下一步迭代的能力。

说白了就是，这个产品经理是不是具备制定一个短期成功指标的能力，能不能进行项目管理，能不能很快地帮助工程师、设计师等团队成员快速解决疑难问题，从而推进产品功能的发布以及迭代。

一个比较成熟的骨干产品经理，管理的就是一整个产品了。 比如说，Facebook 的主页。这个时候他们就需要制定一些稍微长期的未来一到两年的策略了，他们的工程团队也在逐渐扩大。

对这样的产品经理来说，他们需要能够制定一个长期的成功指标，并且能够把这样的长期指标和近期数据对接，知道怎样通过眼前的数据来估测产品的发展是不是在所希望的方向上。

比较成熟的骨干产品经理，还有可能会管理一个从 0 到 1 的产品。这样的产品需要他们从头开始了解用户需求，并且快速证实用户假设。

比如，我们要做一个给年轻人听音乐的 APP，这个 APP 能够自动给年轻人推荐最近刚刚火起来的小众歌手。这时产品经理就需要通过一系列的调研以及数据，快速了解年轻人是不是有这样的需求，从而得出这个产品该不该做的结论。

到职业生涯中期的产品经理，一般就开始管理一个产品领域了。 比如，帮助 Facebook 用户更好地表达自己的一系列产品，可以是主页，可以是自拍 GIF，也可以是自制表情包。

这个时候他们可能就需要从头制定这个领域的产品策略。和之前两种产品经理不同的是，老板一般不会告诉他们要做什么，而是会问他们我们应该做什么。

说白了就是，这样的产品经理已经能够独挑大梁，帮助公司制定未来中长期的产品策略，并且知道如何组织团队的架构。

这种级别的产品经理，会思考类似“帮助用户更好表达自己”的产品领域，有没有什么方式能够把涉及的产品归类，每个类别都可以找一个产品经理分别管辖。

比如说，第 1 类是用视频方式来帮助用户表达自我的产品，第 2 类是用文字和语音来帮助用户表达自我的产品，第 3 类是用 GIF 来帮助用户表达自我的产品。

可能还有别的分类方式，比如帮助高中生表达自我的产品、帮助年轻人表达自我的产品、帮助 40 岁以上的中年大叔大妈们表达自己的产品、帮助老年人表达自我的产品。

那么，这两种分类方式哪种更好呢？其实，这是要取决于这个产品或者公司面向的用户群体。

比如，如果是阿里巴巴的话，可能最重要的是按照年龄划分，因为相同年龄段的人可能买的东西也很相似，所以最重要的是帮助用户更好地表达自我。你可以通过他们的同龄人的表达方式，去激发他们的购买欲。

如果是美图秀秀的话，可能第一种方式更加妥当，因为用户使用美图秀秀， 需要的是能够快速做出最好看的视频、最酷的表情包， 因为用户对于视频、图片、表情包等表现形式有不同的要求，所以按照不同的表现形式来划分更妥当。

到职业生涯中期的产品经理，能够把公司的整体发展策略和自己的产品领域相对应， 他们思考的是怎么用自己的产品来帮助公司实现整体的产品策略。

当然到了职业发展的顶层，产品经理负责的可能是整个公司的产品策略，这个时候探索创新的能力就非常重要了。 比如，Google 是不是应该进军区块链， 阿里巴巴是不是应该做一个自己的 Uber，这种关系到公司策略的大问题，就需要这些产品高管来把关了。

在大公司，其实很多的产品高管，还会思考要不要收购某些小公司，以及收购后怎么发挥这些小公司的价值。

顶尖科技公司的产品高管，衡量他们成功与否的标准，不是某一个产品的使用量怎么样，而是这个公司是不是在行业内到了更领先的地位，是不是对公司股价产生了积极影响等等。

这时，产品高层的大部分时间就不是和工程师在一起了，他们更多地是给其他产品经理的产品策略以及产品功能提建议和意见。

产品高层还要解决的问题是，管理一个几百人的产品团队，如何更好地培训、招聘、管理产品经理，如何促进部门之间的合作与沟通，什么时候需要把团队成员重新分组、重建组织结构、也就是硅谷说的 reorg，这些工作内容占用了产品高层更多的时间。

说了这么多产品高层和产品菜鸟之间的区别，那么怎样才能加快升职的速度呢？

第一，如果你是个产品菜鸟，你可以思考一下自己负责的产品对公司整体有什么影响。

比如，虽然你现在只负责头像这一个功能，那有没有什么方式能够让用户多关注其他人的头像装扮，从而激发购买欲呢？让用户可以互相圈各自头像上的美妆产品，做一个社交美妆软件？或者用户每次购买新东西的时候都可以更换一次头像呢？

你也可以多看看公司高管每天都在讨论些什么，然后思考自己的产品能够怎样帮助高管们解决这些问题，那么你的产品会更容易引起高层的注意，他们也会觉得你有整体观念和全局观念，从而实现晋升。

第二，你可以思考一下怎样才能扩大你的产品版图。

有什么方式能让你不只做头像？你可以从思考头像的目的是什么，我们为什么需要头像开始。我们需要头像，是因为我们需要更好地表达自己是谁、来自哪儿、喜欢什么，那么你可以继续思考有没有什么其他的产品功能或者一个单独的产品，能够帮助用户更好地表达自己？

比如说，除了自己的头像，你可不可以选择一个卡通人物来代表自己此时此刻的心情，能不能用 5 个弹幕来表达最真实的自己，等等。当你这么做的时候，你也就从只负责一个产品功能，延伸到了一个产品领域。

第三，你可以思考一下你的产品如何帮助公司的长期策略，让产品在未来三到五年一直保持领先。

年轻的产品经理一般比较关注当下，更在乎此时此刻、产品刚发布的时候什么数据比较好看，很容易忽略长期的目标和任务。但是，一个比较有经验的产品经理会思考，产品刚刚发布时采取的一些推广策略，会不会破坏产品的长期规划。

比如，给用户发的推送信息太多，他们会不会直接屏蔽所有推送。这些产品经理在一开始就会思考怎么才能保证这个产品在未来三年还是成功的，有没有什么方式能够一步一步接近于长期的成功。

第四，不要局限在思考产品，你还可以思考一下公司的产品管理流程是怎样的。 比如，产品经理的培训和选拔机制有没有什么可以改进的地方，对新的产品经理的培训是不是有效。如果你是一个产品菜鸟，那不妨给高管们提提建议，哪些方式能够帮助新人更好地适应公司的环境，自己可以为此做些什么。

记得我刚入行时犯了一个错误，觉得我是新人就应该听老板的，让我干嘛我就干嘛，所以每天都在等老板给我安排工作。结果，虽然我感觉自己工作很努力、很认真，但一直都不是明星员工。

然后，我就开始观察明星员工的做法。我发现，他们每天不仅仅等着老板发号施令，而是能够主动地、积极地去探索，有没有什么东西是大家都没有注意到的。可能会涉及到一些不属于自己本职工作的事儿，但只要能够对公司的发展和产品的开发有帮助，他们都会去做。

试想一下，如果你是老板，你是喜欢一个只会等你发号施令的人，还是喜欢一个凡事儿都想在你前面，能够帮助你解决你自己可能都还没发现的问题的人呢？所以，一个新人一定要主动主动再主动，不要被自己刚刚进入职场的条条框框限制住，这一点适合于所有的职业。

第五，在硅谷还有另外一个升职的捷径，就是能够发扬自己独特的优势，快速在行业内建立领域专家的地位，当你在行业内有影响力的时候在公司自然就有了影响力。

比如，你是一个产品增长专家，公司其他产品需要解决增长问题的时候也要来问你的意见，你就逐渐建立了在整个公司内的专业影响力。

或者，你自己写了一本从零到一做产品的书，获得了非常高的评价，在业界有了一定的知名度，即使之前你并不一定是老板的宠儿，业界影响力也会让老板不敢小瞧你。

尤其是在大公司，人山人海，怎样能快速显露自己的优势、让自己被注意到，其实是一门学问。

总结

今天这篇文章， 我给你揭秘了不同级别的产品经理的工作内容，以及需要具备的能力。你可以据此思考一下自己怎么才能成长为更高级别的产品经理。

我也跟你分享了五条可以帮助你在产品经理岗位上步步高升的小建议，帮你实现晋升：

第一，你可以思考自己的产品对公司发展的影响；

第二，你可以考虑如何扩大自己的产品版图；

第三，进行长线思考，而不是局限在短期目标上；

第四，你可以思考如何提升产品开发流程；

第五，你要弄清楚自己的独特优势是什么，以及如何发挥。

思考题

如果你是一个产品经理，你现在每天的工作内容，属于上面提到的什么级别呢？

如果你现在是一个负责的让用户能够搜索当日主要新闻，并点击进入到对应的网站阅读全文功能的产品经理，你该如何从这个功能出发，扩大产品版图呢？

欢迎你给我留言。

29 | 你需要一个产品路线图

产品路线图，又称 Roadmap，是很多人说起产品经理时最先想到的内容，而这也确实是产品经理工作中非常重要的一部分。

市面上关于产品路线图的文章有很多，制作路线图的软件也是应接不暇，但是我发现很多人讨论得更多的是产品路线图是什么格式、要用什么软件画，却忽略了产品路线图本来的目的，至有些人把产品路线图和需求文档的概念混淆了。

那么，今天我就跟你分享一下，为什么要做产品路线图，以及我平时怎么做产品路线图。

产品路线图的目的

首先，产品路线图的目的是让团队成员清楚知道产品要往哪个方向走，怎么走，以及在什么时间要做什么事情。

路线图的英文叫作 Roadmap，由 road 和 map 两个单词组成。说到底，路线图首先要告诉团队成员我们要去哪，路在何方，也就是 road；然后告诉他们我们应该怎么去，如何达到目的，这就是 map。

所以，产品路线图一定要立足于产品的愿景（vision），告诉团队成员我们如何一步步实现产品的愿景。

给你举一个 Facebook 大老板扎克伯格制定产品路线图的例子。

这是 Facebook 未来十年的产品路线图，由扎克伯格在 2016 年提出，愿景是连接整个世界，让人与人之间的距离更近。那么如何实现呢？

在未来三年（2016~2019 年），我们立足于 Facebook 生态系统，让 Facebook 继续帮助人们更好地与他人连接。

在未来五年（2016~2021 年）， 我们将从视频、搜索、小组、Messenger、WhatsApp、Instagram 着手，让世界各地的人通过 Facebook 旗下的这些产品，分享各种各样的内容（图片、视频、文字等）。

在未来十年（2016~2026 年），Facebook 将会大力发展核心技术，在网络硬件、人工智能、虚拟现实等方向，为人与人之间的连接作出质的贡献。

从 Facebook 十年的产品路线图中，你可以看出，扎克伯格首先是从整个公司的愿景出发，然后层层深入；从近期的三年计划着手，然后步步深入，最后十年计划一出来，整个公司仿佛看到了一个让整个世界连接更紧密的蓝图。

当然，大部分产品经理管的是一个具体的产品，也不会做一个十年规划的路线图，但是产品路线图的目的都是一样的：先立足于产品要达到的最终效果，以长期愿景为目的，然后一步一步告诉团队成员如何实现。

但是，有些产品经理的路线图，说白了就是一个任务清单，列出了一个个要完成的任务，团队成员看完后，并不清楚到底要达到什么目的，成功指标是什么，这最多算一个项目管理档案，不能叫作产品路线图。

一个好的产品路线图，应该是你读完后：

首先，明确产品的长期愿景；

然后，明确分为哪几个阶段，每个阶段的成功标准是什么，每个阶段之间有什么样的逻辑关系，才能实现最后的长期愿景；

最后，明确每个阶段我们具体要做什么，以及怎么做。

一般来讲，越是高级的产品经理，想得越远，产品路线图横跨的时间范围越广，这种产品路线图的难度也越高。

好的产品路线图，团队成员看完后，应该有种“哇塞，我做的事情真酷”“哇塞，我看到了我们一步一步如何实现最终的成功”这样的感觉，并且团队的每个人都知道：

我们这半年要做的事情，和长期愿景到底有什么关系；

我们这半年做的事情，分为哪几个部分，重要性和优先级都是什么。

产品路线图的内容

我一般会有整个产品团队的路线图，和每个产品的路线图。我的产品团队负责很多产品，所以整个团队的路线图更多得是写我们这半年要达到什么目标，这个目标如何帮助我们离成功更进一步。

下面我通过一个具体的实例，向你展示一下，我一般会按照什么样的框架，来写产品团队的路线图。

团队愿景： 成为最有效的网红和粉丝之间沟通互动的工具，这也是我们团队一直以来的愿景。这个愿景的实现包含了我的产品团队下的许多网红产品，比如粉丝给网红打赏，网红和超级粉丝互动等产品。

成功是什么样子？ 网红首选我们的工具和粉丝沟通，粉丝和网红每周至少互动一次。

下半年的成功是什么样子的？ 比如，50% 粉丝和网红每周至少互动一次。

下半年如何实现这样的成功：

帮助网红找到铁粉。（P0）

给铁粉特别的徽章；

铁粉排行榜。

帮助新粉丝找到自己感兴趣的网红。（P0）

网红发现广场；

每天推荐 5 个网红给新粉丝用户。

提供网红和铁粉之间互动的工具。（P1）

让网红直接选定有特点的粉丝进行互动；

让网红举办针对铁粉的抽奖活动；

方便网红创造铁粉专属内容的工具。

以上三个重点问题是我们这半年工作的核心，我们将通过上面的 7 个产品功能解决。

有时，我还会详细说清楚每个部分的优先级，让团队成员可以优先解决最重要的问题，以最高效的方式实现成功指标。 比如，帮助网红找到铁粉最重要， 那这个问题就是最优先的，用 P0（priorioty = 0，优先级最高）表示，提供网红和铁粉之间互动的工具的优先级是 P1。

注意，我并没有在“如何实现这样的成功”这部分，直奔要实现的 7 个小功能，而是先拆分为三个重点，然后再说明解决每个重点问题，需要实现的具体功能。

通过这个整个产品团队的路线图的例子，我要表达的重点是：产品路线图中，一定要先明确团队要实现的愿景以及成功的标准，然后再说当前的计划和成功标准，这样团队成员很快就能知道我们当前的计划对总体计划有什么帮助。

有的时候，我会在“成功是什么样子”这个部分加上日期，这样才让大家有紧迫感。

比如，我们要在 2019 年上半年实现：网红首选我们的工具和粉丝沟通，粉丝和网红每周至少互动一次。

那么，2018 年上半年我们要实现 50% 的粉丝和网红每周至少互动一次，2018 年下半年我们要达到 75% 的粉丝和网红每周至少互动一次的指标，以及我们的产品要成为网红的前三个选择。

这样，2019 年上半年我们就可以实现最终的成功。

对于一个粉丝给网红打赏的产品，你可以这么写路线图：

产品愿景： 让网红可以以赚取粉丝的打赏为生；让粉丝得到网红特别的关注。

成功标准： 10000 个网红能够达到月收入 10000 元。

2018 年上半年的成功标准： 1000 个网红能够达到月收入 5000 元。

2018 年下半年的成功标准： 5000 个网红能够达到月收入 5000 元，1000 个网红达到月收入 10000 元。

2019 年上半年成功标准： 10000 个网红能够达到月收入 10000 元。

然后，我们具体说 2018 年上半年的成功如何实现：

目标是 1000 个网红能够达到月收入 5000 元，为此我们需要，让已经有粉丝打赏的 200 个网红得到更多的赏金，让还没有得到任何打赏的其他网红（假设目前有 3000 个）中的 800 个月收入达到 5000 元。

接下来，你就可以按照上面整个团队路线图的逻辑划分出重点问题了：

是让粉丝加大打赏金；

培养更多粉丝打赏的习惯；

是增加粉丝用户的数量。

然后，你就可以按照上面整个团队的产品路线图的逻辑，设计每个部分的产品功能，来能实现成功目标了。

总结

今天我跟你分享的主题是，产品路线图。接下来，我给你提炼一下今天内容的要点：

产品路线图的目的是制定产品阶段性的计划，从而让产品实现最终的愿景。这要求产品经理从愿景出发，为每一个发展阶段制定成功标准和策略，而不只是简单罗列亟待完成的事项。

即使一个产品团队负责一个产品线的多个产品，也应该有整个团队的产品路线图，以及每个产品的产品路线图。

产品路线图应该由产品愿景、成功标准、现阶段成功标准、现阶段发展重点、每个发展重点下的具体产品功能这些部分组成。通过划分现阶段的发展重点，增加产品路线图的逻辑性、可读性，并进一步划分产品团队，让每个人都能认识到自己的工作如何帮助团队实现产品愿景。

思考题

如果让你设计抖音未来三年和 2018 年下半年的产品路线图，你会怎么写？

欢迎你给我留言。

30 | 如何制定产品优先级 ？

制定产品优先级是产品经理的必备技能，但这个必备技能着实是一块儿“硬骨头”。

在日新月异的科技行业，计划赶不上变化， A/B 测试可能带给你新的结论，竞争对手可能打乱你的步伐，产品功能比之前计划得要复杂得多，这样的变化都会改变产品优先级。

所以，每个产品经理需要做的，就是要在高变化、高不确定性、高复杂性的情况下制定出优先级，让产品以最快的速度、最小的代价取得最大的成功。

可见，制定优先级并不是一件易事，但更难的是要说服其他人认可你制定的优先级。

为什么需要产品优先级？

产品优先级，可以让团队成员明确哪些功能是需要优先做的，哪些功能是无关紧要的，从而在最短的时间内解决产品最关键的问题。

如果没有明确的优先级，团队成员就会失去方向，各打各的小算盘无法高效合作；产品优先级弄错了，就会耽误产品进度，而且你认为不重要的功能被竞争对手抢先发布了，对创业公司来说可能就关乎生死了。

我见过许许多多的产品团队，无论是成熟的产品团队，还是从零到一的产品团队，也接触过无数的产品经理，无论是资深的行家，还是刚刚入行的新人，这些产品团队和产品经理，都有一个共同的特点，那就是永远有做不完的产品任务，从来没有把事情都做完的时候。

而且，每次产品发布前的一个星期，总会出各种各样的问题，产品经理总会有各种危机要处理，甚至会修改之前的计划。

所以，如果产品团队没有优先级，而是按照顺序一个一个地做所有的任务，那么产品永远都不会被发布。

在 Facebook，我们每个产品经理都要遵循的一个理念是：权衡取舍要无情。这句话重要到我们已经把它做成海报贴在了公司墙上，所有人每天上班前都会看到。

产品优先级的误区

在制定产品优先级时，有以下这四大误区，需要特别注意。

认为所有功能都优先，这句话同时意味着所有功能都不优先。 很多时候我发现，刚入行的产品经理会在产品需求文档洋洋洒洒地写上十几个功能， 而且每个功能都是紧急，这样做根本就是没有搞清楚产品的优先级。
在我看来，产品的优先级是要分等级的，如果你有 10 个功能， 最多有三个功能是最优先，也一定有三个功能是不优先的。
产品优先级的等级，我一般喜欢用 P0、P1、P2 表示，P 代表 priority，P0 指最优先，P1 指一般优先，P2 则可以以后再做。在 Facebook，我们的共识是 P0 是现在要做的，P1 是有空就做的，P2 是一定来不及做的。

认为优先的功能是最简单的功能，这源于产品经理对最小化可行产品的误解。 最小化可行产品， 是确保产品功能只要满足用户最基本的需求就可以了，但并不等于说产品只有最简单的功能。
最优先的功能应该是最有价值的功能，如果一个产品只具备一堆锦上添花的、最简单的功能，那它并不能算是一个完整的产品，它的优先级出了问题。

判断产品优先级时只考虑工程难度以及预期效果，而忽略了这个功能的潜在风险。
如果产品需要下个月发布， 有一个功能非常重要，也不难做，但是涉及到和其他的组的合作。而目前这个组的团队有问题，很有可能这个功能无法按时完成，而产品的发布时间必须要保证。
那么，这时候你就要思考这个功能到底是不是优先，是不是应该先做低风险的功能以确保产品发布。

在做产品计划时，没有明确什么叫做最优先。 比如，产品有三个最优先的功能，发布前其中一个没做完，那么你到底是应该选择先发布两个已经做完的功能，还是推迟整个产品的发布时间，等第三个功能完成后一起发布？
很多产品经理事先都没有考虑这个问题，导致产品发布前出现了突发情况非常慌，和团队成员争论不休，从而耽误了产品发布的良机。
所以，我建议，在做产品计划时就应该先明确，这些功能到底是不是重要到推迟产品发布也要等的程度。

你的产品优先级决定真的算数吗？

很多时候产品经理并不直接管理所有的团队成员，特别是在大公司，每个细分领域都有具体的部门来执行，而这些部门并不直接对产品经理负责。

举个简单的例子，市场营销部门会直接汇报给市场营销总监，所以你的市场营销经理更在乎的是总监在乎的指标，而不是你在乎的指标。

如果你制定的产品优先级和其他部门的不一致，那么你的产品优先级多半不算数。即使你分析得再准确，沟通得再清楚，甚至你的团队成员也哼哼哈哈地同意了，但最终他们并不一定会按照你的优先级来。

我在负责网红产品时，就经历了和市场营销部门的优先级不一致，而影响了产品的事情。我的产品团队有专门负责传媒公司营销策略的市场营销经理，当时我把对小型明星工作室更有帮助的功能，定为了最优先。而这个市场营销经理汇报的部门衡量成功的标准是，传媒公司客户的满意度，因此他们最优先的几个项目都是和传媒公司有关的。

虽然我说服了市场营销经理认可我制定的优先级，他也认为这对我们团队来说是最正确的选择，但在实际工作中，他并没有按照我制定的优先级来。而我们中间又缺乏了有效地沟通，最终影响了我们这个功能的正常发布。

后来，为了解决这种问题， Facebook 在每半年计划的时候， 都会让不同的部门交流彼此的优先项目，提前找出利益冲突的部分。

这样，在制定计划时就充分交流，提前发现问题，有冲突时要么修改各自的优先级，要么修改成功指标（毕竟成功指标是决定优先级的核心标准），可以最大程度地避免对产品发布的影响。

无情的权衡取舍还要明确我们一定不做什么

在 Facebook，我们一直在讲产品经理要无知、无畏、无情：

无知，就是产品经理不应该马上下结论，而是应该保持好奇心，提出假设，然后验证假设；

无畏，就是产品经理应该勇于制定有难度达到的成功指标，更好地激发团队潜力，而不是为了不担风险只打安全牌；

无情， 就是我今天跟你说的， 不管产品的想法多么好，可做的事情多么重要，都一定要分出个主次， 明确我们一定不做什么。

我在 Instagram 的一个老板，在制定产品线路图和优先级时，喜欢加一个“一定不优先”的板块，这个部分专门写那些我们肯定不做、 明确不是优先级的内容。

我第一次看到这个版块时，完全不理解为什么要花这么大精力去写一堆不用做的内容，但真正和团队磨合时， 我发现经常会有人提出我们要不要试试这个功能、要不要也做一做那个功能，或者某一个领导突然对某个东西感兴趣随口问了一句， 大家就蜂拥而至，要修改原有的产品计划，做这个功能。

这样的情况时有发生，虽说可以活跃产品团队氛围，但更多的却是干扰，导致产品的实际执行不能按照既定轨道进行。我的这个老板的“一定不优先”版块，目的就是降低这样的干扰。

他可以自如地给大家展示这个文档，问大家有没有最新的用户反馈，如果没有的话，我们就明确这个功能一定不优先；有没有什么新的信息需要我们改变策略，没有的话，我们就继续按照原定计划执行。这样一来，大家很快就能回到正轨，减少干扰。

总结

今天我给你分享的主题是如何制定产品优先级，这部分涵盖了制定产品优先级的计划、灵活调整优先级、沟通优先级、和与其他部门对优先级达成共识。

我还跟你分享了产品优先级的四个误区：第一，认为所有功能都优先；第二，认为优先的功能是最简单的功能；第三，制定优先级不考虑这个功能的潜在风险；第四， 在做产品计划时没有明确什么叫做最优先，什么情况下我们即使推迟产品发布也要等。

最后，我们跟你分享了产品经理的无知、无畏、无情，“权衡取舍要无情”是 Facebook 的理念，希望和你共勉。

思考题

我在文中提到的产品优先级的四个误区，你曾经中过哪个？

欢迎你给我留言。

31 | 好的产品经理和卓越的产品经理

在 Facebook，我们面试产品经理有一个坐飞机测试，作为面试官，我们得回答，如果眼前这个候选人需要和我坐十个小时飞到亚洲，我愿意让他做我的邻座吗？也就是说我到底会不会强烈推荐这一个人。

我们还有个请假测试，就是这个人好到你会请假半天，放下手头的事情，开车到他家门口求他入职吗？

如果任何面试官对这个人都没有这个冲动，我们就没必要录取他。通过这样的测试，我们希望能够找到卓越的产品经理，而不只是还好的产品经理。

那么，现在我就结合面试产品经理的经验跟你分享一下，卓越的产品经理和好的产品经理之间到底有什么区别。

我之前在 36kr 上发表过《Facebook PM 谈顶级产品经理具备的 4 个特征》一文，大家反响热烈，今天我在这篇文章的基础上，增加了很多全新的内容，希望可以让你更好的理解卓越产品经理的思考方式，助你成为一名卓越的产品经理。

痛点真实存在吗？

我在面试产品经理时，经常会让面试者设计一个产品，比如，设计一个给 00 后看新闻的产品。

普通的产品经理面试者，会假设他设计的产品解决的痛点是真实存在的。 他们会在白板上迫不及待地写下”00 后想看新闻”几个大字，然后告诉我可以给 00 后做个短视频新闻平台、做个“鹿晗讲特朗普”的模块、做个 00 后的今日头条。

卓越的产品经理面试者，会先搞清楚用户到底有没有这个痛点。 他们会先停下来，思考 00 后到底有没有看新闻这个需求。

如果确实有这个需求的话，他们接下来会思考，00 后是不是真正需要一个新的看新闻的产品，今日头条或者微信不能满足他们的需求吗？

卓越的产品经理，并不会一开始就告诉我产品应该设计成什么样，而是告诉我他们打算采取什么方式用最快的速度验证这个需求是不是真实存在。

长期的产品目标和短期的产品目标

在面试产品经理时，我还曾以一个给年轻人找职业导师的产品为例，让面试者回答怎么衡量这个产品是成功的。

好的产品经理面试者，会马上给我一个产品指标，比如月活数、日活数。 他们会说，这很简单啊，你就看“平均每一个用户找到了几个导师”，并马上给了我一个数据指标。这个指标很有道理，但并不全面。

卓越的产品经理面试者，会告诉我短期的小目标是什么， 长期的大目标是什么。 一个特别优秀的面试者告诉我，这个产品最重要的是帮助年轻人找到好的职业导师，从而帮助年轻人更好地提高自己，所以长期来看，产品的成功指标是这个年轻人的薪水有没有涨，和这个导师的联系频率，短期来看，我们可以看看每个用这个产品的年轻人找到了几个导师。

产品刚发布的时候，上面说的两个指标都不重要，因为年轻人必须有导师搭理他们才会继续用这个产品，所以其实更重要的指标，是年轻人给导师发消息之后有百分之多少的导师回复了。

得到的代价是什么？

好的产品经理面试者，“头脑风暴”的方式是给我 20 个主意。 他们以为给我的想法数量越多，越能向我证明他们是“有创造力的好产品经理”。

虽然他们的天马行空让我很欣赏，但是天马行空后他们并不能很好地权衡取舍，选出产品真正需要的想法。

卓越的产品经理面试者，“头脑风暴”时不仅给我主意，而且会告诉我每个主意有什么代价。

比如，第一个想法，能够给我们带来新用户，不过可能会烦到老用户；第二个想法，能够帮我挽回已经流失的用户，但是对增加新用户没有什么帮助。

然后，他会告诉我，现阶段我们这个产品最重要的是吸引新用户，产生集群效应，所以尽管第二个想法非常酷炫， 集合了 AI、机器学习、深度学习、VR、AR 等等，我们还是应该按照第一个想法优化产品体验。

只在乎自己管辖的产品功能

我曾经让面试者在 Facebook Messenger 上，设计一个朋友在你生日的时候给你发生日 GIF 图的产品。

好的产品经理面试者，只在乎自己负责的产品。 他们会告诉我，评价这个产品成功与否的标志是看生日 GIF 图的使用数量。他们说的没错，但是 90% 的面试者都是这么说的，所以无法脱颖而出。

卓越的产品经理面试者，思考方式可以达到产品总监／首席产品官的高度。 我高分录用的一个面试者告诉我，他不仅会看生日 GIF 图的使用数量，还要看 Messenger 的其他数据。

比如，现在朋友可以给你发生日 GIF 图送祝福了，那他们是不是就不会在 Messenger 上发信息祝贺你了，或者是不是就不会在 Messenger 上打电话祝贺你了。但是很多时候，朋友们一个字一个字敲出来的祝福信息，比 GIF 图更有心意，所以对整个 Messenger 产品来说，生日 GIF 图发送数量的增加不一定是好事。

这个面试者不只把自己当成生日 GIF 图的产品经理，他的思考方式更像是整个 Messenger 的产品总监，因此被高分录用。

不符合公司之前同类产品的流程

如果你设计了一个视频产品，但是我对你说，你的这个产品不符合公司视频产品的设计准则。这里的产品设计准则，是说公司制定的针对产品线中所有产品的设计哲学和原则。

好的产品经理面试者，会说我换个方式再想想看吧。 他们很听话，一听我说公司的其他产品不是这么设计的，马上就说那我换一个功能，或者换一种方式吧。

卓越的产品经理面试者，敢于思考公司的设计准则是不是有问题，可否优化设计准则本身。

他们会说，公司之前的视频产品为什么制定这样的设计准则，之前的视频产品和现在这个功能相比有没有本质区别， 这些设计准则是不是可以进一步优化，我是不是可以通过现在这个产品，优化整个公司制定的视频产品设计准则，便于以后其他的产品也能做像我这样的事情。

抽象化和细节化

比如，我让面试者设计一个帮助好朋友过生日的功能，好的和卓越的产品经理的思考方式也会不一样。

好的产品经理面试者，设计产品功能时会一步一步按照流程来。 他们会一步一步地告诉我，应该有什么功能、如何权衡取舍，给我画个 UI 图，然后告诉我衡量成功的标准。

卓越的产品经理面试者，设计产品功能的时候有思考框架，现在的功能和以后的创新都按照这个框架来。

他们会告诉我帮助好友过生日，实际上是满足了让他觉得受到了关注，让他感觉自己是个靠谱的人，以及让朋友间的关系更深一步的需求，也就是满足了三个大框架：有在乎自己的人、让自己更加在乎自己， 以及有互相在乎的关系，这三个人性的核心需求。

所以，卓越的面试者会告诉我，产品的基本功能要涵盖这三个人性需求，但是最小化可行产品（MVP）在每个方面做到基础的程度就可以了，下一版的产品计划再进一步深挖这三个基本的人性需求，也就是产品以后创新的方向。

个人特点和风格

好的产品经理面试者中规中矩，但就是没什么特点，无法打动面试官。 他们经常问 Facebook 喜欢什么样的产品经理，或者自己在网络上搜索 Facebook 产品经理的特点，然后照葫芦画瓢，以为自己表现的像一个 Facebook 的产品经理就一定没有问题了。

卓越的产品经理面试者特点鲜明，让面试官们吵得不可开交。 当然，我这里并不是说我们会为所有卓越的 PM 面试者是否被录用而争吵，偶尔也会有大神级别的人物，大家一致同意要不惜一切代价挖到手。

一般情况下，我们与其要一个有人特别喜欢、而有人不是特别感冒的候选者，也不会选择一个大家都觉得还可以但都提不起兴趣的人。所以，我对想成为卓越的面试者的建议是，深挖你的特点，不一定非要是优点，但是又可以成为优点的部分，然后想尽一切办法发挥这个特点。

比如，我个人的特点就是，精力旺盛、非常有激情，缺点就是太有激情有点急脾气、风风火火。我每次面试产品经理职位时，都会 100% 体现我的这个品质，让所有的面试官起码记得住这个人非常有激情。

可能会有人看不惯我的风风火火， 但不至于因为这个拒绝我， 而有些人就会非常喜欢我，告诉公司一定要让这个人来，那最终的结果就是，我拿到了理想的工作。

总结

我给你对比了好的产品经理和卓越的产品经理之间的区别，希望帮你了解卓越产品经理的思考方式，搞定你的产品经理面试，拿到你想要的工作。

一个卓越的产品经理在面试时，会从以下几方面打动面试官：

设计一个产品时，他们会先搞清楚用户到底有没有这个痛点，并分别给出短期目标和长期目标；

他们不仅会给出“头脑风暴”的想法，并会明确说明每个想法的代价是什么，怎么权衡取舍才会达到最优；

他们的思考不仅局限在于一个具体的功能，而是可以全盘考虑对整个产品的影响，可以达到产品总监／首席产品官的高度；

他们对公司的既定流程提出质疑，并给出优化流程的建议；

他们在设计产品时会先思考框架，而不是一上来就设定每一步的细节流程；

他们会在面试者展示自己的特点，往往更能打动面试官们，或许不能获得一致认同，但相比没有特色的面试者会更容易得到理想工作。

思考题

请你设计一个让 00 后看新闻的产品。

你是短视频 UGC 平台的 PM，你发布的新功能在测试阶段，用户每天观看视频的平均时间增加了 10%，但是平均每个用户发布原创视频的数量却降低了 5%。请你思考一下，这个新功能应不应该发布？

欢迎你给我留言。

32 | 产品经理面试考察的是什么？

在 Facebook，大部分的资深产品经理都要同时兼任面试官的工作。

我在 Facebook 也做了很长时间的面试官，每个月都会面试 7~8 个产品经理候选人，这样的经历让我了解了硅谷的顶尖公司如何评判、选拔产品经理，要考察候选者的什么能力，以及如何考察这些能力。

面试形式

面试工程师时，你可以通过算法问题去评判一个工程师的逻辑能力、代码质量如何。

但是，面试产品经理就没有这么简单，要考察的内容会很全面，也没有一个具体的量化标准，甚至有些是属于人格魅力的内容，面试多以对话的方式进行。

虽然产品经理面试没有一个准确的量化标准，但是通过面试，我们要考察的重点，即候选人的分析能力、讲故事的能力、沟通能力、 权衡取舍的能力、解决问题的能力，是确定的。

针对这些能力的考察，我们一般会通过产品体验设计、产品分析和执行、领袖气质和团队管理这四个主题展开。

产品体验设计:

能力：面试者是否能从用户需求出发，设计出整个产品体验，满足用户需求；

形式： 我们会问一个非常大的问题， 看面试者如何层层递进，按照一定的逻辑关系，找到产品要解决的问题精髓，制定出靠谱的产品解决方案；

经典题型：设计一个 00 后使用的新闻 APP。

产品分析和执行:

能力：面试者能够深入浅出，把一个模糊不清的问题清晰化、具体化，把大问题拆分成可以逐步解决的小问题；

形式：我们会问一系列的产品分析、数据分析、权衡取舍、优先级这样的问题；

经典题型：视频产品的浏览量降低了 20%，作为产品经理，你应该怎么做？

领袖气质:

能力：面试者是否体现了领导能力，沟通能力，同理心，勇往直前的勇气；

形式： 我们希望通过具体的案例以及假想问题，让面试者非常详细地描述解决这些情景的方法，尽可能地用具体的事例和详尽的细节展示他的领导能力；

经典题型：让面试者说一个，以前挑战权威的例子。

团队管理：

能力：面试者是否能在艰难的环境下掌控局面，和团队成员建立信任关系；

形式：我们会问一些非常具体的情景， 如果面试者以前有相应的经验，他可以说说以前的故事，否则可以说说如果这个事情发生了， 他会怎么做；这部分更适合和面试者面对面的谈心， 甚至他说的每一句话我们都会仔细询问；

经典题型：你的一个工程师不信任你，作为产品经理，你会怎么做？

面试流程

硅谷顶尖公司的面试流程一般比较相似：

首先，是和人力资源部面试，这个部分就是问你的简历和以前的经历，看看公司的哪个职位比较适合你。

然后，给你安排电话面试，我们一般有两轮电话面试，分别考察你的产品体验设计和产品分析能力。

表现好的人会进入最后一轮面试，一般会让你到公司和面试官面对面交流，这个部分不仅考察全面体验设计和产品分析执行能力， 还会考查你的领袖气质和团队管理能力。

我们有一个内部系统，面试官可以输入对候选人的评价，大家提交评价前看不到其他面试官的评价，为的是让面试官独立作出考评，保证面试的公平性。

并且，在填写评价时，面试官需要在“强烈推荐”“一般推荐”“有点推荐”“有点不推荐”“一般不推荐”“强烈不推荐”6 个等级中选择一个。

如果候选人进入最后一轮面试，那么所有的面试官会专门开一个会，面对面讨论这个人到底能不能录取。这个会一般由一个产品高管主持，大家各抒己见，经常会出现几个面试官争论不一的情况。

比如，一个面试官说这个人是我见过的最有创新能力的产品经理，另一个面试官却说他逻辑不清楚我不想推荐他，那最终就看这两个面试官谁能说服对方，如果还是意见不一的话，我们一般会再安排一轮面试。

一般情况下，如果所有面试官都认为这个人是“有点推荐”，那么这个人也不一定会被录取。而那些让面试官愿意为他们和其他面试官争取的面试者，才算是值得被录用的。

面试考察的是综合能力

一般情况下，我们面试产品经理时，会综合考虑候选人，让他们开放进组，即我们不会考虑他对于某一个具体的部门是不是合适， 而看他适不适合整个公司。

进入公司后，我们会在新员工培训时，给机会让新人和各个部门老板聊天，双向选择，这个过程叫作新兵训练营（bootcamp）。

每个新人都会经历新兵训练营，一般的周期是一个半月到两个半月。在这里，新人们会接受公司文化、工作流程方面的集中培训，帮助他们认识其他人，尽快融入公司。

如果你是开放进组的产品经理，那在接受培训的同时，还要每天约有招聘产品经理需求的部门领导沟通，达成双向选择。

这个阶段有时会持续到三个月，公司希望你可以尽量多的了解公司情况，选择适合自己的职位，而不是急着选择部门。

所以，面试时，如果你选择的是开放进组的职位（大部分产品经理职位都是开放进组）， 面试流程和内容都是一样的，不会因为你具体的经验而改变面试考察的内容。因为我们的面试考察得更多的是思考能力，而不是听面试者讲精心准备好的故事。

很多硅谷公司，比如 Google 都采用这样的方式。原因是这些公司有非常多的机会， 产品经理进入公司后换部门非常正常， 而产品的发展需要的是综合能力，所以它们希望招聘的产品经理具备优秀的思考和策略、分析和执行能力，能够胜任不同的产品部门，而不只是因为某个部门的老板觉得他特别合适。

当然，除了开放进组，也有少部分的产品经理选择特定的职位， 但这种情况并不多见， 一般是产品部门的高管或者是需要特定的专业经验的职位（比如，音乐产品的产品经理需要了解音乐版权的运作模式等）。

这样特定的产品经理会有专门的面试通道，但也会有其他部门的面试官考察这些人的综合能力。

在最后一轮面试后，对每一个的候选人，我们都会有一个所有面试官坐在一起讨论的流程，以保证不会因为某个人特别喜欢他就草率地录用了他。

比如，之前我见过有些候选人，以前和某个高管关系密切，是这个高管最信任的人，高管想把他招进自己的部门。但是面试后，这个人的能力没有得到足够多的面试官的认可，所以不能被录取。

你可能会说这样的方式不适用于小公司，但这篇文章的目的是抛砖引玉，即让你在面试产品经理时，知道各大公司在考察什么，从而有针对性的提高自己。

同时，如果你正在思考怎么才能招到优秀的产品经理人才，也希望给你一个如何组织面试、需要着重考察哪些能力的参考。

总结

今天我主要跟你分享了，顶尖公司产品经理面试的模式、主要流程，以及要考察的能力，面试的形式主要包括产品体验设计、产品分析执行、领袖气质以及团队管理。

希望你能记住以下三点：

第一，顶尖的科技公司的产品经理面试考察的是综合能力， 会花更多的时间问一些产品经理无法准备的问题， 看他们如何思考，而不是听他们讲精心准备过的故事和以前的经验。

第二，产品经理面试结果一般由一组面试官共同决定，而不是由某个高管的个人喜好决定。

第三，大部分产品经理都是开放进组，所以我们考察的是综合能力，他们进入到公司之后通过新兵训练营选择合适的团队和职位。

思考题

你所在公司的面试流程是什么样的，考察的是哪些方面的能力？

欢迎你给我留言。

33 | 如何提升产品感（product sense）？

产品感（product sense），是一个有点儿抽象的概念，其实说白了就是，产品经理能把用户的需求转化成用户喜欢、用得顺手的产品体验， 主要包含了以下四个方面：

能否将模糊抽象的想法转化成实际可行的产品解决方案；

能够设计符合用户使用习惯、体验流畅的产品方案；

能够制定产品策略，明确产品的特点，知道下一个功能该做什么；

能够明确产品的重点以及成功标准。

一句话概括，产品感就是你是不是知道如何做产品决定，以及你的产品决定是不是有道理。

Instagram 最近刚刚发布的看视频平台 IGTV，采用了竖版全屏的方式，在我看来这就是产品感的体现。

视频产品呈现的方式有很多，现在视频 APP 的内容虽然好，但大多是横版，不够沉浸化。而 IGTV 意识到了用户年轻化、爱时尚的特点，所以它所有的视频都是竖版、全屏的。即使是长达一小时的小电影也是竖版全屏，这也是第一个做到长视频是竖版的 APP。

这种竖版全屏的模式，对 Instagram 擅长的时尚和旅游之类的内容特别合适，体验非常浸入式，因此这个产品也吸引了大量用户。

能够在其他产品的长视频都是横版的情况下，IGTV 的产品经理认识到这样的体验对于现有用户并不是最优的，并制定出了浸入式又便捷的解决方案，这就是好的产品感的范例。

如何提升你的产品感？

那么，如何提升产品感呢，也就是如何提升你做产品决定的能力呢？我曾经尝试过很多方法，在这里我给你分享四种最有效的方法，希望可以帮你提升产品感，或许还可以为你激发出更多提升产品感的方法。

第一，对比和研究同类产品，从同类产品中寻找灵感。

对于视频产品来说，你可以对比和研究抖音、快手、微视、YouTube 等等。

首先，对比它们的目标用户群体、 产品功能等比较直观的内容；然后，对比用户体验，这也是最关键的。

你可以在这几个视频网站上传同一个视频，对比发布视频之后的体验：

哪个视频在短时间内观看的数量更多？

其他用户给你反馈的方式是什么（评论还是表情包），用户喜欢发什么样的评论（B 站和抖音的评论方式就很不一样）？

它们多久会给你发一次提醒消息，给你发的提醒消息是否有用？

为什么打开抖音最先看到的是最火的内容，而打开 Instagram 最先看到的是朋友或者关注的明星的内容，这样设计的目的是什么？

研究同类产品如何解决同一个用户问题，这个方式对我来讲是最有用的，看完了已经有的功能，我就会思考还没有的功能。比如，如果要加一个视频剪辑的功能，我是抖音的产品经理会怎么做，我是 Instagram 的产品经理又会怎么做。

第二，给每一个你喜欢的产品挑刺。

这是我经常锻炼自己的一个方式，因为越是你喜欢的产品，用户体验越好，可以挑错的空间也就越小，所以给最喜欢的产品挑错，你需要大量的思考、谨慎的观察产品体验的一丝一毫，这个过程可以有效提升你的产品感。

如果现在让你给微信、抖音、Instagram 挑错，你会挑出哪些问题呢？

第三，思考产品成功指标的制定过程。

了解其他产品的成功指标是什么，以及如何指导产品的功能开发。 你可以看一些访谈以及科技新闻，看看成功产品的负责人如何评价他们的产品，如何描述成功指标。
Facebook 每个季度的报表，会讲用户使用数量是多少，平均每个用户使用产品的时间；而 YouTube 的每次报告，会讲视频观看总时长是多少。
然后，你就会理解为什么 Facebook 会在用户的信息流上放很多视频，因为这样可以提升每个用户使用产品的时间；你也会理解为什么 YouTube 会不断推荐长视频让你看，因为这样可以提升观看总时长。

思考其他产品为什么会制定这样的指标。 Facebook、YouTube 的盈利模式都是在内容中插广告。而且它们插广告都有一定的逻辑，比如你看了多长时间后才插广告，所以你使用产品的时间越长，他们能插的广告就越多。
那现在我们如果把 Facebook 和 YouTube 的盈利模式，改成了订阅制，就像 Netflix 一样， 那么成功指标应该是什么？根据这个新的成功指标又应该有哪些新的产品功能呢？
我在专栏前面的文章中，给你留下了很多思考其他产品的题目，也是因为这样的假想思考题对锻炼产品成功指标的决定能力非常有帮助。

第四，从非互联网产品中寻找灵感。

所有的产品都是相通的，讲究的都是如何解决用户问题。

我先跟你说说时尚产品能教我们什么道理。如果你在购物时多看一眼布告牌广告，你就会发现时尚产品的功能定位和市场营销方式很不一样，这样的区别来自哪里呢？

同样是奢侈品牌，LV、Chanel 和 Burberry 的大片对于女性的描述方式很不一样， 每次时装秀，你都可以听到设计师讲自己的“缪斯”来自哪里，是纽约上东区的富太太还是独立自主、白手起家的女企业家，是饰演功夫电影闻名的女性还是拍文艺电影的小清新，这和我们的目标用户群体是相通的。

再看看从金融行业，我们能学到什么。很多银行产品也提供了非常有意思的产品功能策略，它们对用户的分层非常明显， 金卡、银卡、白金卡，每种卡的对应福利也不一样。

为什么某某银行的白金卡提供的福利是五星级酒店的酒廊，有的卡提供的却是免费汽车护理和加油，这源于目标群体用户的生活方式不一样，信用卡公司要符合用户的生活习惯。

不同的银行对于金卡、银卡、白金卡有明确而具体的分层，每个层级都有对应的策略，这就和我们把用户分成“金主爸爸”（买的多）、付费用户、活跃用户、普通用户、偶尔上一次、下载完了就不玩了等类别，而且采用不同的推送方式一样。

不能把互联网产品看成一个孤立的门类， 你完全可以通过对其他类别产品的观察以及研究来提升对科技产品的创新能力和产品感。所以，一定要多看多听多思考，跳出互联网产品的小圈子去看外面的大世界，这是产品经理的素养，也是提升产品感的好方法。

总结

产品感，说白了就是产品经理能够作出好的产品决定的能力，这样的能力需要立足于对用户的了解、 对用户痛点的捕捉、把抽象概念转化成具体的产品功能和计划的能力，以及对产品成功指标的把握。

我还跟你分享了四个锻炼产品感的方法：第一，同时对比和研究同类产品；第二，给每一个你喜欢的产品挑刺；第三，思考产品成功指标的制定过程；第四，从非互联网产品中找灵感。

其实，提升产品感是一个非常有趣的过程，重点在于观察生活、思考生活，这样我们才能更好地服务于用户的生活。

思考题

你平时还会通过哪些方式锻炼产品感？

欢迎你给我留言。

34 | 如何提升产品经理的综合素质？

产品经理的工作内容多种多样，接触的人也是风格各异，产品发布更是情况不断，所以你不仅需要具备过硬的产品增长能力、领导能力、管理能力等，更需要勇气和灵活应变的能力来应对各种变化和压力，也就是还要具备各种软实力。

我在前面的内容中，跟你分享了如何提升产品经理应该具备的硬技能，那么今天我就跟你聊聊怎么增强软实力？

讲故事的能力

讲故事的能力，看似很虚、只是动动嘴皮子，但却是一个非常重要的能力，因为不论是营销经理还是设计师还是最最学术路线的工程师，他们都喜欢听故事。

你需要注意的是， 我在这里说的“讲故事”，并不是指吹牛，而是要给团队讲清楚我们到底做的是什么事情，为什么这件事情值得我们做、值得我们这么做。

如果你看过 Facebook 的首席产品官克里斯 · 考克斯（Chris Cox）的演讲， 你一定会被他讲故事的能力震撼。每一个新员工进入公司，在新兵训练营的第一天，克里斯都会给大家讲 Facebook 的愿景以及产品蓝图，每次讲完，你都可以明显看到新员工两眼放光，对工作充满了激情和斗志。

那么，怎么才能提升讲故事的能力呢？

第一，你可以用一些具体的人物细节，很多的名人演讲中也都会用到。

奥巴马在 2008 年的竞选演讲中，他回顾历史，讲述黑人平权运动和女性投票权如何一步步地取得进展时，并没有单纯地用史实讲授，而用了一个 106 岁黑人妇女安妮 · 库波尔（Ann Nixon Cooper）的亲身经历，侧面揭示美国在民主和和平上的进展。

作为观众，我们都不由自主地被安妮个人经历的跌宕起伏吸引，演讲结束之后，我们意犹未尽，对美国近百年来取得的成绩充满自豪，情不自禁地展望奥巴马做总统后的美国又会是什么样。如果你感兴趣，强烈建议你去看看原文。

第二，你可以借鉴虚拟文学的写作方式，甚至是一些戏剧文学书的写作方式，它们的开端、铺垫、高潮、结局的写作技巧同样适用于讲清述产品故事。

你可以在开端部分说出用户的痛点，铺垫部分说说为什么这样的痛点一直没有解决，高潮部分说说我们想要达成的目的和解决方式，结局部分收收尾，让大家充满期待。

和他人建立信任的能力

产品经理要和各种各样的人打交道，比如我现在的产品日常就要接触一二百个人，每个人都有不同的风格和性格特点，这就意味着我需要培养和各种人快速建立信任的能力。

之前我看过一个心理学家的研究，说领袖吸引他人的两个特点：一是有能力，二是慷慨。 所以，产品经理除了要具备超群的产品能力外，更不能自私、唯我独尊，而是应该大度、慷慨，愿意多花时间帮助别人，给他人带来福利。

这说起来容易，但并不简单。如果你的工程师在这个项目上花的时间最多，当有机会给大老板展示时，大家自然而然想到的是你这个产品经理，那这个出风头的机会你会让给工程师么？

另外，我们日常的工作中难免会有摩擦，比如你因为否掉了某个人提出的主意，而影响了你俩的信任关系。

所以，这里建立信任的能力不仅仅是第一印象建立良好的关系，还包括快速修复关系的能力，遇到摩擦之后，如何坦诚解决，重塑信任，这一点很重要。

那如何重塑信任关系呢？

Facebook 的首席运营官谢乐尔 · 桑德伯格（Sheryl Sandberg）是这么说的：
- 一是，敢于直接面对不舒服的对话（Difficult Conversation），包括对别人的工作方式提出批评、建议，直面和同事的隔阂等等，直击问题要点，让对话透明化；
- 二是，主动问别人对你有没有什么意见，用这样的方式让对方更舒服地说出问题，从而解决问题。

在 Facebook，在成为产品主管之前，所有人都要接受公司的内部培训，专门教你如何进行不舒服的对话。

在我看来，和他人建立信任的能力，是领袖气质最重要的体现。

《哈佛商业评论》经常会报道领袖能力的最新研究，很多时候都是说如何与他人建立信任关系，如何激励你的团队成员。

它的英文版有一个每日贴士（Tip Of The Day）板块，你可以直接订阅到你的邮箱，每天都可以收到一条帮你提升领导力的建议。我每天都在看这个内容，收获颇丰，也强烈推荐给你。

另外一个很好用的锻炼方式是，在社交活动上和陌生人聊天。你可以专门找一些乍一看不是很热情、很好说话的人，看你能不能在很短的时间内就和他建立信任关系。

或者在工作中，遇到了不顺心的人，不要想办法逃避，不妨锻炼一下自己，看看你能不能在未来的一个星期内和他修复关系。

创造能力

对我来说，跨学科的碰撞是最能提升创造能力的，每当接触新鲜事物或者其他学科时，都是我“脑洞大开”，创造力爆棚的时候。

虽然工作繁忙，但我还是建议你要花时间去尝试自己不熟悉的东西，其实这也是在为工作做功课。

周末时，我会去尝试不一样的东西。比如，学个新爱好，读一本从来没接触过的领域的书，在 Coursera 或者知识网红平台上学一门与计算机、产品无关的课。

我曾经在 edX 上过一节哈佛大学的米其林料理课，课程中讲了很多厨师摆盘、设计菜品的想法，后来在设计产品时我经常会想到这些，给了我不少的设计灵感。

活到老学到老的道理，你我都明白。但在这里，我想强调的是，对产品经理来说，接触新鲜事物不能只是玩玩，而必须认真对待。

科技产品迭代太快，很多的想法和功能马上就过时了，唯有不断地吸纳新的想法，你和你的产品才能立于不败之地。因此，尝试新鲜事物也是我们必须要花时间做的事情。

另外，你可以多做一些能够体现创造力的工作，创造力好比健身，不练也会退化。

斐济 · 西默（Fidji Simo）是 Facebook 最年轻的副总裁之一，2012 年开始做产品经理，之后一年至少升一级，30 出头就成了 Facebook 的副总裁。她对我们说，她的新年计划就是每周做一件有创造力的事情，比如画画、写文章等等。

我觉得这个主意非常不错，我有时候工作忙起来就会全心全意忙工作，满脑子想的都是公司具体产品的事情，其实真的需要跳出来，锻炼创造能力，否则就只是在消耗，没有积累和锻炼新的能力，那终有一天会黔驴技穷。

总结

这篇文章，我主要跟你分享了如何提升产品经理的三大软实力：讲故事的能力，和他人建立和修复信任的能力，以及创造能力。

这三个能力都是需要积累的软实力，故事讲得好，才能把产品的愿景沟通清楚，激励团队成员；和最难搞的人或者和你最不一样的人建立信任，团队才能高效工作，毕竟产品经理大多管不了招人，所以要学会和各种人合作；遇到摩擦时重塑信任，要透明、敢于直面不舒服的对话。

最后，要专门花时间学习新知识、了解新领域、经常做有创造力的事情。

思考题

你还看过哪些对产品经理工作有帮助的书？

在留言中分享吧！

35 | 非计算机专业也能做产品经理？

硅谷的很多公司，几年前都要求产品经理必须要有计算机背景，谷歌甚至要求所有产品经理都要通过编程面试。

近几年来，以 Facebook 为首的一些公司，开始允许各种背景的候选者来面试产品经理的职位。而最近硅谷如火如荼的一系列女性平权运动，让越来越多的人意识到产品经理需要有多元化的背景，这样才能了解百万甚至千万用户的需求，而不只是做一堆中看不中用的“黑科技”。

但是，没有计算机专业背景，我怎么才能做好产品经理呢？工程师会不会瞧不起我？我会不会不知道如何设计科技产品？我以前是做运营的，到底怎么转型做产品经理呢？

现在我经常被人问到这样的问题，那么今天我就来跟你聊聊，没有计算机专业背景怎么做产品经理。

在我看来，一个理想的产品经理，确实需要具备一定的计算机知识，但是不一定要有计算机专业的学位。 我自己是计算机和经济双专业背景，做了产品经理这么多年，我也曾认真思考过我的计算机知识究竟用在了哪里，毕竟工作中我从来不写代码。

结合我的工作经验和思考，我要跟你聊聊，我的计算机学位从哪些方面给与了我帮助，如果你没有计算机学位，又可以如何弥补。

说到计算机学位对我的帮助，主要体现在给工程师的第一印象，判断项目复杂程度的能力，了解技术是否可实现、有哪些限制这三大方面，所以针对没有计算机专业背景如何弥补，我也会从这三个方面给你建议。

给工程师的第一印象

计算机专业学位最明显的优势就是，工程师对我的第一印象会比较好。他们会默认我不好蒙骗，也知道我会理解他们的辛苦和难处，毕竟我自己也曾调试代码到半夜。

但这也仅限于第一印象，之后我的想法是不是靠谱，大家是不是信任我，就和计算机学位越来越没有关系了。

那没有计算机学位，你应该给工程留下好的第一印象呢？他们可能会欺负你不懂专业好蒙骗，或者担心你的建议不靠谱，但是没关系。

你只要在一开始保持好奇心，多问工程师问题，同时展示你自己的能力，那完全可以弥补你没有专业学位的短板。在我看来，你没有必要过度纠结专业学位对你第一印象的影响。

判断项目复杂程度的能力

首先，有计算机背景，我可以更容易理解一个项目的复杂程度。比如，如果这个项目牵扯到更改之前的数据结构，那么即使看上去只是加一个按钮，我也能知道工程难度可能会非常大。

另外，我可以更容易理解一个项目应该如何拆分，前端怎么拆分，后端怎么拆分；如果时间紧任务重，需要多派人，我也可以明白把人放到哪个部分可以加快速度。这将有利于我制定产品优先级，路线图，以及权衡取舍。

那如果没有计算机背景，你应该怎么弥补呢？

其实，对项目复杂度的理解和项目的拆分，更多的是来自我以前做编程项目的经验，而不是书本或者说学位。 我在学计算机专业时，大部分时间都花在了做老师布置的编程作业上，写代码、调试代码、优化代码，但是参加工作后，这些具体的内容我再也没碰过。

所以，我觉得没有计算机学位，你也不会损失多少。我的建议是，你可以在新项目开始时多了解以下五个部分的内容，可以帮助你判断项目复杂程度，避免“产品经理瞎设计，技术上根本做不出来”的窘境。

项目的工程结构图是什么样的？最简单的，这个项目需要前端 UI 吗，需要后端吗？是移动还是网页？是一个新添加的功能还是修改已经有的产品流程？需不需要推荐系统，排序（ranking）？利用的是已经存在的用户数据，还是需要输入新的用户数据？

这个项目的所有用户体验都由我们自己的团队控制，还是需要利用其他组负责的部分？依赖的其他组的功能部分是已经做好了，还是正在开发阶段？如果我们修改了当前的用户体验，会不会影响已有的功能，需不需要修改以前功能的代码？

这个项目一步步的用户流程图是什么样的？每一步需要提取什么样的用户数据？每一步和每一步之间有延时吗？

这个项目最复杂的部分是什么？最耗时间的部分又是什么？哪些部分可以平行开发（也就是两个工程师可以同时开始，各做各的），哪些部分是要先完成后其他工程师才能开始做（这样你多派了工程师也不会提高生产效率）。

这个项目的产品质量（包括会不会需要花很长时间计算才能进行到下一步，会不会在网络条件不够理想的情况下无法操作）会不会受影响？对所有的手机型号都适用吗？

当你明白了这五个问题，你也就对整个项目的工程难度有了一个清晰的认识，对项目存在的风险也会了然于胸。

比如，这个项目的一部分体验由另一个团队负责，但是这个项目对于另一个团队来说并没有那么重要，所以作为你产品经理，就应该提前和其他团队的产品经理沟通，或者预留更长的开发时间。

其实上面这些问题，是每个好的技术骨干都应该清楚的，这便于他们预估工期。在这里，我让你自己先弄明白这些问题，并不是要让你取代他们的工作，而是因为当你明白了这些问题后，你和工程师团队的沟通会顺畅很多。

了解技术是否可实现，有什么限制

计算机专业出身，我可以更了解某项技术到底能不能实现我的这个功能。

比如，你可以利用人工智能技术设计一个模型，来自动捕捉成人内容，原理就是利用图像进行判断，所以你很容易就可以训练出这样的模型。

但是，如果你要用这个模型来捕捉政治内容，那单靠这个模型可能就不够用了。这时，我就需要设计一个产品工作流，能够把模型不那么确定的内容经由人工审核，确保准确度。

接下来，我就跟你分享一下，如果没有计算机专业背景，你需要怎么了解某项技术是否可实现，来弥补自己的短板呢？

其实，了解某项技术能做实现什么功能并不需要计算机专业，你只需要多问几个为什么就可以了。

下面我就以最具代表性的人工智能项目和移动端项目为例，给你分析一下怎么化解自己因为缺乏计算机背景而带来的问题。

对于人工智能项目来说，你明确了以下两点，问题也就迎刃而解了。

你需要明确这个项目需要捕捉的内容是宁缺毋滥还是一个都不能少？
宁缺毋滥是指，我们希望这个人工智能模型捕捉的内容都是符合设定条件的，宁可少捕捉几个，也不要捕捉不满足要求的内容。就像警察抓小偷，需要证据，没有证据即使这个人鬼鬼祟祟，警察也不能随便逮捕，冤枉好人。
一个都不能少是指，我们不想错过任何一个满足条件的内容，即使你不确定这条内容是否满足所有条件，也不希望它成为漏网之鱼。如果你要找到哪些视频的质量差，不适合广告商插广告，那么即使你不确定这条视频广告商是否喜欢，你都会选择不在这条视频中插播广告，因为你怕广告效果不好，广告商取消和你的合作。
所以，宁缺毋滥还是一个都不能少，其实是一个产品决定，需要产品经理和工程师弄清楚再行动。

我们的数据有多少？多少数据才能训练出准确的模型？数据来源又是什么？

对移动端的项目来说，你照样弄明白下面两点，你就可以预估出某项技术能否实现了。

信息图像处理是在移动设备上进行，还是先把内容发到服务器上，之后再处理？

UI 必须是 native 的吗（也就是说，使用 Objective-C 或者 Java 等语言），还是我们可以在网页端写代码，然后在移动端显示网页就行了，后者将会大幅降低工程难度。

总结

今天的这篇文章，是希望为非计算机背景的产品经理说清楚有计算机背景和没有背景之间到底有什么不同，换句话说，如果你想要弥补计算机背景的短板，应该如何进行。我从以下三个方面给你提供了建议，希望对你有所帮助。

如果工程师因为你没有计算机背景而对你的第一印象不好，那没什么大不了的。你只要多问问题，直接体现你的能力，你良好的表现很快就可以取代不好的第一印象。

如果你没有计算机背景，需要在每一个项目开始的时候了解项目的复杂程度。我提到的五类问题，可以帮你以最快的速度了解如何权衡取舍，产品开发的风险难度。我建议你收藏这篇文章，等到下个项目开始时再回过头来看看。

关于了解技术是否可实现，有什么限制。我针对目前比较火的、也是比较有代表性的人工智能项目和移动端项目，给出你建议：针对人工智能项目，先弄清楚宁缺毋滥还是一个都不能少；针对移动端项目，先弄清楚移动端和服务器端是什么关系。

思考题

如果你有计算机背景，还有哪些方面的计算机知识能够帮助你的工作？

如果你没有计算机背景， 还有哪些方面你感到吃力？

欢迎你给我留言。

36 | 模拟一场硅谷的产品经理面试

作为专栏的最后一篇文章，我会为你模拟一场产品经理面试，增强你的面试能力，助你取得理想的 offer。

在今天的分享中，我以产品感和分析能力的考察为例，边和你分享面试者和面试官的对话，边为你解释每部分要测试的能力。

对话 1

面试官： 如果现在要设计一款帮助大家找房子的产品，你会怎么设计？
面试者： 嗯，让我想一下。能否给我几分钟捋清思路？
面试官： 没问题。

这里你需要注意的问题是，不要害怕和面试官多要时间，也不要怕面试的时候你需要现场思考，因为经过思考说出的内容比试图脱口而出的要好得多。

对话 2

面试者： 我想先问几个问题明确一下我们设计的目的，以及针对的用户。
面试官： 嗯，你说。

面试者： 你说找房子，是什么概念，是买房子还是租房子？
面试官： 你是产品经理，你觉得呢？

这里需要注意的问题是，这个面试者的问题很好、很关键，但面试官提出这样模糊的问题也是有目的的，他就是要考验面试者的思考能力。

对话 3

面试者： 首先，买房子这个部分我们已经有很多产品了，比如 Zillow、Redfin 等。其次，我们公司的优势是用户数据多，用户的活跃程度高，而买房子的交易频率太低了，我觉得不能充分发挥我们公司的优势。另外，现在房屋出租的产品比较少，而且租房要综合考虑房源和室友，室友的选择需要更多的是人与人的接触，而这恰恰是我们公司最擅长的。所以，我觉得还是租房子的产品比较适合我们。

对话进行到这里，你就可以发现这个面试者的逻辑能力很强，面试官的眼睛已经亮起来了。

对话 4

面试官： 好的，那我们就来做租房子的产品。你接下来会怎么设计呢？
面试者： 我会先考虑用户的痛点有哪些。租房子的一般都是年轻人，他们还没有结婚，所以会考虑有几个室友，房源在什么位置，周围有哪些配套设施，交通是不是方便这些问题。所以，我们这款租房产品要解决的痛点是，能够搜索并筛选目标地域，查看具体的房源信息，包括房源图片以及房东和室友信息，还要添加配套设施、房源评价等功能。

面试官： 等等，你房源的信息是怎么来的？
面试者： 房源信息是用户提供的呀。

面试官： 也就是说这是一个包含房主和访客两方的平台，他们都要在我们的平台上发信息。现在已经有其他的平台上有房东和房源的信息了，我们为什么不直接拿来用呢？

面试者： 你说的有道理。但是，我的顾虑是，如果我们直接把其他平台的信息通过爬虫技术拿过来，那我们就只能通过邮件或者电话的形式实现房客和房东的联络了。但是，我们公司有自己的发消息产品，而房东和房客的联络应该是我们掌控的，以后我们可以根据这些信息做进一步的功能。

面试官： 好吧，但是这要求我们从头开始，冷启动时，我们要怎么解决没有足够的房客和房东的问题？
面试者： 我觉得，我们可以让运营团队先把房东信息带过来。其实，我们可以专门找一个人，通过其他平台的房东信息联系上房东，让他们也来注册我们平台的一个账号。他们只要输入最基本的电话或者邮箱就可以了，剩下的信息我们可以帮他们填充，减少他们的工作量，吸引他们完成注册。另外，我们应该一个城市一个城市地发布，而不要一开始就覆盖所有城市。

这里需要注意的是，面试者如果能事先想到其实有两种方式，一种是从头搭建平台，一个是先和其他平台合作或者爬取他们的信息，然后再分析哪个方式更有道理，这样能更好地体现他的思考能力。

对话 5

面试官： 有道理， 你继续吧。
面试者： 我们刚才讲到了痛点，我觉得要是划分优先级的话，我会把搜索并筛选目标地域，查看房源信息，包括房源图片以及房东和室友信息作为最小化可行产品。之所以要加上房东和室友信息，是因为这些信息别的平台没有，我希望我们产品第一天发布就能给用户眼前一亮的感觉。

面试官： 我们通过公司其他产品提取了大量用户数据，怎么利用好这些资源？
面试者： 我觉得，我们可以在房东和房源信息这个板块下功夫，比如我们了解用户的喜好，所在地、学校信息，我们可以推荐同校的房客住在一起，我们也可以让房客找到房子后对房东以及房源进行实名评价。这些就是我们数据资源的独特优势。

面试官： 好了，时间不多了，有一点你还没告诉我，我们产品的成功指标是什么？
面试者： 我觉得，应该是多少房客给房东发了消息询问房源信息。

面试官： 为什么不是最后签合同的数量呢？
面试者： 我们平台最大的作用应该是高效帮助用户筛选靠谱的房源，让他们从几百个房源中筛选出五个，而不是从五个中选出一个。五选一，完全可以通过电话聊天来完成，那我们所做产品并没有本质性的变革，但是从几百个中选五个就不一样了，这个过程最繁琐，用户最不喜欢，而且难度最高，我们能把这个做好就很了不起了。

面试官： 好的，谢谢你参加本次面试。

这里需要注意的是，产品的成功标准最好能在设计产品功能之前先说。但是他的回答，还是非常有道理，也反映出了他很强的思考能力。

对话 6

面试官和应聘者聊完以后，就要给老板汇报了。

面试官： 我觉得这个人我们应该录用。
首先，他有很强的逻辑分析能力，能够精准确定用户群体，问的问题也能反映出他有很好的洞察能力。
其次，他能够很好地权衡取舍，不仅能够选出最小化可行产品的功能，也能清晰地说出这些功能必须做的原因。比如，他说：“我之所以要加上房东和室友信息，是因为这些信息别的平台没有，我希望我们产品第一天发布就能给用户眼前一亮的感觉”。
最后，他对成功指标的定位很准确，能够清醒认识到我们的价值不在于选择最后一个，而是筛选出最合适的五个，目标明确，我们应该录取。

招聘老板： 好的，听你的。让 HR 跟进发 offer 吧。

总结

我给你还原了一场硅谷面试的真实过程，希望你可以认识到以下几点：

你要多问问题。比如，这个面试者一上来就问清楚到底是买房子还是租房子的产品。问问题的能力，是产品经理最重要的能力之一，一定不要想当然， 而是要问得越清楚越好。

不要只说我选 A，而是要先说出有 A、B、C 三个选项，为什么我觉得 A 最靠谱。这样才能体现你的思考全面性，让面试官知道你不是拍脑袋做出的决定。

明确表达什么部分优先做，什么部分可以等，什么部分是我们产品的核心竞争力，我们应该如何和其他产品区分，这是产品经理想要取得成功的最关键能力。

思考题

如果你是面试者，针对上面面试者的回答，你觉得可以在哪些方面做得更好？

欢迎你给我留言。

新书首发 | 《硅谷产品：36讲直通世界级产品经理》

你好，我是曲晓音。在专栏更新完最后一篇文章的三个月时间后，我要再和你分享一个好消息。今天，我的新书在极客商城上架了，书名叫《硅谷产品：36 讲直通世界级产品经理》。

很多老朋友可能会问我，出了专栏为什么还要出书？

其实，从 2018 年春节“极客时间”的编辑找到我，到 7 月 14 号专栏内容全部更新结束，这半年多的时间里，我在专栏写作、回复你的留言，以及寻思你可能遇到的产品相关问题的过程中，也在不断梳理、迭代自己这些年在硅谷做产品经理的所思、所感、所悟。当然了，我非常希望能把这些内容固化下来，不仅仅是作为你闲时的消遣，而是能真正帮你解决在产品路上遇到的各种问题。

同时，这半年来，和专栏编辑、图书编辑磨稿的过程中，我最深的感触是，专栏和图书是不一样的。专栏是文字 + 音频的形式，更适合通勤路上等更碎片化、更适合“听”的场景；而纸质图书，更适合你慢慢琢磨其中的内容。因此，这也就决定了专栏和图书在内容交付上是不一样的，也因此有了今天这本书的问世。

在图书出版的过程中，我和编辑又根据纸质图书的特点，在专栏文章的基础上进行了些调整，比如我又优化了一部分文章的结构脉络，旨在帮助你通过图书 + 专栏的形式，充实自己的碎片化时间，梳理出更高效的学习路径，锤炼自己的产品思维。

说到底，这些优化，很多是源自于你在专栏文章下的高质量留言。可以说，是你的赞赏、批评等各种支持，帮助我一起创作了这本书。

所以，如果你想系统、全面地了解产品经理这个行业，也想看看硅谷的产品经理从 0 到 1 打造一个千万用户级产品的过程，那么这本书将是一个不错的选择。正如《人人都是产品经理》的作者苏杰为这本书写的推荐语：

国内写产品经理的书有很多，我们引进的硅谷相关图书也不可谓少，但本书是一个在 Facebook 等硅谷科技公司工作过的中国人，用她的双重视角写出的。内容方面，既走在行业前沿，又可落地操作，相信对各位同行会有很大帮助。

最后，能出版这样一本书，我感到很荣幸，也非常珍惜能把我这些年的思考和体验提炼成文字的机会，通过这种方式和你聊聊天。同时，我也很感激这几个月以来有你的陪伴。如果你在阅读这本书的过程中，有任何的问题、困惑，都可以在专栏对应文章下，给我留言，我将时不时地回来看看，和你分享我最新的想法。

《硅谷产品》这本书已经在极客商城提前开售，作为已经订阅专栏的老朋友，除了首发优惠之外，我还给你申请了优惠码。在极客商城待付款订单中点击“使用优惠”，输入优惠码“chanpin”，结算时可再减 5 元。

最后，希望你也能找到属于自己的“灯塔”，亲手设计出那款世界级的产品。

尾声 | 每个世界级的产品都有其使命

去年 6 月份的时候，Facebook 召开了一个全体员工的大会，向我们宣布了一件大事：CEO 马克 · 扎克伯格（Mark Zuckerberg）调整了 Facebook 的使命宣言。

在此之前的十几年里，我们全体员工每周都会重复这样一句话：赋予人分享的权力，让世界更开放互联（to give people the power to share and make the world more open and connected），也就是我们的使命宣言。

每个季度，我们看着公司的数字指标呈指数型增长，哗哗哗，上亿了，上 10 亿了，到 20 亿了，整个科技界，从来没有一个产品能够有这么多的用户。

为了实现这个使命， 我们从 CEO 扎克伯格所在的哈佛校园开始，到开放给所有人，从美国到印度到日本再到全世界，最后 Facebook 的增长速度甚至超越了互联网在世界的覆盖速度。所以，我们在非洲铺设了高速网络，先给用户提供免费的网络，再让他们用 Facebook，希冀于让互联网成为一项基本人权。

Facebook 月活突破 20 亿时，CEO 扎克伯格对我们说，仅仅让人与人之间建立联系还不够，我们需要“赋予人创建社群的权力，让世界融合在一起” （Give people the power to build community and bring the world closer together）。

为此，我们改变了每个部门的业绩目标，不再简单以增长人数为目的，而更在乎人与人之间连接的紧密程度，如果我们只是让你和你的朋友互相加了好友，但是你们彼此之间互相不了解，那么我们也不能算是成功。

修改使命宣言，对于现阶段的 Facebook 来说是一件大胆且伟大的事情。

大胆在于，要翻过以前的荣耀篇章，按照一个新的目标从头开始。

伟大在于，当年看似遥不可及的把全世界连接在一起的使命，我们居然做到了，月活达到了 20 亿，以至于旧的使命已经不再能够承载我们的野心，我们需要更高的目标。这就好比说，你少年时有一个很大很远的梦想，现在你居然梦想成真了，而这时这个梦却不够大了，你要有更高远的梦想。

做了产品经理这么多年，我最大的感触就是要敢做梦，说白了就是产品要有使命感。在 Facebook，我见过世界上最聪明的工程师、最有创意的设计师、最有经验的律师，但是我发现，这些最最优秀的天才， 都渴望有一个使命，告诉他们做的工作有价值，他们才会有奔头儿。

这些天才们理解了产品的使命，你甚至不需要催他们，他们都会像打了鸡血一样，用最厉害的才能和头脑，像干练的水手那样以最快的速度驶向灯塔。

但很多时候，他们并不知道要达到什么目标。也就是说，虽然他们每天都在工作，但是并不清楚到底要去哪儿，于是就开始争吵，或者南辕北辙，或者抓不住重点，又或者机械性地消耗自己的才华。所以，作为产品经理明确整个团队的使命，是至关重要的。

作为产品经理，制定产品使命就像是指出了那个在左前方 30 度的灯塔，告诉水手们说：“你们看，那里就是目的地”。然后，水手们顿时铆足了劲，开始为达目的使出浑身解数。

有些产品经理，好像拿着鞭子催活儿的船长，对水手们说，你要加大马力、再加大马力，但是却并没有指出要往哪里去。大家叫苦不堪，拼命了好久，船却纹丝未动。

还有更多的产品经理，好像船长指向最近的那个浮标说：“快，往那走，先过去再说”；或者，看到旁边的船开向了一个浮标，就说：“快，快跟着走”。

这就像是，产品经理太在乎达到短期内一个临时制定的目标，而忽略了这个短期指标对产品长期使命宣言的作用，这也正是普通产品和世界级产品的最大区别。

产品有了使命，也就有了灵魂，然后每一步的运作和努力，都有了盼头和意义。扎克伯格更换 Facebook 使命宣言这件事，最让我佩服的是，他从不停止寻找新的灯塔，不断赋予产品新的盼头、野心和恒心。

读到这里，你已经知道了产品经理存在的意义就是，帮助产品团队找到灯塔，也就是找到产品使命，并带领团队去实现这个使命。 明白了这一点，那我在专栏里面跟你分享的内容是不是也更容易理解了。

作为产品经理，通过了解用户痛点来精炼总结产品要解决的问题的过程，就像是船长在寻找灯塔。

很多时候，船长会发现很多灯塔，他需要从中找出哪个才是目的地。对应到产品经理就是，需要明确用户群体确定产品方向，如果一时不能准确把控产品的方向，那也可以通过一定不能做的事情来逐个排除。

发布最小化可行产品，通过市场反应得出正确的产品方向，就像是船长与其等待勘测清楚灯塔的具体方向，不如先驶出几步，去探索灯塔在何方。

最小化可行产品发布后，根据用户反应，你可能需要调整产品策略，尝试一些不同的功能，多做一些 A/B 测试，以产品使命为标准，来判断每次的优化是不是距离产品使命更近了，这就需要你提前制定出衡量产品成功的标准。就像是，船驶出后，船长通过不断调整航线，来判断是否离灯塔更近了。

产品上线后，为了获得更多的用户，你就需要运用产品增长的技巧（比如，我在专栏中给你分享的增长黑客、硅谷高管的 UIE 增长论、减少用户阻力等等），但也要注意权衡取舍产品的增长代价。这就是像是，船长会通过调整船帆的方向等方式，加快前进速度。

这里你需要注意的重点问题是，进行产品增长的前提是，你已经证明了产品能够解决用户需求，否则一切努力都是徒劳。

在和团队成员，尤其是资深的设计师、工程师打交道的过程，就像是船长搞定大副、二副。针对不同风格的团队成员，你需要做的是，找到他们在意的点，激发他们的潜力和干劲儿，最大程度地发挥他们的才能，实现产品成功。

最后，我要告诉你的是，衡量一个产品经理是否成功的标准，非常简单，就是他负责的产品是否取得了成功。就像是，衡量一个船长的标准，不是他长得帅，也不是他领导派头十足，而是他引导船到达了灯塔。

一个老船长，经历过风浪、翻船，以及生死存亡一瞬间后，最难得的是，他绝不会满足于触手可及的浮标，而是不断寻找新的灯塔。

那么产品经理呢，就是要有使命感，而且要不断地赋予产品恒心、野心。所以，我也希望这个专栏，能让你在寻找并追逐灯塔的路途上，多一份笃定和自信。

最后，非常感谢极客时间这个平台，可以让我给你分享我的所学、所得、所思，也感谢一直关注并支持专栏的你，感谢你一路的鼓励与陪伴！