mod

极客时间专栏/硅谷产品实战36讲/产品经理基本功/13 | 如何撰写产品需求文档？.md

@@ -0,0 +1,96 @@
+<audio id="audio" title="13 | 如何撰写产品需求文档？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/29/dd/29a5933e25333fee62ae612206ce16dd.mp3"></audio>
+
+很多产品经理给人的印象就是每天开会，开完会就趴在桌子上写产品需求文档。上次和国内的几个产品经理交流时，有的产品经理告诉我说花好几个星期写的一份产品需求文档，工程师没看完就扔一边了；有的产品经理和我说， 他们的产品需求文档非常精确，每个小细节、每个逻辑都讲得清清楚楚， 流程图也画得非常清晰， 工程师照着这个文档一行一行地写代码就可以了。
+
+我在硅谷认识的很多产品经理，包括我自己，都不喜欢把大量的时间花在写产品需求文档上。我们认为，应该直接和工程师、设计师面对面地沟通，当面把东西讲清楚， 而不是写一摞文档，最后工程师、设计师根本没时间看，或者一看这么多内容随便瞟一眼就扔一边了。
+
+这样做的好处是，我们做决定的速度非常快，当面开完会，马上就开始干活，而不需要把每个细节都写得清清楚楚。
+
+这样做的缺点是，如果你的团队成员还不具备自己做一些小决定的能力，或者公司对于一些基本的UI部件没有固定的标准（在大公司，按钮、配色都有相应的设计准则），那么很有可能出现产品的功能和功能之间不协调的问题。尤其是当一个成员辞职后，整个产品组需要花很长时间来填补这个空缺。所以，我理解有些公司的产品经理会在产品需求文档里面，事无巨细地把所有细节都写得清清楚楚。
+
+所以，我们还是要写产品需求文档，只不过在产品需求文档中只写清楚最最重要的内容就可以了。可能你会说我这样的方式更适用于硅谷、适用于大型公司，并不符合我的现状。但这篇文章并不是要“教条式”的向你传达如何做产品经理、如何写产品需求文档，更重要的目的是带给你一个新的思考方式，把可以借鉴的方法应用到你的实际工作中，相信会起到事半功倍的效果。
+
+## 明确产品需求文档的目的
+
+撰写产品需求文档是为了和工程师、设计师、数据科学家等团队成员清晰的沟通产品蓝图， 讲清楚产品要解决的问题、 实现的场景、成功的标准等等， 并有据可查。所以，产品需求文档需要具备以下三种功能：
+和团队成员高效沟通，用他们能够看懂的方式清晰地表达你的想法，让他们清楚什么该做什么不该做；
+记录之前的问题是如何解决的；
+明确列出产品功能的短期目标、长期目标，绘制一个从短期到长期的产品蓝图。
+
+在我看来，产品需求文档并不需要面面俱到，写清楚所有的事情，重要的是写出团队成员真正感兴趣的、对他们有帮助的内容。
+
+## 产品需求文档需要包含哪些内容？
+
+我的产品需求文档一般会包含以下内容：
+
+第一，要解决什么问题。
+
+工程师、设计师等对产品解决的问题都有自己的理解，而且根本不在一个频道，这个情况在产品经理的工作中非常常见。
+
+比如，我要在直播上增加一个给主播唱歌打分的功能，工程师们认为是为了让主播提高唱歌水平，而设计师们却认为是让粉丝们在主播换歌的空当不会感到无聊，按照这个思路设计的产品必然不会成功。但实际上，问题是出在了产品经理身上，他没在产品需求文档中讲清楚到底我们要解决的问题是什么。
+
+所以，如果我是豆瓣读书的产品经理，要添加一个图书推荐的功能， 我会先讲清楚这个功能要解决的问题是什么，这也是我作为产品经理必须要跟大家说清楚的。比如说，用户现在已经可以通过豆瓣来浏览评价高的图书，也可以通过豆列找到自己感兴趣的书，我要新增加的图书推荐的功能是进一步解决用户渴望通过个性化的方式、找到自己感兴趣且评分比较高的书。
+
+在产品需求文档中明确了新的功能或者产品需要解决的问题是什么，可以让团队成员明确为什么要做这个产品。相信我，让大家对产品要解决的用户痛点保持一致，可以避免以后无数个日日夜夜里的争论不休。
+
+第二，论证这个痛点问题到底是不是存在（这个坑我踩过，大家一定要注意）。
+
+在很多工程师的眼中，产品经理只会吹牛、瞎扯，我也确实见过不少产品经理随随便便地就写出了用户痛点，而并没有验证过这些痛点到底存不存在，产品要解决的问题到底存不存在。
+
+比如，给主播唱歌打分功能的这个例子，到底粉丝们在主播换歌空档期有没有闷、闷到什么程度，或者到底主播有没有必要提升唱歌质量、粉丝们在不在乎主播的唱歌质量，我们应该先验证这些问题是不是真的存在，然后再去谈论具体怎么设计这个功能。
+
+所以，我上面说到的豆瓣读书的例子，如何验证用户是真的有寻找读书建议的需求呢？我们可以通过数据来验证，如果我们发现35%的豆瓣用户已经习惯通过豆瓣找书阅读，特别是通过豆瓣来探索刚刚推出的新书，那我上一步提出的问题就是真实存在的。
+
+第三，写清楚这个功能的成功指标和反指标是什么。
+
+这个功能的成功指标应该是，通过这个功能用户在豆瓣下载或者购买图书的次数。 
+
+如果使用豆瓣图书推荐这个功能的用户数量非常多、频率非常高，可以说明这个功能有人用；如果用户通过图书推荐的功能找到书后，通过豆瓣下载或者是购买图书的次数也增加了的话，那就说明这个功能对豆瓣有好处。 
+
+这个图书推荐功能的反指标，是指增加这个功能后用户使用其他豆瓣产品的频率。如果因为这个图书推荐的功能， 豆瓣的其他产品（豆瓣电影、电视剧等）的用户数量和使用频率降低了，那这个功能对于整个豆瓣产品来说到底是不是好功能就有待进一步研究了。如果一项新功能的成绩会挤占原有产品的成绩，这就叫做侵蚀效应，来源于生物界的自相残杀（cannibalization）这个词。
+
+第四，讲清楚要解决的用户场景。
+
+这个功能的使用场景可以包括;
+
+- 用户已经选择了一本书，我们自动推荐给他和这本书类似的其他图书。
+- 用户选择了自己感兴趣的主题，我们推荐书单。
+- 用户刚刚进入豆瓣读书页面，自动根据他之前读的书以及喜欢的作家推荐书单。
+
+从产品的角度来看，这三种场景的差别很大。
+
+<li>第一种情况下，用户已经给了我们非常明确的信息，表明了他此时此刻找书的意向。比如，用户说：“我刚看了《钢铁是怎么炼成的》，给我推荐一本相似的书”。<br>我们需要做的是根据已知的用户意向准确推荐，要着重推荐的准确和相关性，难点是怎么推荐和《钢铁是怎么炼成的》最相关的一本书。<br>这就像我们走进商场， 对售货员说：“我要买一条和这个笑脸包搭配的丝巾”，这时售货员就需要赶紧帮我找到很搭的丝巾，快、狠、准最要紧。
+</li>
+<li>第二种情况下，用户只给了我们一点点暗示，有点“犹抱琵琶半遮面”的意思，他说：“我喜欢科幻小说，给我推荐几本”，这时我们需要根据这些信息，进行推荐。但是，可以推荐的科幻小说有很多，用户此时此刻也没有具体想要哪一本书的想法，更多的时候只是在探索。<br>所以，我们的难点是：第一，给用户推荐各种各样的科幻小说，方便他们选择；第二，科幻小说有几万本，我们怎么决定推荐书单的排序；第三，如果给所有人都推荐《三体》这样的书单，难免有些单调，而且我们也不能确定用户会喜欢《三体》这个风格的图书，所以就需要注意科幻小说书单的多样性。<br>这种情况就很像我们走进商场，跟售货员说：‘’我要买一个包包”，然后售货员直接给你介绍了三款最新流行的网红包，他们也不知道你到底喜不喜欢这个风格。
+</li>
+<li>第三种情况下，我们并不了解用户使用图书推荐的目的，只能根据他以前的习惯进行推荐。 他以前喜欢过《哈利波特》、《百年孤独》，也喜欢过《从零到一》，涉猎广泛，那我们可以推荐的书就实在太多了，并且我们并不知道用户此时此刻想看什么。<br>用户刚进入豆瓣图书，可能只是想随便看看，或者找一本好书，或者找一个热销的书单，所以这时最重要的不是帮用户找到具体的某本书，而是要激发他们的兴趣，把他们引到更深层次的读书需求上，那就需要让他们多看看、多逛逛。<br>同样是逛商场的例子，我刚刚进入商场，应该是鼓励我多逛几个店，并通过明亮的灯光、热情的音乐等方式激发我的购买欲望，而不是在门口直接拦住我给我推荐一款笑脸包。
+</li>
+
+第五，解释清楚产品功能方案。一般包含以下六个方面。
+
+<li>**如何开启这个功能。**
+</li>
+<li>**这个功能的流程图是什么样的，这是最重要的部分。**<br>你需要针对每一种场景画出流程图，目的是让团队成员有一个清晰的认识。这个流程图，并不一定是经过精心雕琢产生的精美图表， 也可以用第1步、第2步、第3步等方式来表达。
+</li>
+<li>**这个功能哪些部分可以使用已有的架构或者产品流，这样可以在已有基础上稍作修改，而不用重新开发，可以大大节约产品开发时间。  **<br>比如， 豆瓣已经存在电影推荐和音乐推荐功能了，所以图书的推荐列表可以参照以前的产品流。<br>再比如，我们已经推出了让用户选择自己喜欢的音乐类型的功能，根据用户做的音乐类型测试的结果，向他们推荐音乐。同样的测试流程，我们可以直接应用在图书推荐上。
+</li>
+<li>**如果涉及到和其他组合作时，我需要先和其他部门沟通好，方便我们组开展工作。  **<br>比如，我们这个功能会和其他组的产品功能在UI上有一些冲突，他们可能要修改“推荐”这个总菜单， 这个总菜单包含我们的图书推荐功能，那就需要在产品需求文档里面记录这个情况。
+</li>
+<li>**有些情况下这个功能可能无法达到预期效果，那么这时的解决方案是什么。**<br>比如，用户没有任何图书浏览记录， 那我们可能就无法提供个性化的图书推荐， 这时我们要么随便推荐一堆书，要么直接导入畅销书单。<br>再比如，图书推荐的功能是通过分析用户看了图书A后还喜欢看什么书来推荐的，但是有些英文新书，这个功能会因为没有足够的资料而无法生成推荐， 这时我们需要告诉用户这本书不适用于图书推荐这个功能。
+</li>
+<li>**往往事先没有想清楚的地方都可能会出现问题，导致整个产品设计和开发都得从头来，这也是一个坑。**<br>一个推荐系统经常会出现的问题是，重复推荐的现象。造成图书推荐系统重复推荐的原因，可能包括：不同出版社的同一本书，或者同一个出版社、同一个作家的2014年版、2015年修订版、2016年再版。如果一个书单里10本书，有3本是重复的，那体验就太差了，所以我们需要找到一个可以去掉重复书名的方式。<br>如果这个问题在之前数据提取的时候就已经考虑到了，那么我们训练的机器学习模型的结果就会比较准确。可是，如果事先没考虑到这个情况，那就需要在发现这个问题后，从头开始了。<br>比如，《爱的教育》这本书，有无数个版本（宝宝版、小学必读版、人生成长版、精编版、简化版），相关的推荐系统的数据就很容易分散。如果销量或者评论数是推荐系统的一个重要指标的话，那么本来《爱的教育》这本书所有版本加起来有1万条评论，但因为系统默认是不同的书，就导致每个版本的几百个评论在推荐系统的畅销排名都很低，所以这本书压根儿就不会出现在书单上。发现这个问题之后，就要重新处理数据、重新运行训练环境、更新畅销排名等工作，非常容易推迟产品的发布。
+</li>
+
+## 总结
+
+这篇文章我和你分享了产品需求文档需要包含五大关键内容：解决的痛点问题是什么，论证这个痛点确实存在，说明如何衡量成功，要清晰描述场景，并解释清楚产品功能方案。
+
+成功的产品需求文档，可以让团队成员都明确要解决的痛点以及解决的方式，让大家对产品从策略到执行都清清楚楚，从而实现团队成员之间的高效沟通。
+
+另外，我还跟你分享了两个可能会踩的坑：一是，没有论证这个痛点到底是不是存在，而是想当然认为用户肯定有这个痛点；二是，没有提前考虑到产品可能出问题、实际执行影响预期功能计划的情况，导致产品发布时间推后。
+
+## 思考题
+
+如果你是微信公众号的产品经理，现在要添加一个粉丝可以和偶像互动的功能，你会怎么设计？你的产品需求文档会包含哪些内容？有哪些需要注意的地方？欢迎给我留言。
+
+

