需求文档作为产品经理的基本功，其重要性不言而喻，那么如何写好需求文档呢？作者分享了自己的一些心得。 提到需求文档，不少人认为写需求文档就和写论文一样，只要按照模板顺下来就可以了，还有人认为只要把问题说明白就好，写不写需求文档就是一个形式：与其写PRD，还不如写测试用例。那么，PRD是产品经理最底层的技能吗？是不是会写就达到要求了？产品经理应该将一部分精力放在完善PRD上吗？还是像不少人认为的将这些完善的时间用在跟进进度等更实际的工作上？ 下面我将就一下几个方面和大家聊聊什么是需求文档，为什么我建议产品经理要将写好需求文档作为工作要求。 需求文档（ProductRequirementDocument）是什么； 需求文档的使用对象有哪些； 写好需求文档分几步；（干货在此） 需求文档是什么 需求文档，ProductRequirementDocument，简称PRD，就是对产品的说明文档。 这里要说明的是，需求文档的说明对象不只是限于产品的功能。产品文档不仅要告诉别人你要干什么，还要说明为什么这么做，你的目标是什么，验收标准是什么，如何不能一步到位，是否有分步的实现路径。 第一，你要干什么，就是说明产品的功能边界。要新增某个功能？或者改变原功能？最好能用简洁的一句话来总结你要干什么，比如，在某产品内新增发红包功能。 第二，为什么这么做，就是要明确新增或改变功能的原因。这个问题与产品经理对产品的定位和策略有关，建议将原因量化到你的KPI上，比如，新增发红包功能的目的是提高与用户的互动程度，以提高用户粘性。 第三，产品目标是什么，就是在团队中建立共同目标。共同目标对团队而言是非常重要的问题，后续你的研发、运营、测试、项目等都要围绕产品目标开展工作。比如，本阶段某产品的目标是将用户粘性提高至X。建议设定目标时，要具体化到某个指标某个数字。 第四，验收标准是什么，就是要量化细化产品的验收指标。建立验收标准有助于后续走查，同时也能告诉团队要做到哪一步。和产品目标相比，验收标准是具体到某个版本某个阶段的短期指标。因为很多时候，某个产品目标的实现需要分拆到不同的版本，你需要为团队建立每个版本一步一步的验收标准。 假如设计的产品功能负责，涉及系统性的迭代，可以将大的迭代拆分成更小的更新步骤。分步的实现路径就是说明大的目标是什么，通过几个版本的迭代，要达到整体的效果是怎样的，为了实现这种效果，每个版本要做什么事等。 需求文档的使用对象 很多产品经理把写需求文档当做作业或者存档，总以为按照模板写完就可以了。尤其是大公司，成熟的团队一般都会有PRD模板，在这种情况下，不少人会有填充型的思维：反正我按照模板写完也不会落什么内容，何必自己再搞一份呢？ 不管是新人还是老手，我不推荐直接复用模板。因为需求文档是基于公司面向研发的。之前我的mentor和我说过一句话，我觉得非常在理。将需求文档也当做是你的产品，从整个角度出发，从实际的使用者的角度出发去构想你的PRD要写什么，怎么写。 首先，需求文档的使用对象是哪些人呢？ 第一，研发人员。这也是需求文档的主要使用者。需求文档就是产品和研发沟通的工具。作为一个过来人，踩过不少口头协议达成却扎在需求文档细节上的坑，我从中学到的最大的教训就是，作为一名合格的产品，永远不能将口头协议作为验收标准，不仅出了问题说不清，而且也不利于后续产品的继承以及复盘等。关于产品，要以需求文档为准，当然这也非常考验产品经理对框架的认知和对细节的把控力，以及对可能的风险的预知以及防御能力。一份优秀的PRD，不仅能和研发说明产品要干什么，要实现什么功能，而且也得交代清楚交互的逻辑和跳转的逻辑是什么以及每种情况下的托底逻辑。 第二，项目经理以及项目其他成员。这里可能不同的公司会有不同的情况，整体来看，作为产品的leader，建议产品经理及时和项目组成员同步关键的项目进展，同时产出关键节点上的各种文件，这里面最重要的就是PRD。 第三，产品经理本身。首先，验收研发交付的产品时，要以需求文档为准，不要过分相信自己的记忆能力，其次，强烈建议定期复盘，找时间看看自己写的历史文档，再回顾下每个版本出了哪些bug，想想是否对风险有预期，如何避免类似的bug，后续如何改进。这一点，对于产品经理的成长而言至关重要。 写好需求文档分几步 那么，如何产出一份优秀的需求文档呢？ 第一步，明确产品目标及框架。 其实在动手开始写PRD之前，就应该对产品的目标及框架有成型的方案。如果写的时候还不清楚自己到底要设计一款怎样的产品，一定要停下来梳理清楚。 第二步，拆分产品目标至版本，制定产品roadmap。 如果产品目标本身设计得比较大，不能一个版本内完成迭代，可以拆分至不同的版本，这时候，产品经理要制定产品roadmap，也就是每个版本做什么事。 第三步，建立自己的模板。 如果是老手的话，一般都会有自己熟悉和擅长的表达方式，可以根据上述两个点对格式进行删减更改。 如果是新人的话，建议先按照产品的目标和功能用mind画一下每个模板的关键点，尽量列出来，先不用想着各个点之间的关系，列完之后再分类，比如可以按照前后端分开，其次，将自己作为小白用户完整的过一遍流程，要注意用户的分叉点，走到这一步，接下来怎么走，这样走会遇到什么问题等。 第四步，按照你喜欢的方式开写。 想清楚上面的这些问题，就可以开始写了。有的产品习惯有完整的时间一次完成，有的产品碎片化写作也没有关系，总之，你喜欢怎么写，就怎么写。不要纠结于一次完成还是多次完成。因为我在工作中，发现有的新人经常会有这样的抱怨：根本没有完整的时间写PRD。其实这个问题很简单，要么你适应碎片化的工作方式，要么你学会管理出完整的时间。 第五步，复读PRD。 这个方法是我自己总结的一个小窍门，可以很好地查漏补缺。写完之后，不要马上发给研发，可以先换个脑子，然后自己复读一遍，不要遗漏每一条用户的路径，也要注意各种细节，托底逻辑是什么，用户会不会有各种奇葩的操作，等等。 最后的最后，个人认为，写好需求文档是产品经理技能中最重要的一块。因为产品经理最主要的输出就是PRD，需求文档的质量是产品经理水平的直观体现。 另外，这里有一份硅谷产品经理组的关于如何写好PRD的资料，供各位参考学习。（https：svpg。comassetsFilesgoodprd。pdf） 相关阅读： 产品基本功系列（一）：资深产品经理是如何分析页面的
