产品基本功系列(二):如何写好需求文档?

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

需求文档作为产品经理的基本功,其重要性不言而喻,那么如何写好需求文档呢?作者分享了自己的一些心得。

提到需求文档,不少人认为写需求文档就和写论文一样,只要按照模板顺下来就可以了,还有人认为只要把问题说明白就好,写不写需求文档就是一个形式:”与其写PRD,还不如写测试用例”。那么,PRD是产品经理最”底层”的技能吗?是不是“会写”就达到要求了?产品经理应该将一部分精力放在完善PRD上吗?还是像不少人认为的将这些完善的时间用在跟进进度等更”实际”的工作上?

下面我将就一下几个方面和大家聊聊什么是需求文档,为什么我建议产品经理要将“写好”需求文档作为工作要求。

  • 需求文档(ProductRequirement Document)是什么;
  • 需求文档的使用对象有哪些;
  • 写好需求文档分几步;(干货在此)

需求文档是什么

需求文档,ProductRequirement Document,简称PRD, 就是对产品的说明文档。

这里要说明的是,需求文档的说明对象不只是限于产品的功能。产品文档不仅要告诉别人你要干什么,还要说明为什么这么做,你的目标是什么,验收标准是什么,如何不能一步到位,是否有分步的实现路径。

第一,你要干什么,就是说明产品的功能边界。要新增某个功能?或者改变原功能? 最好能用简洁的一句话来总结你要干什么,比如,在某产品内新增发红包功能。

第二,为什么这么做,就是要明确新增或改变功能的原因。这个问题与产品经理对产品的定位和策略有关,建议将原因量化到你的KPI上,比如,新增发红包功能的目的是提高与用户的互动程度,以提高用户粘性。

第三,产品目标是什么,就是在团队中建立共同目标。共同目标对团队而言是非常重要的问题,后续你的研发、运营、测试、项目等都要围绕产品目标开展工作。 比如,本阶段某产品的目标是将用户粘性提高至X%。建议设定目标时,要具体化到某个指标某个数字。

第四,验收标准是什么,就是要量化细化产品的验收指标。建立验收标准有助于后续走查,同时也能告诉团队要做到哪一步。和产品目标相比,验收标准是具体到某个版本某个阶段的短期指标。因为很多时候,某个产品目标的实现需要分拆到不同的版本,你需要为团队建立每个版本一步一步的验收标准。

假如设计的产品功能负责,涉及系统性的迭代,可以将大的迭代拆分成更小的更新步骤。分步的实现路径就是说明大的目标是什么,通过几个版本的迭代,要达到整体的效果是怎样的,为了实现这种效果,每个版本要做什么事等。

需求文档的使用对象

很多产品经理把写需求文档当做“作业”或者“存档”,总以为按照模板写完就可以了。尤其是大公司,成熟的团队一般都会有PRD模板,在这种情况下,不少人会有“填充型”的思维:反正我按照模板写完也不会落什么内容,何必自己再搞一份呢?

不管是新人还是老手,我不推荐直接复用模板。因为需求文档是基于公司面向研发的。之前我的mentor和我说过一句话,我觉得非常在理。“将需求文档也当做是你的产品”,从整个角度出发,从实际的使用者的角度出发去构想你的PRD要写什么,怎么写。

首先,需求文档的使用对象是哪些人呢?

第一,研发人员。这也是需求文档的主要使用者。需求文档就是产品和研发沟通的工具。作为一个过来人,踩过不少口头协议达成却扎在需求文档细节上的坑,我从中学到的最大的教训就是,作为一名合格的产品,永远不能将口头协议作为验收标准,不仅出了问题说不清,而且也不利于后续产品的继承以及复盘等。关于产品,要以需求文档为准,当然这也非常考验产品经理对框架的认知和对细节的把控力,以及对可能的风险的预知以及防御能力。一份优秀的PRD,不仅能和研发说明“产品要干什么”,“要实现什么功能”,而且也得交代清楚“交互的逻辑和跳转的逻辑是什么”以及“每种情况下的托底逻辑”。

第二,项目经理以及项目其他成员。这里可能不同的公司会有不同的情况,整体来看,作为产品的leader,建议产品经理及时和项目组成员同步关键的项目进展,同时产出关键节点上的各种文件,这里面最重要的就是PRD。

第三,产品经理本身。首先,验收研发交付的产品时,要以需求文档为准,不要过分相信自己的记忆能力,其次,强烈建议定期复盘,找时间看看自己写的历史文档,再回顾下每个版本出了哪些bug,想想是否对风险有预期,如何避免类似的bug,后续如何改进。这一点,对于产品经理的成长而言至关重要。