极客时间专栏/硅谷产品实战36讲/产品经理基本功/14 | 如何用数据做出产品决定？.md

@@ -0,0 +1,81 @@
+<audio id="audio" title="14 | 如何用数据做出产品决定？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/43/89/432e1a2a70e2ef3de560d6d3fc727389.mp3"></audio>
+
+今天这篇文章我用一个增长日活数的案例，跟你分享一下如何用数据做出产品决定。
+
+## 案例背景：通过提高新用户的留存率来提高日活数
+
+我们希望能够把不同活跃程度的用户区分开来，于是就发明了一个指标：七天活跃天数。我们用D7表示这个指标，直观体现留存率：D7=1，代表用户在过去的7天只使用了这个APP一天；D7=7，代表用户在过去的7天中每天至少使用这个APP一次。D7&gt;4代表高活跃度用户，2&lt;D7&lt;4代表中等活跃度用户，D7&lt;2代表低活跃度用户。
+
+通过对已有数据的分析，我们发现很多低活跃度用户并没有关注其他用户，他们的朋友圈根本没有任何内容，只能通过搜索来看内容。因此，我们认为用户关注其他用户的数量会影响到用户留存率，此时我们并不是非常清楚其他因素是否会影响留存率，所以我们可以先假设，关注其他用户对提高用户留存率非常重要。
+
+## 形成假设
+
+**第一个问题是，影响用户留存率的原因是什么。**
+
+这个问题需要考虑以下两种情况：
+
+- 第一种假设是，用户没有关注其他用户（或关注的数量非常少），他们的朋友圈里没有足够的内容，因此在APP里停留的时间也就非常短。
+- 第二种假设是，用户没有被其他用户关注（或关注他的人非常少），他们的朋友圈虽然有内容，但是他们自己发出内容时很少会有人回复，久而久之丧失了对APP的激情。
+
+我们假设这两种情况都会影响用户的留存率，但是影响留存率的原因并不一样。所以我们需要弄清楚，哪种情况发生的频率更高、对用户留存率的影响最大、应该先优化哪部分。
+
+**第二个问题是，用户的关注数量到底会不会影响留存率。**
+
+当用户关注100个人、1000人和只关注1个人时，对留存率的影响是同一个级别的吗？用户自己的粉丝数量会不会影响留存率？当你有100个、1000个和只有1个粉丝的时候，是不是也会不同程度影响你的留存率呢？
+
+形成假设时要避免的坑是，切记要分情况考虑。不能简单地归类为增加关注数，而是要考虑清楚增加关注数其实影响了两类人，一类是关注别人的人，一类是被关注的人，这两种情况很有可能带来的结果完全不一样，所以要分开考虑、分开假设。
+
+## 解决问题
+
+**第一个问题，影响用户留存率的原因是什么，我们通过A/B测试的方式来解决。** 我们需要设计两组独立的实验来区分关注和被关注对用户留存率的影响。
+
+- **关注其他用户与否**： 我们给实验组用户的朋友圈推荐好友关注，他们可以直接一键关注所有人。这个推荐内容在用户每次打开朋友圈时都出现在第一条状态的上面，以增加用户使用这个功能的概率。对照组用户的朋友圈没有添加这个功能，只显示已经关注的朋友的内容。
+- **被其他用户关注与否**： 我们把实验组用户的账号作为推荐放到其他用户朋友圈的第一条，增加他被其他用户关注的概率。对照组用户的账号，我们会避免它们被推荐给其他好友。
+
+我们通过两组实验对比发现， 当我们帮助用户关注更多其他用户后，他们的D7增加了6%；而当我们帮助用户获取更多粉丝后，他们的D7增加了4%。这说明，帮助用户关注更多人或者帮他们吸粉，可以让增加他们的留存率。
+
+我们还设置了一组对比实验，分别在用户使用APP的第一周、第二周、第三周和第四周帮助他们关注其他更多用户。通过实验数据，我们发现，在用户开始使用的第一周时就让他们关注更多人，否则他们非常容易流失，而且再也不回来了。
+
+除了帮助用户尽快关注别人，也要考虑尽快帮助用户吸粉，为此我们对比了第一周帮他们吸粉和过几周后再帮他们吸粉的数据，结果发现虽然第一周帮他们吸粉的效果会好一些，但是影响没有很明显。
+
+通过上面的分析过程，我们制定了产品策略：增加一个“你可能想关注”的版块，在新用户第一周使用APP时，向他们推荐其他用户，并在这个板块里预留几个名额给其他的新用户。那么，这个版块既可以帮助新用户关注更多其他用户，又可以帮助新用户吸粉，相当于一箭双雕。
+
+之后我们又做了一些优化：推荐什么用户才能帮助新用户提高留存率呢？为此，我们增加了推荐系统，根据新用户提供的个人信息进行推荐，或者根据新用户所在的位置、年龄、手机类型等进行推荐。
+
+**第二个问题，用户的关注数量到底会不会影响留存率，我们用统计图的方式来解决。**
+
+<li>**针对帮助用户关注更多其他用户的假设，统计图的横轴设置为新用户第一个周内关注其他用户的数量，纵轴为D7。**<br>我们发现，当用户关注的其他用户数量在20个左右的时候就到了所谓的临界点，也就是说，D7逐渐趋于平坦，增速显著放缓。因此，我们发现了“20”这个魔法数字。所以我们把“帮助新用户在第一周内关注更多的其他用户”的策略，调整为“帮助新用户在第一周关注20个其他用户”。<br>通过上面的数据，我们做出了另一个重要决定，我们需要开发一系列功能，来帮助新用户快速发现、搜索其他用户，探索值得关注的主题以及每个主题对应的活跃用户，最终达到一周关注20个其他用户的目的。
+</li>
+<li>针对用户粉丝数量对留存率的影响，我们做了同样的统计图：横轴设置为用户的粉丝数量，纵轴为D7。<br>通过数据，我们发现用户的粉丝量不在多，如果有几个特别忠实的粉丝给你评论、发消息，你照样可以坚持在APP上发状态，增加D7。所以，我们需要帮助你的忠实粉丝找到你，让你的忠实粉丝在你刚使用APP发东西时就能找到你、关注你。  
+</li>
+
+这里需要注意的是，当你验证了某个指标对你的成功有影响时（比如用户关注其他用户的数量对于产品留存率有积极作用），不要仅仅停留于此，还要更深入的研究这个影响是正面的还是负面的、到底有多大、在什么情况下影响最大。你要找到那个可以发挥最大影响力的点，比如这个例子中的“20”，否则就会出现效果未达到预期或者事倍功半的结果。
+
+## 产品决定
+
+根据上面的数据分析，我们决定做以下的产品功能：
+
+<li>将“你可能想关注”板块作为重点，特别是针对第一周使用APP的新用户。
+</li>
+<li>“你可能想关注”板块中，涵盖高质量老用户以及其他新用户。高质量老用户用来帮助这个新用户找到有意思的内容，推荐其他新用户是为了帮助他们增加粉丝量。
+</li>
+<li>除此之外，想尽可能多的方式帮助新用户在第一个星期内关注20个用户。我们可以通过优化搜索推荐的方式，给这些新用户推荐更有价值的用户，并引领他们到广场上发现有意思的内容从而增加他们关注其他用户的数量等。
+</li>
+
+## 总结
+
+这篇文章我用一个增长日活数的例子跟你分享了如何用数据做决定。
+
+首先，要形成具体的假设，注意要把不同的假设分开写，而不是合起来写一个泛泛的假设。
+
+其次，可以通过A/B测试的方式验证假设，每个假设需要单独设置对比实验来验证。
+
+然后，验证完了某个变量对总体的成功指标有积极影响后， 需要找到这个变量影响整体指标提升的规律。
+
+最后，要通过验证的假设决定产品功能，这才能保证你的产品可以真正能提升成功指标。
+
+## 思考题
+
+如何增加抖音用户的留存率？你有哪些假设，如何验证这些假设？
+
+

