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