PRD是什么？
可以说，产品经理最重要的工作就是跟团队说清楚需求，只有说明白了需求是什么，才能让开发、设计、测试等去进行后续的工作。PRD是产品经理说明需求的不二选择。
什么是PRD？
PRD，产品需求文档(Product Requirement Document，PRD)的英文简称，这是一个产品经理为了跟其他项目成员说明需求的重要文档，也是PM参加需求评审会时，你的成果作品。
你可能还不知道需求评审会是什么，那我就简单讲一讲。需求评审会就是产品经理提出需求跟大家PK，让大家评估产品经理提出的需求，然后决定后续工作的会议。几乎所有的开发、设计、测试都会有忙不完的活，你凭什么让他们把你的需求优先开发，这将严重考验你和你的PRD。如果搞不好，你会被开发、设计、测试从头到脚批一遍，那个场面，就像在直播吃翔。
至于为什么会搞不好，很大程度就是产品经理没有把需求的各方面思考清楚，哪怕有一个逻辑没有思考清楚，或者漏掉了某个步骤，团队的其他人就会向你投来怀疑的眼光。如果一次评审会议中你被多次怀疑，那么不用想了，你就是在直播吃翔。
PRD是给谁看的？
首先，PRD是给产品经理自己看的。产品经理提出一个需求，那么实现这个需求的功能、逻辑，通过书写PRD的过程，能够慢慢梳理出逻辑。有人说：”我做高数微积分题全用心算完成，你那些功能、逻辑，我都能想得清清楚楚”。
其次，PRD是给团队的其他人看的。一个产品经理，即便能够在脑海里想清楚所有的功能、逻辑，但是他不能保证团队的其他人也能在头脑里想清楚一切逻辑。所以，产品经理需要通过输出PRD，让团队其他人员理解需求的逻辑。
再次，PRD也是给老板看的。产品经理需要做某一个产品，在跟老板申请资源的时候，给出一份清晰的PRD能够让老板看明白你到底要做什么。
你知道PRD有多重要吗？
PRD的重要性，怎么夸大都不过分。
首先，PRD有证明需求的作用。你口头跟开发、设计、测试说一个需求，他们可能也口头上答应帮你做。然后，可能就真的没有然后了。。。接近项目上线，你突然发现他们没有做你的需求，这时你再去找他们，他们完全可以说你没有提出过需求，那场面，直接就是在吃翔。所以，产品经理需要认真写一份PRD，通过需求评审后，邮件群发给开发、设计、测试等大爷，有文件留底，到时候他们就赖不掉了。
其次，PRD有证明PM的作用。很多公司将PRD的修改次数作为作为评判PM水平的标准，还可能作为PM升级评定的参考因素。如果一个产品经理写的PRD平均修改次数过多，那将严重影响升级评定。
PRD闭环
做产品无时无刻都需要思考产品闭环的问题。PRD作为需求的说明书，更是需要体现产品闭环。完成下面的步骤，你就能够写出一份优质的PRD了。
你的目的是什么？
这个是一份PRD最重要的地方，其实做一个产品，或者实现一个功能/逻辑，都不是困难的事，但是你得想好为什么要做这件事，或者说，你要确定做这件事所获得的东西是不是你自己想要的。这个问题想不清楚，后面的都是白搭。比如，你准备做一个游戏活动页，本来目的是为了拉新，但是目的没有把握好，后面做成了留存，那么你的KPI很可能就“呵呵”了。
实现目的所需要的功能？
在目的已经清晰、明确的前提下，PM得好好思考实现该目的所需要的功能，这些功能是实现目的的必经之路。最好给出功能列表，一个功能点都可以单列一条，并且和测试用例一一对应。
还可给出功能的应用场景，方便团队其他人理解该功能的作用。比如，一个简单的用户在某活动页兑奖的情景：
用户在购买某服务后，得到兑奖网址
用户输入该网址后，弹出活动页
用户点击“领取奖励”按钮，页面弹出注册/登录框，用户输入账号密码，登录成功，领取奖励
列出了功能点后，还需要对功能列表里的功能进行排序，得出优先级。暂时不做的需求，也要事先提出，放入需求池。
完成功能需要的逻辑？
这部分其实就是将功能分成很多小的功能点，比如一个兑奖的功能，可以分拆成注册、登录、第三方登录等小功能点。实现了每个功能点的逻辑，就组成了整个兑奖功能。
这部分，我感觉是实现产品体验的最重要阶段。实现一个功能的逻辑，如何做到让用户使用起来不复杂，同时能够让开发工作量不要太大，同时还能让大部分情景能够正常触达正确的结果，这不是一件简单的事。
异常逻辑、危机处理？
大部分用户能够正常使用功能后，就需要思考一些异常逻辑和危机情况了。这一部分非常考验产品经理的逻辑思维，从深度、广度两个方面全面考验。这一部分也最容易被团队其他人发现逻辑漏洞，分分钟让你感觉在直播吃翔。所以，这一块大家要加把劲，争取想出每一种异常逻辑，做好危机处理。
还是以兑奖活动为例子说明，一个兑奖活动页，目的是为了让某客户端装机量上升，那么必须设定该活动页必须在该客户端中输入，才能跳出兑奖网址（该客户端带浏览器功能）。那么异常逻辑可能就有：
用户不在客户端里输入网址
用户在断网情况下在客户端/其他浏览器输入网址
用户超过活动时间后才输入活动网址
…………
争取需要的资源
完成上面的步骤后，就需要跟项目组要资源了。
项目成员：完成产品开发工作所需的程序员（前端、后台、运维等），设计师（交互、视觉），测试，运营，商务等。
硬件资源：服务器，宣传物品等
数据反馈
这部分也是非常重要的，你做出了一个产品，肯定是需要知道它的市场反馈如何，得到反馈后，才能决定下一步该怎么走。这里就需要设计数据反馈系统，订立考核指标。
访问量
转化率
留存率
用户活跃天
产品收入
任务、活动完成量、质量
完成以上步骤，一个完整的PRD闭环就做好了，这下子，可以去找其他人PK了，做得足够认真的话，应该就不用直播吃翔了，可以挺直腰板当大爷了。这个世界就是一个“要么你是大爷，要么我是大爷”的世界，各位还是争取自己当大爷吧。
注意事项：坑，还是很多的
这部分说明一下具体写PRD时，需要注意的事项。
换位思考
写PRD一定要时刻想着换位思考，你得想着你的文档是给开发、设计、测试等看的，语言上尽量好理解，尽量不要用形容词，描述功能时，可以尝试用开发的逻辑去思考书写方式。
不要求大求全
这部分是我踩的一个深坑，我之前总想着把所有的逻辑都整理在一个流程图上，然而这在很多情况下是不可能的，除非你做的这个产品比较简单。即便你真能够将所有逻辑整理在一个流程图上，那么这个流程图也会很复杂，不容易让团队其他人看懂。功能最好分点说明，正常逻辑和异常逻辑分开说明。
所见即所得
这是一个读图的时代，图片展现是最清晰明白的。有的功能点，逻辑比较复杂，这时可以考虑用原型图展现，原型图可以做到所见即所得。
实现进度如何？
在PRD之外，最好再做一个项目进度表，这份表格要做到及时更新，让整个团队知道项目的进度。
关于语病和错别字
一份优质的PRD，最好达到新闻稿的校验程度，基本不要有语病和错别字。语病和错别字太多的话，容易让大家觉得你很不严谨。
排版标准
排版一定要有一套标准，保证你的每一份PRD都按照同一份标准。排版力求美观大方，字体、颜色、字号、行间距等方面都需要有一定的选择。
好了，以上基本将PRD的理论知识介绍了一下，我所说的，可能都是错的。说了那么多，其实PRD的作用就是让其他人帮你干活。一个极致的情况，模仿全栈工程师，我提出一个“全栈产品经理”的概念。当一个产品经理强悍到精通策划、前端开发、后台开发、设计、测试、运营、商务等，那么这种人我称Ta为“全栈产品经理”。
如果你是全栈产品经理，那么上面我说的关于PRD的东西可能对你来说都是垃圾，你自己就能做完所有的事情，请你务必要加我微信，让我膜拜你一圈。但即便你是全栈产品经理，能一个人完成所有工作，但是完成时间肯定会很长，效率肯定会下降。所以，广大PM兄弟姐妹们，咱们还是老老实实写PRD吧！