极客时间专栏/硅谷产品实战36讲/产品经理基本功/15 | 如何组织有效的会议？.md

@@ -0,0 +1,59 @@
+<audio id="audio" title="15 | 如何组织有效的会议？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4d/96/4db7d87e1d7dc52eb272fecf76393096.mp3"></audio>
+
+产品需求讨论会对产品经理来说是家常便饭。
+
+当产品经理对我们应该解决什么痛点、有哪些功能有了一个计划，接下来就需要组织产品需求讨论会了。我会和工程师、设计师等团队成员坐在一起讨论对这个功能的看法，跟他们讲讲这些功能一步一步的体验是什么样的：设计师是不是觉得这个设计是以人为本的；工程师会不会说我们的底层结构不支持，这个根本做不了。
+
+**简单地说， 产品需求讨论会目的是要明确我们的功能、量化成功的标准和时间表，团队成员达成一致意见后就开始撸起袖子努力干了。**
+
+首先，我跟你分享一个失败的产品需求讨论会，通过这个例子让你明白会议低效的几个常见原因，以及组织会议的几个误区。然后，针对这个案例的具体情况，我会告诉你怎么才能提高产品需求会的效率。最后，我会结合以前自己踩过的坑（说多了都是泪啊），跟你分享几个组织高效会议的独门秘诀。
+
+## 案例：一个失败的产品需求讨论会
+
+前段时间，隔壁组的产品经理组织了一个产品需求讨论会，讨论一个由他们主导的新功能，因为这个功能需要和我们合作才能实现，所以我们组也被邀请去开会。这个产品经理写了一本厚重的产品需求文档，组织大家每天一个小时讨论这个文档。
+
+这个会议共有21人参加，包括：我们组的产品经理、工程经理、工程负责人和运营经理，他们组的产品经理、高级工程经理、工程经理、工程负责人、5个工程师、2个律师、设计师、设计师经理、数据科学家、用户体验调研师、运营经理、运营专员。
+
+如此多的人员每天聚在一起一个小时，逐项地讨论这个需求文档，进展非常慢。在第五天的时候，他们的高级工程经理忍无可忍，当场问责：“每天在这里浪费时间，结果什么都没有讨论出来，这个模式根本不行”。这个产品经理瞬间不知道该怎么办了。
+
+这次的产品需求讨论会，可以说是我在Facebook三年多以来开过的最杂乱无章的会。那么，我来给你分析一下这个产品需求讨论会失败的原因，其实这些原因都源于对产品需求会认知的误区。 
+
+<li><p>**以为开会要让全组的人都有参与感，所以邀请了所有人，导致参会者众多。**
+这个新功能是针对众多媒体公司的，有点类似企业软件。它是一个复杂的工作流，涉及非常多的情况，每种情况对应的逻辑都不同，而且要符合对应的法律、政策等要求。<br>其实真正懂这个功能的也只有三四个人，但是团队其他成员都想参与进来，可以对产品功能做一些决定，而这个产品经理也希望可以讨好团队的每个成员。所以，会议的大部分时间都花在给这些不懂产品的人解答最基本的问题上，因此效率非常低。</p>
+</li>
+<li>**以为多开几次会，多聊聊，效率会很高，但是大家都有很多会议要参加，因此每次开会都有不一样的人缺勤，导致会议效率低下。** 每次开会都要跟上次缺席的人同步进度，往往会议开始的前十分钟甚至更长的时间，都浪费在这里了，这就导致了会议效率特别低下。
+</li>
+<li>**以为开会的目的是要从头开始逐项讨论，并得到大家一致的认同，所以细节讨论占据了会议大部分时间，反而来不及做重要的决定。** 会议的模式决定了，如果一个成员有疑问，大家就都要停下来解决这个问题，一个小时很快就过去，于是未来得及做的重要决定又要第二天的会议来讨论。
+</li>
+
+那针对这样的情况，通过怎样的方式才可以避免呢？
+
+<li>**一鼓作气 ，并设定一个需要作出决定的时间。**<br>比如，这个复杂功能的需求讨论会可以把大家集中在一起5个小时，将100%的精力投入到整个会议中，一次搞定而不要分散成多次进行。如果这5个小时讨论不出结果，可以设定一个截止日期（比如周五之前），如果讨论不出来就加班继续讨论。<br>人类其实是一个很有意思的物种，没有截止日期的话，大家就会觉得有的是时间，拖来拖去；如果设置了截止日期，大家就会觉得工作压力大，最终争分夺秒赶在截止日期的时候完成。<br>所以，即使不知道这个会议需要多久才能开完，也一定要设置一个截止日期，哪怕到时候没能完成，往后推两天也比没有截止日期的效果来得好。
+</li>
+<li>**分工明确，减少参会人数。**<br>可以先开一个项目启动会议。你可以邀请团队所有成员参加这个启动会，告诉他们这个产品开发的背景知识、调研结果、核心原则等战略和原则性的内容。比如，对于网红新的赚钱方式的讨论，你可以告诉大家一定不能允许网红自行植入软广，这样才能保证我们可以控制营销内容和普通内容的比例。<br>按照工作内容划分小组，并确定每个小组的成功标准、具体负责人，然后每个小组分别开会。这个小组划分的工作可以在项目启动会上完成。在这个案例里，你可以成立一个小组专门负责法律问题，小组成员包括律师、运营人员；再设置一个小组负责帮助网红适应和开启新的功能，小组成员包括用户体验分析师、负责增长的工程师、数据科学家等。<br>每周召集所有成员开一次会，有每个小组的负责人汇报工作进度，并解决他们遇到的问题。这样既可以满足其他成员了解整个项目进展的需求，增加他们的归属感，又可以减少每个决定需要的人员数量，提高会议效率。
+</li>
+
+## 组织成功产品需求会的秘诀
+
+根据我自己的工作经验，以及所见所闻，我给你总结几个产品经理组织高效产品需求会议的秘诀。
+
+<li>**精准管理开会的时间。**在会议开始前，做好会议时间规划文档，精准到分钟，你可以采用上周数据更新（3分钟，张娜）、产品测试结果（5分钟，小王）这样的方式。<br>比如，第一部分由某工程师介绍功能开发计划，你给他规划的时间是 5 分钟。如果大家讨论无足轻重的细节问题或者快要到5分钟的时候，你可以礼貌地提醒大家注意时间。虽然这种方式打断了大家的讨论，但会议非常有效率，会后也没有人因为被打断觉得不被尊重。<br>以前我没有做会议时间规划时，不好意思打断别人，结果每次开会都有二十分钟甚至更长的时间在讨论无关紧要的问题，而且往往只有两个人针对这种问题争论不休，其他人都无所事事。但是，自从有了精确管理开会时间的文档，我可以非常礼貌地打断这种无关紧要的争论，并且他们会非常自觉地把这个问题留到会后单独讨论解决。
+</li>
+<li>**如果无法做出统一的决定，那就统一大家做决定的思考方式。这是一个可以让团队意见统一的迂回战术。**<br>比如，开会的时候大家一直在争论到底是做A决定还是B决定，这样的情况我们可以先不讨论到底是选A还是B。我们可以约定用更多的数据或者用户反馈来做决定，并统一做下一步决定的思考方式：如果数据达到X%我们就选择A， 否则就选B。<br>通过约定统一的思考方式，可以让僵持不下的两方取得统一意见，这种公允的决策方式可以取得两方人的信服。<br>我以前就遇到过这个问题，设计师、工程师虎视眈眈，公说公有理，婆说婆有理，谁都不肯让步，即使我更认同工程师的想法，也不能在这个时候直接怼设计师，否则这场争论不但不会停止，反而会扩大。但是，我采用“统一他们思考问题的方式”的迂回战术，那双方很快就点点头表示认可，问题随之解决了。<br>原因是什么呢？两个人的看法可以说都是对的，因为他们看重的情况不一样。但是，看完数据后，我和设计师说：“你的假设很有道理，但是通过数据我们发现，这种情况并不多见，所以综合考虑，我们决定做XXX”。这时，设计师会点点头，表示认可。最终，和平就这么来了。
+</li>
+<li>**会议开始时先说明会议要达到的目的。**<br>比如，在会议开始时，告诉大家未来的30分钟我们需要一起做出什么决定。那么当会议开始后，大家一般都会直奔主题，可以非常有效率的得到你想要的结果，会议成员也会觉得这三十分钟没有白白浪费掉。<br>我刚开始做产品经理时，就犯了一个错误。我组织了一个确定成功指标的会，但是没有和参会者说明会议目的，最终三十分钟的会议什么问题都没有解决。会后就有人跟我的老板反映，白白浪费了三十分钟，什么问题都没解决。被老板大骂一通后，我认识到了问题出在哪里，所以吃一堑长一智，在每次会议开始时先说明要达到的目的，这种问题就再也没有出现过了。
+</li>
+
+## 总结
+
+接下来，我给你提炼一下本篇文章的要点。
+
+我从一个失败的产品需求讨论会为切入点，跟你分析了造成会议低效的原因往往是：每次都邀请所有人参会，并让细节的讨论占据了太多的时间。因此，针对比较复杂的产品需求讨论会，你可以这样做：1. 一鼓作气，尽量通过一次会议解决，如果解决不了，就设置一个截止日期；2. 按照产品内容分成小组，然后各小组讨论，最后汇总。
+
+我还跟你分享了我踩坑之后获得的独门秘诀：1.精准管理开会事项，管理时间到分钟；2.如果无法做出统一的决定，那就统一大家做决定的思考方式，尤其适用于两方僵持不下，各自都非常往心里去的紧张情况；3.会议开始时先说明会议要到的目的，比如设定出产品路线图，或者确定产品成功指标，一定要明确这个目的。
+
+## 思考题
+
+回想一下，上一次你组织的或者参加的失败的产品需求会议，你认为会议效率低下的原因是什么？如果可以重新来一次，你会在哪些方面进行改进？欢迎你给我留言。
+
+

