产品经理PRD写作

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吧！

PRD一般指产品需求文档。产品需求文档是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。

该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然，这个定义针对的是一个全新的产品。

广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略是指：产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。

PRD的主要使用对象有：开发、测试、项目经理、交互设计师、运营及其他业务人员。

开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。

PRD是项目启动之前，必须要通过评审确定的最重要文档。

扩展资料：

产品需求文档的相关内容

1、文档意义

该文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。

2、文档撰写

在该文档中，基点依然是MRD中的内容，只是把重心放在了“产品需求”上，而产品需求本身是在MRD中有所体现的，区别就是在于，PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。

这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块）。

Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。

3、文档核心

该文档中，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。在一些国外的公司，是允许把MRD和PRD合并成一个文档的，通常叫做“Marketing & Product Requirements Document”。

-产品需求文档

什么是MRD 什么是BRD这些问题是在群里说到的；一个群友问到有没有PRD文档；当时看到这个信息时，可能会有很多群友们都在想：什么是PRD？那么接下来就为大家简单分享介绍PRD、MRD、BRD的含义。一、PRD的含义 英文简称，PRD（Product Requirement Document），PRD文档中文意思是：产品需求文档。 PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。二、MRD的含义MRD，英文全称Market Requirement Document，中文意思是：市场需求文档。 该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。 作用是：产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对年度产品中规划的某个产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。三、BRD的含义 BRD，英文全称为：Business Requirement Document；中文意思是：商业需求描述。 基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。BRD是产品生命周期中最早的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。四、PRD、MRD、BRD之间的关系 1、PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明，而产品需求本身是在MRD中有所体现的。 2、MRD侧重的是对产品所在市场、客户（client）、购买者（buyer）、用户（user）以及市场需求进行定义，并通过原型的形式加以形象化。 3、如果说PRD的好坏，直接决定了项目的质量水平；那么BRD的作用，就是决定了你的项目的商业价值。