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

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

朗读人:丁婵    15′33′′ | 7.64M

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

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

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

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

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

明确产品需求文档的目的

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

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

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

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

第一,要解决什么问题。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. 如何开启这个功能。

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

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

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

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

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

总结

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

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

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

思考题

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

版权归极客邦科技所有,未经许可不得转载

精选留言

  • honggang

    写详尽的好处,哪怕不甚理解,也可以照着做;国内的对日外包是这种思路。
    在不少小互联网公司,资深的员工少,因为招不到或者付不起。尾部员工素质一般,也有靠非常详尽文档来保持理解一致。
    2018-05-19
    作者回复

    确实和员工素质水平有关系 我比较幸运啦 同事都给力

    2018-05-20

  • 陈小鹿
    我想请问一下,另外一篇文章中提到的用例use case,是否需要写在需求文档中?
    2018-07-09
  • DSY💎
    下面简要说下我的【设计思路】【文档涉及内容】【需要注意的点】,请晓音姐指正思考的方向是否正确。 【设计思路】 1、 为什么要做这个功能?结合产品定位和功能定位思考 2、 做这个功能能为用户、平台产生什么价值。 3、 产生这些价值可以通过怎样的方式实现 4、 怎么定义用户(即怎样定义粉丝)?根据定义做不同的策略。 5、 什么样的用户会在会在什么样的场景下使用这个功能?主要的用户路径有哪些? 【文档涉及的内容】 1、 需求背景(为什么要做这个、解决的问题有哪些) 2、 数据支撑及相关调研内容 3、 功能的详细逻辑及页面、策略说明 4、 衡量指标 【需要注意的点】 1、互动是否需要引导?怎么做引导? 2、功能上线后数据没有达到预计应该怎么处理?
    2018-05-25
    作者回复

    方向很明确 很棒!

    2018-05-29

  • 个人认为,微信产品在创立之初,就秉承着以线下熟人关系链为主的聊天平台,所以微信不会在像qq一样容易被取代,因为对于用户来讲,抛弃微信,就等于抛弃了自己的朋友,成本太大,使用微信,也是因为不会容易被陌生人打扰,如果要和明星互动,这就等于明星的部分隐私会被他人所获取,但微信的壁垒就在于线下熟人的交流,所以如果我是明星,我宁愿选择头条微博,而非用微信,这会威胁到我自己的隐私,所以我认为这是个伪需求,当然这也需要数据支撑,需要去调研
    2018-05-21
    作者回复

    qq取代性这一点很有见地👏🏻

    2018-05-22

  • Iris.Guo
    能分享一些文档供参考吗
    2018-07-20
  • 徐东鹏~种下一朵太阳花
    微信公众号的定位是博客系统,本质上是产生内容,功能上也与普通的博客系统的订阅、留言、更新推送没有本质区别。但在微信体系下,由于微信的高日活及社交、传播能力,一切都变得不一样了。
    如果我来做,增加明星和粉丝互动的玩法,首先我不会改变公众号自身的定位;其次,互动一定是要有内容沉淀的。最后,玩法一定有较高的自主选择及可扩展性的。
    我会选择用小程序来做,通过小程序与粉丝互动、获得新粉丝。比如做直播,具体玩法是 让粉丝在文章下方留言、明星可以选择某个文章集中讲解和答复问题,在线互动等。视频内容会通过微信公众号直播小程序(就叫公众号直播吧)让更广大的微信用户看到,公众号粉丝也会第一时间收到推送。往期的直播内容也会关联文章,在公众号中显示。

    我的需求文档会包含:1、项目背景介绍及要解决的问题(通过公众号直播增强互动,沉淀内容)。 2、玩法流程图,内容分发流程;3、功能清单及定位,预期标准;4、功能需求说明及原型图示。
    2018-05-27
  • yuyu
    首先这个痛点应该是存在的,参比微博粉丝偶像的互动,微信公众号现有的方式更加封闭一些。建议在现有微信公众号的基础上增加额外的功能,比如用户可以选择偶像发布的公众号出现在朋友圈,类似于广告位。有共同偶像的朋友圈好友都可以参与互动。
    正指标可以是1用户选择开通这一功能比例2针对偶像内容评论数。负指标可以是原有公众号关注度或评论数降低。
    总之要和工程师沟通清楚,这一功能的出发点就是让用户和偶像的互动能更直接,便捷。
    也考虑过要不要让所有朋友圈好友都能看到自己的偶像,好处是能吸引更多人关注,坏处是会被不感兴趣的人当广告对待。最好可以让用户自行选择。当然这些也需要通过测试来验证。
    2018-05-20
  • Iris.Guo
    其实就是想系统的学习一下所有文档的撰写,看完作者的系列篇,感觉对于我还是纸上谈兵
    2018-10-15
  •  宝小萱
    1.要解决什么问题
    用户想要和公众号偶像互动的问题
    2.论证这个痛点到底是不是存在
    可以看文章阅读数和点赞数数是否成正比(相关性)想要留下痕迹和只是阅读
    做用户调研、问卷
    3.写清楚这个功能的成功指标和反指标
    成功指标:进入公众号/文章日活增加、用户停留时间变长
    反指标:阅读文章篇幅变少,明星内容变少,互动区不好管理
    4.讲清楚要解决的用户场景
    在阅读公众号文章之后,增加评论功能,作者可以回复读者问题
    5.解释清楚产品功能方案
    如何开启这个功能
    读文章后
    这个功能的流程图是什么样的
    主动进入文章/分享进入-读文章-发表评论-回复推送-查看回复-回复/看其他
    这个功能哪些部分可以使用已有架构或者产品流
    朋友圈回复
    合作前的沟通
    无法达到预期时,解决方案是什么
    2018-08-07
  •  宝小萱
    新增:
    1.通过广告营销、赞助综艺节目,让用户感兴趣下载
    2.网红、KOL
    3.页面用于添加好友,可从通讯录、QQ、微信、微博添加好友
    留存:
    生产者:
    1.合理分发机制,让新用户有足够的曝光次数
    2.简单的制作方式让用户更多的去生产
    3.挑战、模版让用户制作成本更低
    4.水军点赞
    5.教学视频
    内容消费者:
    1.推荐算法给消费者推荐感兴趣的内容,来增加用户的消费时间 2.简单的上下左右操作,让用户更简单、更加不用思考的方式停留
    挽回:
    2018-08-07
  • luna
    我把我的需求文档当作产品来对待,我的用户就是需要沟通的开发测试和设计师,我的产品的成功指标就是沟通完第一遍需求之后,他们找我再次确认需求的次数,再次确认次数越少,代表我的文档描述越清晰精确逻辑无漏洞。而且有必要的时候,还会在文档上写出简单的数据分析作为这个功能需要实现的论据。该功能上线后,如设立的目标已达到,也会和参与的人员分享这个战果,鼓舞一下士气。
    2018-07-21
  • luna
    刚讲漏了一点,其实内测遇过版本重点功能内测期间实现效果和想象中差太远的,需要重写需求或代码时,则需向项目负责人尽早确认延期发布及延长内测时间
    2018-07-16
  • 类似给主播唱歌打分这个功能到底有没有必要,项目经理跟产品经理经常会吵得不欢而散,这种情况很多,而且没有条件去做市场调查得到一个论证结果。在我们这种小团队里,功能齐全与实用好像一直都是他们的矛盾,其实文章中说的很多要注意的地方大家都懂,也都遇到过,只是没有好的解决办法
    2018-05-28
  • Lisa
    请问,什么是产品流?
    2018-05-24
    作者回复

    产品流程。第一步第二步第三步

    2018-06-01

  • 剪影
    哈哈,问题是不是回答了文中唱歌打分的设计初衷;包括互动的方式,时间点,内容,程度,成败指标(怎么挖掘客户在使用过程中想要的优化?)
    2018-05-19
  • 剪影
    问题是不是回答了文中,唱歌打分的设计初衷? 互动方式,内容,程度,达到的效果,成败指标
    2018-05-19