极客时间专栏/硅谷产品实战36讲/产品经理基本功/16 | 如何和工程师有效沟通？.md

@@ -0,0 +1,120 @@
+<audio id="audio" title="16 | 如何和工程师有效沟通？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0d/fb/0d89264a857e31dc5780eb0c38541ffb.mp3"></audio>
+
+工程师和产品经理之间的恩怨情仇，一直是科技圈茶余饭后久盛不衰的一个话题。“产品狗”摧残“码农”的故事、或者工程师吐槽产品经理什么也不懂只会乱提需求的段子屡见不鲜。那么，产品经理和工程师到底能不能和谐共处，成为一个战线上的好伙伴？
+
+其实，一个优秀的产品经理不仅能和工程师有效合作，甚至可以让工程师觉得跟定了你，没你不行。
+
+在硅谷，我们常说一个顶尖的产品经理每次跳槽，都能拉走一堆优秀的工程师，究其原因：一是，这样的产品经理确实不多见；二是，遇到一个好的产品经理，工程师可以把更多精力花到他们感兴趣的、有巨大影响力的方面，可以更有效率地做出优秀的产品。
+
+## 优秀的产品经理能激发工程师的能动性
+
+在硅谷的很多顶尖科技公司，都是 “工程师导向”的文化，也就要求产品经理不能像监工一样告诉工程师应该做什么。如果产品经理对工程师指手画脚，那工程师会顿时失去工作的兴趣，吵着嚷着要换组、换产品经理。
+
+但是，一个真正优秀的产品经理能够让工程师兴奋起来，满腔热情地投入到产品开发中；而这种热情一旦被激发出来，产品经理就再也不用担心工程师会拖延工期、消极怠工，相反工程师甚至会比你更积极。
+
+那怎么才能激发工程师的能动性呢？我至少和百位不同背景、不同资历的工程师工作过，在无数次“踩坑”后，我总结了下面的这些建议。
+
+第一，作为产品经理，你应该知道这个工程师在乎的是什么。
+
+他是一个刚毕业不久、满腔激情、想赶快升职加薪的工程师？还是一个想解决最高难度的技术问题，哪怕产品没人用，只要解决的问题难度足够高就高兴的工程师？还是一个满肚子主意，极其讨厌产品经理告诉他该做什么的“点子大王”？还是一个有些害羞、很多想法都憋在心里，但其实特别希望自己有存在感的人？
+
+**知道了他在乎什么，你才能知道怎么激发他的能动性，以及该让什么人做什么样的项目。**
+
+<li>
+想升职的工程师肯定喜欢做老板能看得见的项目，哪怕这些项目没有多高的难度，帮助这些工程师在老板面前“出出风头”，他们肯定对你死心塌地。
+</li>
+<li>
+技术宅？那你就给他们强调一下，这个项目的哪些技术问题是其他工程师想想就头疼、根本解决不了的，满足他们的虚荣心。
+</li>
+<li>
+<p>“点子大王”？那就找机会表扬他的点子又多又好，就算这个想法是你先想出来的，你也可以在和他交流时循循善诱，引导他说出你的想法，然后赞叹他的想法真厉害。<br />
+比如，如果你认为应该在视频平台上做一个让用户发弹幕的功能，不要直接和“点子大王”说：“你负责做弹幕”，而是要从问题出发，你可以说“我们的视频互动性太差，用户都不喜欢发评论”，然后引导他说出做弹幕的主意。</p>
+</li>
+<li>
+至于害羞的工程师，你可以在开会的时候刻意给他们表达自己的机会，他们绝对对你感激涕零，期待和你继续合作。
+</li>
+
+**知道工程师要什么，想办法在现有的项目里给他们相应的机会，会让你们之间的合作事半功倍。** 至于怎么知道工程师要什么，你不如和他约个时间喝杯咖啡私聊一下，了解他的个人情况，你甚至可以直接问他：“你是如何决定自己做的事情有没有价值的，你在乎的是什么？”
+
+第二，产品经理应该知道怎么和工程师沟通最有效率。
+
+很多工程师最讨厌的就是开会，因为30分钟的会议打断了他们的思考时间，拖慢了他们写代码的进度。
+
+所以作为产品经理，虽然你每天要花很多时间在开会上，但是要考虑一下这个会到底有没有必要让工程师参加，可不可以安排到这个工程师其他会议之前或者之后的时间， 这样尽量少地打断他们的思考，以便于他们有效率地编程。
+
+你还需要思考，除了开会之外，还有没有其他可以高效做决定的方式，比如发个邮件。
+
+第三，产品经理要弄清楚什么决定需要自己领导大家做，什么决定可以放心地交给工程师们自己做。
+
+比如，某个按钮是100像素还是120像素，类似这样的决定，是不是可以让工程师和设计师自己决定？
+
+**很多产品经理常犯的错误是，自己做出所有的决定，和工程师交流时只是要求他们按照指定要求来做，但实际上有些要求根本就不切实际。** 更或者，按钮是100像素还是120像素，可能对于产品的成败来说，并不是最重要的决定， 你完全没必要在这种决定上花时间。
+
+还有些产品经理只告诉工程师要做什么，从来不解释产品的目的、成功的标准，工程师完全不知道这些决定背后的策略和思考过程， 结果就是事事都需要产品经理告诉他们要怎么做。
+
+其实，**一个好的产品经理一定会清晰表达产品要解决的问题、如何衡量成功、需要最先解决的用例以及原因，让产品团队的工程师、设计师、数据科学家等都有足够的背景信息。** 这样，很多的小决定完全可以让团队成员自己做，从而既可以大大提高产品效率，又可以提高团队成员的能动性。
+
+当然，这并不是说产品经理什么决定也不用做，**一个优秀的产品经理，会确保自己的时间花在“非我不可”的事情上**，其他决定都会交给他人。设想， 如果一个产品经理把每天的时间都花在解决按钮是100像素还是120像素这种问题上，他们哪还有时间去和客户做一对一交流、制定产品战略、思考“脑洞大开”的新功能。
+
+第四，产品经理应该帮助工程师解决开发过程中的一些困难。
+
+很多工程师在开发过程中会遇到一些困难，比如因为其他组工程师进展缓慢而导致开发工作停滞，因为开发的新功能被律师认为风险太大而面临一些质疑，等等。因此，产品经理应该积极询问工程师：“你需不需要我为你提供一些帮助”，帮助工程师解决开发过程中遇到的障碍。
+
+**因此，帮助工程师扫清开发路上的各种障碍，可以提升你的产品开发效率，而这正是优秀的产品经理需要做的事情。** 比如，我常常对工程师说：“现在有哪些工作是你不喜欢做的，告诉我，无论是脏活累活，我来帮你做”。其实，这也是一个帮助你和工程师建立信任关系的过程。
+
+## 怎么催工程师加快进度？
+
+这个问题是很多刚入行的产品经理最担心的，我的建议是，让工程师先自己估计需要的工期，然后再设定截止日期。如果他们预估的工期太长，我可能会提出一些问题，弄清楚为什么需要这么长时间，看看哪些部分可以砍掉，到底值不值得为截止日期砍掉这些功能。
+
+工程师估计完自己需要的时间后，我会和工程师说明我们的发布计划， 比如某月某日营销团队会开始宣传产品功能、 某月某日我们需要开始运营工作等等，这样可以让工程师了解其他部门的进度，增强他们的归属感。
+
+刚入行不久的工程师估计工期的能力比较差，如果他们的工期估计得太长，我就会想方设法让他们告诉我工期是怎么估计出来的，然后跟他一起讨论，哪些部分可以用现成的API，哪些部分可以少花一些时间。
+
+如果遇到确实要将截止日期提前的情况，我会告诉工程师需要提前的详细原因。这样做的目的是，让工程师觉得你和他是一起的，让他感觉到你的信任、你在思考如何一起解决工期提前的问题。
+
+所以，我一般不会直接说要花多长时间，而是让工程师先估计工期，如果我觉得估计得过长，我会诚恳地告诉他我们需要加快进度，看看有没有什么方式能够重新组合一些计划，以加快工期。
+
+在这里，**一定要让工程师觉得自己是有掌控权的，而不是产品经理一拍脑袋，就决定个截止日期。** 就算这个截止日期是你自己拍脑袋决定或者老板要求的，在表达日期的时候也要尽量体现出对工程师的尊重，用问问题的形式表达自己的看法，积极地和工程师一起寻求提前工期的方式。
+
+## 产品经理常见的棘手问题：需要改需求怎么办？
+
+改产品需求是一个非常常见的过程，有些时候前期计划做得很好，开始Beta测试时却发现，用户对某个功能根本不理解，还是需要改动。
+
+其实，开发本来就是一个不断迭代的过程，所以应该首先认识到，产品开发不是产品经理闷头花几个星期写一个文档， 然后再抛给工程师让他们按照这个文档执行的过程。
+
+但是，改需求并不代表产品经理可以在产品需求文档上胡写乱写，做出一些不靠谱的决定，这是在浪费工程师的时间。这里我就跟你说说有哪些方式能够避免在开发后期改需求，如果真的要改需求，如何和工程师有效沟通。
+
+<li>
+**尽早和工程师进行产品功能设计的讨论，让他们提前了解各种背景信息。**我平时的工作方式是，先在产品需求文档中写明需要解决的问题、如何判断成功，并写几个产品方案的初稿，和工程师、设计师们进行讨论，回答他们的问题，让他们一开始就参与进来。通过这个讨论过程，我可以知道有什么技术上的局限性，然后根据大家的反馈修改产品需求文档。这样可以避免在工程师花费大量时间后才发现问题，然后重新来过，导致工程师做无用功。
+</li>
+<li>
+**如果确实需要让工程师们重新写已经写好的东西， 或者砍掉他们已经写好的东西，一定要积极承担责任。**  这种情况，可能是因为你作为产品经理少考虑了某些情况，也可能是突然发生了一些变故，比如公司改变了策略、竞争对手突然“搞事情”。虽然这并不一定是你的责任，但是这时你还是应该积极和工程师交流，主动承担责任，告诉他们：“这个赖我，辛苦你了”。
+</li>
+
+其实很多时候，就算产品经理自己主动承担责任，工程师也不会“顺杆爬”埋怨你，他们反而觉得你是个靠得住的好产品经理，甚至会过来安慰你。
+
+积极承担责任，说句“抱歉，辛苦了”，虽然对你来说就是一句话的事儿，但这可以很好地安抚已经努力工作了一个月、每天加班加点儿的工程师。很多时候，给工程师们一些鼓励和温暖，虽然看上去微不足道，但却能让他们干劲儿百倍，对你死心塌地。
+
+## 总结
+
+最后，我来给你提炼一下今天的要点。
+
+要做到和工程师的有效沟通，你作为产品经理需要做到：第一，知道这个工程师在乎的是什么；第二，知道怎么和工程师沟通最有效率；第三，弄清楚什么决定需要自己领导大家做，什么决定可以放心地交给工程师们做；第四，帮助工程师解决开发过程中遇到的困难。
+
+接下来，我还跟你分享了怎么催工程师加快进度，以及怎么处理改产品需求这种常见的棘手问题，归纳起来不外乎这几点：第一，尽早和工程师进行产品功能设计的讨论，让他们提前了解各种背景信息；第二，积极承担责任，把过错往自己的身上揽，而不要抛给工程师；第三，要让工程师觉得自己是有掌控权的，而不是产品经理一拍脑袋就决定了截止日期和产品的需求。
+
+## 思考题
+
+<li>
+你的一个工程师平日少言寡语，从不会主动表达自己的想法，会议的时候也不怎么发言，但是你在产品开发的过程中发现，他并不完全同意大家的决定，所以也不能很顺畅地执行，那么你作为产品经理应该怎么做？
+</li>
+<li>
+你的一个产品功能，因为测试的体验太差，有被砍掉的风险，而这个主意是你自己提出来的，你会怎么和工程师沟通这个糟糕的结果？
+</li>
+<li>
+你的一个工程师鄙视你没有工程背景，在做决定的时候并不信任你提出的建议，你该怎么取得他的信任？
+</li>
+
+欢迎你给我留言。
+
+

