好书推荐——《优秀的产品经理》-CSDN博客

未经同意窃取和转载我的内容，如果涉及到权益问题，后果自负！

本文链接：https://blog.csdn.net/weixin_41605937/article/details/143447776

摘要

本文讨论了产品经理在功能取舍、产品需求文档撰写和数据驱动决策方面的能力实战。文章通过案例分析和实际操作，展示了如何利用现有架构、跨部门合作、处理功能预期外情况、避免重复推荐问题，并使用数据来提高用户留存率和日活数，最终形成有效的产品策略。

1. 产品经理对功能的取舍

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

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

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

第一是，我们的产品刚刚开始内测，一般会让公司内部所有员工使用进行测试，然后再开放给一部分用户使用。如果我们收到用户反馈说某个功能哪里哪里不好用，那我们就会讨论到底要不要把产品发布时间推后，先把这个功能修复好再发布产品。
第二是，我们的产品需要和其他组合作完成，但其他组出现了突发情况，以至于产品的某个功能无法按时完成。比如，我所在的视频组要和搜索组合作，完成允许用户通过关键词搜索视频的功能，但搜索组突然出现了问题，无法按照预定的发布时间实现“自动推荐关键词”，我们现在就会讨论到底是先砍掉这个功能直接发布产品，还是等到搜索组的问题解决后再发布这个产品。

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

1.1. 案例分析

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

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

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

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

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

1.2. 思考方式

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

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

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

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

方案一：我们产品的普通用户部分的功能，先在安卓平台发布，而iOS平台晚两周再发布，明星用户部分的功能发布日当天全部发布；其他几个产品正常发布。如果采用这种方案，我们需要考虑两个问题：第一个问题是，要和明星用户解释一下，普通用户部分的功能现在只有安卓平台发布了，iOS平台两周后才会发布，所以两周后的数据才是最有说服力的；第二个问题是，这个方案是有风险的，虽然我们已经跟明星用户做了解释，但毕竟数据不好看，明星用户依然会对我们的产品丧失信心。
方案二: 先发布其他几个针对明星用户的产品，而我们产品在安卓端和iOS端的发布全部推后两周。这个方案的风险是，因为我们产品延后发布，导致其他几个产品缺乏完整性、用户体验不连贯。
方案三：所有的产品全部推后两周调试完美后再发布。这样做的风险是，全部计划包括公关计划都会受影响，损失惨重，其他的组不会同意。

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

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

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

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

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

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

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

2. 如何撰写产品需求文档

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

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

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

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

2.1. 明确产品需求文档的目的

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

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

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

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

2.2.1. 要解决什么问题。

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

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

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

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

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

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

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

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

2.2.3. 写清楚这个功能的成功指标和反指标是什么。

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

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

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

2.2.4. 讲清楚要解决的用户场景。

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

用户已经选择了一本书，我们自动推荐给他和这本书类似的其他图书。
用户选择了自己感兴趣的主题，我们推荐书单。
用户刚刚进入豆瓣读书页面，自动根据他之前读的书以及喜欢的作家推荐书单。

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

第一种情况下，用户已经给了我们非常明确的信息，表明了他此时此刻找书的意向。比如，用户说：“我刚看了《钢铁是怎么炼成的》，给我推荐一本相似的书”。我们需要做的是根据已知的用户意向准确推荐，要着重推荐的准确和相关性，难点是怎么推荐和《钢铁是怎么炼成的》最相关的一本书。这就像我们走进商场，对售货员说：“我要买一条和这个笑脸包搭配的丝巾”，这时售货员就需要赶紧帮我找到很搭的丝巾，快、狠、准最要紧。
第二种情况下，用户只给了我们一点点暗示，有点“犹抱琵琶半遮面”的意思，他说：“我喜欢科幻小说，给我推荐几本”，这时我们需要根据这些信息，进行推荐。但是，可以推荐的科幻小说有很多，用户此时此刻也没有具体想要哪一本书的想法，更多的时候只是在探索。所以，我们的难点是：第一，给用户推荐各种各样的科幻小说，方便他们选择；第二，科幻小说有几万本，我们怎么决定推荐书单的排序；第三，如果给所有人都推荐《三体》这样的书单，难免有些单调，而且我们也不能确定用户会喜欢《三体》这个风格的图书，所以就需要注意科幻小说书单的多样性。这种情况就很像我们走进商场，跟售货员说：‘’我要买一个包包”，然后售货员直接给你介绍了三款最新流行的网红包，他们也不知道你到底喜不喜欢这个风格。
第三种情况下，我们并不了解用户使用图书推荐的目的，只能根据他以前的习惯进行推荐。他以前喜欢过《哈利波特》、《百年孤独》，也喜欢过《从零到一》，涉猎广泛，那我们可以推荐的书就实在太多了，并且我们并不知道用户此时此刻想看什么。用户刚进入豆瓣图书，可能只是想随便看看，或者找一本好书，或者找一个热销的书单，所以这时最重要的不是帮用户找到具体的某本书，而是要激发他们的兴趣，把他们引到更深层次的读书需求上，那就需要让他们多看看、多逛逛。同样是逛商场的例子，我刚刚进入商场，应该是鼓励我多逛几个店，并通过明亮的灯光、热情的音乐等方式激发我的购买欲望，而不是在门口直接拦住我给我推荐一款笑脸包。

