首先我自己，不喜欢把大量的时间花在写产品需求文档上。我认为，应该直接和工程师、设计师面对面地沟通，当面把东西讲清楚。这样做的缺点是，如果你的团队成员还不具备自己做一些小决定的能力，或者公司对于一些基本的 UI 部件没有固定的标准（在大公司，按钮、配色都有相应的设计准则），那么很有可能出现产品的功能和功能之间不协调的问题。尤其是当一个成员辞职后，整个产品组需要花很长时间来填补这个空缺。所以PRD还是需要的。只不过在产品需求文档中只写清楚最最重要的内容就可以了。

以下步骤理性写文档。。。。

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

撰写产品需求文档是为了和工程师、设计师、数据科学家等团队成员清晰的沟通产品蓝图， 讲清楚产品要解决的问题、 实现的场景、成功的标准等等， 并有据可查。所以，产品需求文档需要具备以下三种功能：

和团队成员高效沟通，用他们能够看懂的方式清晰地表达你的想法，让他们清楚什么该做什么不该做；

记录之前的问题是如何解决的；

明确列出产品功能的短期目标、长期目标，绘制一个从短期到长期的产品蓝图。

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

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

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

第一，要解决什么问题。

工程师、设计师等对产品解决的问题都有自己的理解，而且根本不在一个频道，这个情况在产品经理的工作中非常常见。所以：在产品需求文档中讲清楚到底我们要解决的问题是什么。

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

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

这个就可以参考挖掘用户需求的方式，但我们公司现阶段的需求主要来自客户和同类型产品，。

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

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

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

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

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

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

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

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

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

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

第一种情况下，用户已经给了我们非常明确的信息，表明了他此时此刻找书的意向。比如，用户说：“我刚看了《钢铁是怎么炼成的》，给我推荐一本相似的书”。

我们需要做的是根据已知的用户意向准确推荐，要着重推荐的准确和相关性，难点是怎么推荐和《钢铁是怎么炼成的》最相关的一本书。

这就像我们走进商场， 对售货员说：“我要买一条和这个笑脸包搭配的丝巾”，这时售货员就需要赶紧帮我找到很搭的丝巾，快、狠、准最要紧。

第二种情况下，用户只给了我们一点点暗示，有点“犹抱琵琶半遮面”的意思，他说：“我喜欢科幻小说，给我推荐几本”，这时我们需要根据这些信息，进行推荐。但是，可以推荐的科幻小说有很多，用户此时此刻也没有具体想要哪一本书的想法，更多的时候只是在探索。

所以，我们的难点是：第一，给用户推荐各种各样的科幻小说，方便他们选择；第二，科幻小说有几万本，我们怎么决定推荐书单的排序；第三，如果给所有人都推荐《三体》这样的书单，难免有些单调，而且我们也不能确定用户会喜欢《三体》这个风格的图书，所以就需要注意科幻小说书单的多样性。

这种情况就很像我们走进商场，跟售货员说：‘’我要买一个包包”，然后售货员直接给你介绍了三款最新流行的网红包，他们也不知道你到底喜不喜欢这个风格。

第三种情况下，我们并不了解用户使用图书推荐的目的，只能根据他以前的习惯进行推荐。 他以前喜欢过《哈利波特》、《百年孤独》，也喜欢过《从零到一》，涉猎广泛，那我们可以推荐的书就实在太多了，并且我们并不知道用户此时此刻想看什么。

用户刚进入豆瓣图书，可能只是想随便看看，或者找一本好书，或者找一个热销的书单，所以这时最重要的不是帮用户找到具体的某本书，而是要激发他们的兴趣，把他们引到更深层次的读书需求上，那就需要让他们多看看、多逛逛。

同样是逛商场的例子，我刚刚进入商场，应该是鼓励我多逛几个店，并通过明亮的灯光、热情的音乐等方式激发我的购买欲望，而不是在门口直接拦住我给我推荐一款笑脸包。

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

如何开启这个功能。

这个功能的流程图是什么样的，这是最重要的部分。

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

这个功能哪些部分可以使用已有的架构或者产品流，这样可以在已有基础上稍作修改，而不用重新开发，可以大大节约产品开发时间。 

比如， 豆瓣已经存在电影推荐和音乐推荐功能了，所以图书的推荐列表可以参照以前的产品流。

再比如，我们已经推出了让用户选择自己喜欢的音乐类型的功能，根据用户做的音乐类型测试的结果，向他们推荐音乐。同样的测试流程，我们可以直接应用在图书推荐上。

如果涉及到和其他组合作时，我需要先和其他部门沟通好，方便我们组开展工作。 

比如，我们这个功能会和其他组的产品功能在 UI 上有一些冲突，他们可能要修改“推荐”这个总菜单， 这个总菜单包含我们的图书推荐功能，那就需要在产品需求文档里面记录这个情况。

有些情况下这个功能可能无法达到预期效果，那么这时的解决方案是什么。

比如，用户没有任何图书浏览记录， 那我们可能就无法提供个性化的图书推荐， 这时我们要么随便推荐一堆书，要么直接导入畅销书单。

再比如，图书推荐的功能是通过分析用户看了图书 A 后还喜欢看什么书来推荐的，但是有些英文新书，这个功能会因为没有足够的资料而无法生成推荐， 这时我们需要告诉用户这本书不适用于图书推荐这个功能。

往往事先没有想清楚的地方都可能会出现问题，导致整个产品设计和开发都得从头来，这也是一个坑。

一个推荐系统经常会出现的问题是，重复推荐的现象。造成图书推荐系统重复推荐的原因，可能包括：不同出版社的同一本书，或者同一个出版社、同一个作家的 2014 年版、2015 年修订版、2016 年再版。如果一个书单里 10 本书，有 3 本是重复的，那体验就太差了，所以我们需要找到一个可以去掉重复书名的方式。

如果这个问题在之前数据提取的时候就已经考虑到了，那么我们训练的机器学习模型的结果就会比较准确。可是，如果事先没考虑到这个情况，那就需要在发现这个问题后，从头开始了。

比如，《爱的教育》这本书，有无数个版本（宝宝版、小学必读版、人生成长版、精编版、简化版），相关的推荐系统的数据就很容易分散。如果销量或者评论数是推荐系统的一个重要指标的话，那么本来《爱的教育》这本书所有版本加起来有 1 万条评论，但因为系统默认是不同的书，就导致每个版本的几百个评论在推荐系统的畅销排名都很低，所以这本书压根儿就不会出现在书单上。发现这个问题之后，就要重新处理数据、重新运行训练环境、更新畅销排名等工作，非常容易推迟产品的发布。

总结

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

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

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