写好需求文档分几步

那么,如何产出一份优秀的需求文档呢?

第一步,明确产品目标及框架。

其实在动手开始写PRD之前,就应该对产品的目标及框架有成型的方案。如果写的时候还不清楚自己到底要设计一款怎样的产品,一定要停下来梳理清楚。

第二步,拆分产品目标至版本,制定产品roadmap。

如果产品目标本身设计得比较大,不能一个版本内完成迭代,可以拆分至不同的版本,这时候,产品经理要制定产品roadmap,也就是每个版本做什么事。

第三步,建立自己的模板。

如果是老手的话,一般都会有自己熟悉和擅长的表达方式,可以根据上述两个点对格式进行删减更改。

如果是新人的话,建议先按照产品的目标和功能用mind画一下每个模板的关键点,尽量列出来,先不用想着各个点之间的关系,列完之后再分类,比如可以按照前后端分开,其次,将自己作为小白用户完整的过一遍流程,要注意用户的分叉点,走到这一步,接下来怎么走,这样走会遇到什么问题等。

第四步,按照你喜欢的方式开写。

想清楚上面的这些问题,就可以开始“写”了。有的产品习惯有完整的时间一次完成, 有的产品碎片化写作也没有关系,总之,你喜欢怎么写,就怎么写。不要纠结于一次完成还是多次完成。因为我在工作中,发现有的新人经常会有这样的抱怨:根本没有完整的时间写PRD。其实这个问题很简单,要么你适应碎片化的工作方式,要么你学会管理出完整的时间。

第五步,复读PRD。

这个方法是我自己总结的一个小窍门,可以很好地查漏补缺。写完之后,不要马上发给研发,可以先换个脑子,然后自己复读一遍,不要遗漏每一条用户的路径,也要注意各种细节,托底逻辑是什么,用户会不会有各种奇葩的操作,等等。

最后的最后,个人认为,写好需求文档是产品经理技能中最重要的一块。因为产品经理最主要的输出就是PRD,需求文档的质量是产品经理水平的直观体现。

另外,这里有一份硅谷产品经理组的关于如何写好PRD的资料,供各位参考学习。(https://svpg.com/assets/Files/goodprd.pdf )

相关阅读:

产品基本功系列(一):资深产品经理是如何分析页面的

 

本文由 @时雨 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自PEXELS,基于CC0协议

祝给予赞赏的伙伴,2017年发大财!
5人打赏

评论( 14

写下你的想法
  1. 不会做交互设计的产品经理不是一个好用户研究员。

    看每篇文章的评论,总是有喷人的。说别人写的烂的人,不见得他写出什么好文章。
    支持一下作者!

    回复
    1. 回复

      对。如果是真心想给提建议,我相信大多数人都会接受。如果是超级牛逼,喷就喷了。不赞成没有水平的喷。 :oops:

  2. 是,我领导也是,产品思维就是这样逼出来的。。

    回复
  3. 有一点很有意思:产品经理要以产品思维写PRD。我领导中午吃饭都用产品观分析这家小店怎么才能火起来。。。

    回复
    1. 回复

      我领导也是,产品思维就是这样被逼出来的

    2. 回复

      哈,我领导还一个论点比较有意思,所有吸引用户的产品都离不开七宗罪里的欲望,所以切入点就找到了

  4. 你好请问什么是交互逻辑和跳转逻辑

    回复
    1. 回复

      第一,交互逻辑,举个例子,用户点击某个button之后,你设计的交互动作是什么?弹窗?还是跳转到下个页面?类似。第二,跳转逻辑,接着上面的例子,点击弹窗后跳转至某个页面,需要注意的是,要考虑完整的情况,比如用户点击弹窗的时候, 如果这时候网络中断了,就要跳转到异常页面。

  5. 一只产品路上前行的狗,阳痿定要睡林允儿

    太鸡巴恶心了,还搞分因为,直接给个模板,会死啊,

    回复
    1. 回复

      看起来您有很好的模板,建议和大家分享一下。

  6. 差 文章

    回复
  7. 十五以上年连续创业者,注册经营过2家公司,从0到1.持续盈利

    1、其他口水话不评论,最后那个硅谷?难道互联网我们还是要膜拜硅谷之类? 学习融合,发展那是国内互联网人独一份。

    回复
    1. 回复

      您过分解读了,我并没有说膜拜硅谷。如果您有更好的经验可以和大家分享。

    2. 回复

      你给个每个回复你的都有解释,服,继续你的风格。

推荐阅读