2.2.5. 解释清楚产品功能方案

一般包含以下六个方面。

如何开启这个功能。
这个功能的流程图是什么样的，这是最重要的部分。 你需要针对每一种场景画出流程图，目的是让团队成员有一个清晰的认识。这个流程图，并不一定是经过精心雕琢产生的精美图表，也可以用第1步、第2步、第3步等方式来表达。
这个功能哪些部分可以使用已有的架构或者产品流，这样可以在已有基础上稍作修改，而不用重新开发，可以大大节约产品开发时间。 比如，豆瓣已经存在电影推荐和音乐推荐功能了，所以图书的推荐列表可以参照以前的产品流。再比如，我们已经推出了让用户选择自己喜欢的音乐类型的功能，根据用户做的音乐类型测试的结果，向他们推荐音乐。同样的测试流程，我们可以直接应用在图书推荐上。
如果涉及到和其他组合作时，我需要先和其他部门沟通好，方便我们组开展工作。 比如，我们这个功能会和其他组的产品功能在UI上有一些冲突，他们可能要修改“推荐”这个总菜单，这个总菜单包含我们的图书推荐功能，那就需要在产品需求文档里面记录这个情况。
有些情况下这个功能可能无法达到预期效果，那么这时的解决方案是什么。 比如，用户没有任何图书浏览记录，那我们可能就无法提供个性化的图书推荐，这时我们要么随便推荐一堆书，要么直接导入畅销书单。再比如，图书推荐的功能是通过分析用户看了图书A后还喜欢看什么书来推荐的，但是有些英文新书，这个功能会因为没有足够的资料而无法生成推荐，这时我们需要告诉用户这本书不适用于图书推荐这个功能。
往往事先没有想清楚的地方都可能会出现问题，导致整个产品设计和开发都得从头来，这也是一个坑。 一个推荐系统经常会出现的问题是，重复推荐的现象。造成图书推荐系统重复推荐的原因，可能包括：不同出版社的同一本书，或者同一个出版社、同一个作家的2014年版、2015年修订版、2016年再版。如果一个书单里10本书，有3本是重复的，那体验就太差了，所以我们需要找到一个可以去掉重复书名的方式。如果这个问题在之前数据提取的时候就已经考虑到了，那么我们训练的机器学习模型的结果就会比较准确。可是，如果事先没考虑到这个情况，那就需要在发现这个问题后，从头开始了。比如，《爱的教育》这本书，有无数个版本（宝宝版、小学必读版、人生成长版、精编版、简化版），相关的推荐系统的数据就很容易分散。如果销量或者评论数是推荐系统的一个重要指标的话，那么本来《爱的教育》这本书所有版本加起来有1万条评论，但因为系统默认是不同的书，就导致每个版本的几百个评论在推荐系统的畅销排名都很低，所以这本书压根儿就不会出现在书单上。发现这个问题之后，就要重新处理数据、重新运行训练环境、更新畅销排名等工作，非常容易推迟产品的发布。

3. 如何用数据做出产品决定

3.1. 案例分析

通过提高新用户的留存率来提高日活数。

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

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

3.2. 形成假设

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

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

第一种假设是，用户没有关注其他用户（或关注的数量非常少），他们的朋友圈里没有足够的内容，因此在APP里停留的时间也就非常短。
第二种假设是，用户没有被其他用户关注（或关注他的人非常少），他们的朋友圈虽然有内容，但是他们自己发出内容时很少会有人回复，久而久之丧失了对APP的激情。

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

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

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

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

3.3. 解决问题

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

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

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

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

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

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

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

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

针对帮助用户关注更多其他用户的假设，统计图的横轴设置为新用户第一个周内关注其他用户的数量，纵轴为D7。 我们发现，当用户关注的其他用户数量在20个左右的时候就到了所谓的临界点，也就是说，D7逐渐趋于平坦，增速显著放缓。因此，我们发现了“20”这个魔法数字。所以我们把“帮助新用户在第一周内关注更多的其他用户”的策略，调整为“帮助新用户在第一周关注20个其他用户”。通过上面的数据，我们做出了另一个重要决定，我们需要开发一系列功能，来帮助新用户快速发现、搜索其他用户，探索值得关注的主题以及每个主题对应的活跃用户，最终达到一周关注20个其他用户的目的。
针对用户粉丝数量对留存率的影响，我们做了同样的统计图：横轴设置为用户的粉丝数量，纵轴为D7。通过数据，我们发现用户的粉丝量不在多，如果有几个特别忠实的粉丝给你评论、发消息，你照样可以坚持在APP上发状态，增加D7。所以，我们需要帮助你的忠实粉丝找到你，让你的忠实粉丝在你刚使用APP发东西时就能找到你、关注你。

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