极客时间专栏/硅谷产品实战36讲/产品经理基本功/17 | 如何与设计师有效沟通？.md

@@ -0,0 +1,63 @@
+<audio id="audio" title="17 | 如何与设计师有效沟通？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/2c/6f/2c631263d76773321c31dec238690e6f.mp3"></audio>
+
+虽然，产品经理和工程师之间的恩怨情仇是科技圈讨论得最多的话题，但实际上，我刚入行时和设计师的关系是最有挑战、最让我最头疼的。
+
+在和设计师交流这件事上， 我花了很多精力、也得罪了不少设计师。痛定思痛，我总结出了一些可以和设计师高效沟通的方式，希望这些建议可以成为你和设计师们沟通的“润滑剂”。
+
+## 设计师的艺术家型人格
+
+我刚入行时，有个设计师对我的意见很大，他认为我每天风风火火、节奏太快，让他感觉太紧张、工作压力太大；而我却觉得这个设计师慢慢悠悠，在很多根本不重要的小事儿上浪费了太多时间，影响了整个团队的进度。
+
+后来，老板对我说：“设计师是艺术家，艺术家都是完美型人格。他们在乎的是用户体验，而不是具体的数据指标提升了几个点，你要试着和他们换位思考。”这句话点醒了我。
+
+之前，我对设计师的方式和对工程师一样，简单粗暴、直戳要害，直接告诉他们我要什么、为什么要这么做、提升的是什么数据、增长的是什么指标。在这件事之后我意识到，很多设计师并不在意具体的数字指标，在他们看来，提升了5%又怎样，这个按钮的配色有问题，看着别扭就绝对不可以用。
+
+其实，很多优秀的产品设计大都源于设计师的艺术家型人格，这也就决定了设计师的角色在产品团队中不可或缺。因此，作为产品经理，时刻谨记“设计师都是艺术家”，实现和设计师的高效沟通是非常重要的。
+
+然而，在和设计师沟通时的方式，也要具体情况具体分析。在我看来，和设计师新人、老手打交道是很典型的两种不同方式。
+
+## 设计师新人和设计师老手的沟通技巧
+
+在一个产品团队，设计新人一般只负责产品具体的一个功能，产品经理要把产品要求甚至每部分做成什么样都写得一清二楚。这样，设计新人才能把产品经理制定的产品计划、产品体验，转化成具体的设计图。
+
+和设计师新人打交道时，需要注意以下三个问题。
+
+<li>**他们不具备产品思考能力，也不能从头设计一个产品。**<br>产品经理需要帮他们理清头绪，最快的方式就是直接告诉他们要做什么，让他们照着做。但是这样的问题是，设计新人总是需要成长，总是需要具备从头开始思考产品和体验的能力，所以你也需要给他们成长的空间，比如选取一部分时间不紧张的功能让他们从头开始设计，然后积极地给他们反馈。
+</li>
+<li>**如果不把产品功能的范围讲清楚，他们会抓不住重点。**<br>比如，明明一个按钮就可以解决的问题，他们会设计得过于复杂，导致工程师工期太长；再比如，他们设计了太多的功能，然而这些功能我们都可以先不做，产品发布后，看市场的反应再决定需要增加哪些功能。<br>所以，对设计师新人来说， 产品经理应该尽量帮助他们弄清楚这版产品应该涵盖哪些功能，哪些功能现在是不必要的。这样的沟通，最好在他们设计过程中进行，而不是等他们花了几个月、设计了一堆功能之后，才发现大部分功能现在看来都是不必要的。
+</li>
+<li>**他们估计工期的能力非常差。**<br>比如，他预估一个星期可以完成这个功能，但在设计时总感觉哪里不够完美、哪里又需要增加一些功能，导致一个星期的设计工作却拖了好几个星期没能完成。<br>所以，对于新人来说，产品经理需要提前告诉他：“这个设计一定要在一周之内完成，你可以在开始设计前，先写一个设计场景列表，我可以帮你看看，咱们确定好列表内容后你再开始。”
+</li>
+
+**相对于没有经验的设计师新人来说，老练的设计师可以设计范围很广的产品或者产品线。** 比如，他们可以设计一套从头到尾的用户体验，甚至设计一系列产品，或者完成公司全部产品的系统设计概览（比如，Facebook中朋友圈和视频里的评论，就是一套设计体系）。
+
+**设计老手可以解决模糊的产品问题，** 比如你告诉他，我们得设计一个面对面加好友的新方法，他就会设计出具体的功能和应用场景，而无需特别强调用二维码加好友的方式。
+
+因此，设计老手在你的团队，就意味着你无需把产品需求文档写得非常详细，比如不用具体说明某个按钮应该是什么样子的，但是你一定要写清楚产品要解决的问题、衡量成功的方式、第一版和第二版产品功能之间的路线图，这些内容适用于所有设计师。
+
+## 设计师和产品经理发生矛盾的常见原因
+
+<li>**设计师喜欢连贯与和谐，产品经理却要考虑开发效率，需要分析具体场景下连贯性是不是重要。**<br>有一次，我需要设计师重新设计所有的菜单列表，这个菜单列表涉及到三个场景，每个场景的样式都不一样，但只有一个场景的用户浏览量比较高。<br>在设计师看来，需要统一这三个场景下菜单列表的样式，这需要花费很多的时间。而在我看来，不常用的两个菜单列表可以直接砍掉，根本不值得浪费时间。<br>于是，我试图用这个菜单列表在三个场景下的用户浏览量数据来说服设计师，结果他很生气，认为数据不能代表完美的用户体验，为此我和设计师闹得很不愉快。<br>后来，我针对三个菜单列表的样式需不需要统一的问题进行了用户调研，用户直接说：“那两个场景我都不用，我不在乎它们的样式统不统一”。我把用户反馈告诉设计师后，他就很痛快地采取了我的意见。<br>从这件事中，我得到的启发是：作为产品经理，你要清楚设计师的完美型人格，他们往往更看重功能间的和谐、连贯，所以你需要主动地思考他们敏感的点是什么，比如用户反馈往往比数字更能让他们信服，以掌控产品的设计进度。
+</li>
+<li>**不同风格的设计师，针对不同的项目，对产品经理的期待不一样。**<br>同样一份产品需求文档，有的设计师认为功能描述太具体，限制了他们发挥的空间；有的设计师却认为不够具体。这是我刚做产品经理时感觉非常苦恼的一个问题，在和设计师打了多次交道后，我才明白了“众口难调”的原因，以及怎么处理这种情况。<br>在我看来，处理这种问题最直接、最高效的方式是，和你的设计师搞好关系，问问他们是喜欢文档中功能描述写得清楚些，还是只要给出策略性的建议就可以了。<br>你可以在每个项目的文档中先写策略性的内容，然后对设计师说：“这是咱们产品的策略和大致想法，你先看看有哪些部分不够清晰，我来写得更具体一些。”只有多沟通，才能更高效。
+</li>
+<li>**出于工期等原因，产品经理不得不砍掉设计师的完美设计蓝图中的一些功能。**<br>我们的一个产品，计划用一周的时间设计，两周的时间开发。但是，设计师灵感大发，从现在到未来，设计了一大堆现在不必要的功能，因此我不得不砍掉设计图中的大部分功能。<br>这时，我就很直接地跟设计师说：“你这个设计图中的功能太多了，我们现在只能实现里面的2个功能，其他几个功能的设计都要砍掉”。结果设计师非常生气，觉得自己的“完美设计”没有得到应有的尊重。<br>总结一下，**作为产品经理，我在这里踩了两个坑：第一，我应该在设计过程中多和他沟通，这样就可以避免他在不必要的功能上花费过多的时间；第二，我和他的沟通欠缺技巧，让他感觉自己的努力没有得到尊重。**<br>设计师的完美型人格，往往会让他们的设计过于理想化，而且他们的自尊心和对自己作品的保护意识都比较强。所以，一定要在设计中多沟通，而且沟通时要站在设计师的角度考虑充分。<br>因此，如果是因为没有及时、充分地和设计师沟通，导致他花了很多精力、做了很多不必要的功能，那在砍掉他的设计时，一定要注意沟通方式。你可以先感谢他考虑充分，完成了产品短期和长期的蓝图，然后告诉他我们现在工期紧张，只能先完成其中两个功能，剩下的功能要等产品发布之后再实现了。
+</li>
+
+## 总结
+
+通过今天的文章，我希望告诉你和设计师沟通的有效方法。
+
+产品经理和设计师的很多冲突来源于不同的价值观，设计师是艺术家型人格，他们更在乎功能间设计的连贯性、对数字不是特别敏感，而产品经理大多雷厉风行、结果导向，所以二者自然就存在一些冲突。
+
+要解决这样的冲突，首先是要意识到设计师菜鸟和老手之间的区别：对于设计师菜鸟，要帮助他们弄清楚要解决的问题以及产品功能的范围，控制设计的工期长度，并提前告诉他们哪些功能不重要可以先不设计；对于设计师老手，更多的是要给他们发挥的空间， 但是同样要沟通清楚产品解决的问题以及成功指标。
+
+最后，我跟你分享了产品经理和设计师冲突的主要原因。设计师追求完美、和谐，产品经理要和设计师多沟通，控制好他们的设计范围，帮助他们避免设计太大而导致无法按期开发的情况，需要砍设计时更要注意方式方法。
+
+## 思考题
+
+你身边的是设计师都有哪些特点？在和这些设计师沟通的过程中，你都踩过哪些坑？
+
+欢迎你给我留言。
+
+

极客时间专栏/硅谷产品实战36讲/产品经理基本功/18 | 如何搞定A|B测试？.md

@@ -0,0 +1,101 @@
+<audio id="audio" title="18 | 如何搞定A/B测试？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ba/c8/bacd0b489441d94c25f21ff8df0af7c8.mp3"></audio>
+
+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测试时间，从而观察产品的长期表现，适时作出决定。
+
+## 思考题
+
+你有没有经历过哪些产品（或者功能）的短期数据很好看，而长期数据却不好看？出现这个问题后，负责的产品经理是怎么处理的？
+
+欢迎你给我留言。
+
+