PRD（Product-Requirement-Document，产品需求文档），是衡量一个产品经理整体思维的标准，一个PRD可以看出一个产品经理在某个领域的专业性，同时也可以反应出一个产品经理的整体产品思维。

产品经理的整体思维体现在：

1、提炼核心需求

2、思考满足核心需求的方式

3、评估方式优劣选定方案

4、思考功能概要

5、思考支撑功能和关联功能

6、细化设计功能

7、子功能（功能间迭代）

1、为什么需要写产品需求文档？

当我们从用户那里收集到需求后经过初步的市场调研、需求筛选和可行性分析后会将需求转化为一条条用户需求，而在产品经理的规划和分析下会对这些需求进行去重、归类然后转化为产品需求，形成产品功能列表也就是我们常说的（功能列表）Feature List。这时候我们需要将大大小小的功能点汇总成为一个产品并最终实现它就需要将我们的意图系统的表达给设计狮、程序猿，然而此时任何的表达不清或错误都会造成后续工作的无法进行或返工，因此产品需求文档应运而生。

所以对这种文档的判断要求也就变得清晰明了，第一要规范化的格式，不能一个项目一套文档标准，采用统一的规范可以在最大的程度上避免产品设计上的内容疏缺。第二则是要以程序猿、设计狮能理解的语言来描述，专业的术语不仅能减少分歧更能使产品经理给相关各方留下一个专业认真的形象，有利于团队的凝聚力。

2、产品需求文档包括的内容

（1）概述

概述部分是概括地说明产品背景，简述产品功能，预期实现的目标，分阶段实现的阶段性目标。

• 背景介绍：是基于什么样的考虑要做这个需求。

• 产品目的：解释说明该产品是干什么的，为什么需要这样的产品。同时产品想要达到什么样的目标。产品概述及目标就是对产品核心功能讲解，同时希望可以达到的期望。

• 产品（路线图）roadmap：产品分期目标，阶段描述，以及时间点的确定，产品是个不断演进的过程，很多时间一期产品只完成了产品70%的功能，二期才会继续去完善剩下的30%，同时有可能会推翻了重新推出第二版。产品roadmap并不及着全部规划好所有的阶段目标，而是更多的通过维护来保持产品的更新和迭代。

• 名词解释：声明文档中出现的名词含义。

• 数据词典：介绍本产品中数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等。

• 文档阅读对象：声明本文档输出的阅读对象和注意事项。

• 产品风险：描述产品可能存在的风险，比如商务谈判的风险，外部合作的风险，不当使用的风险等等。风险级别为高中低。

（2）产品描述

产品描述介绍用户使用产品的逻辑流程，概括性的描述产品需求、产品版本规划、产品整体的框架结构以及功能列表。产品整体流程与产品框架都需要使用相应的图表展现。

• 产品整体流程：展示产品框架图和用户流程图。

• 产品需求描述：描述产品核心功能，解决哪些情景下的哪些需求。

• 产品版本规划：叙述产品版本迭代计划，版本号、主要模块、功能点、计划开发时间、计划结束时间、备注。

• 产品框架：展示页面层级，展现产品框架中各一级页面、二级页面、三级页面及备注信息。

• 功能列表：展示产品功能名称、对应模块、功能说明、备注等信息。

（3）功能描述

功能需求这部分需详细描述产品所涉及的各个功能点。将整体框架拆成数个独立的功能点，分别描述每个功能点的逻辑流程图、界面、字段说明以及业务说明。统一采用Use Case的方式进行描述。

• 流程图

• 界面原型

• 字段说明（包括数据字典）

• 业务说明（Use Case）

（4）效果预期

做任何一个需求，我们都有明确的目的，有了目的还不够，我们应当根据产品的现状，对此次需求上线后的效果有一个预期，效果预期主要通过数据层面来体现。

有了效果预期，PDR的读者就知道在需求上线后，会对产品带来多大的变化和影响，在需求实施的时候，也能更全面的考虑各种情况。

（5）数据埋点指标

这部分跟上述效果预期相关联，有效果预期以后，需要有相应的指标来评判效果，因此，需要在PRD中将详细的数据指标列出来，以便研发对数据指标的提取进行埋点，以及后续数据提取。这部分和效果预期常常容易被忽略，等到需求上线了，才发现需要的数据没有，导致需求效果难以评估，后续的迭代也没有数据支撑。

（6）非功能需求

非功能需求，也就是关于产品的其它方面的要求。一般情况下非功能性需求包括以下几个部分：产品营销需求、规则变更需求、产品服务需求、法务需求、财务需求、帮助需求、安全性需统计需求、性能需求、可用性需求等。与其说是全方位的掌握技能，还不如说是沟通，如何与不同的部门人员之间的沟通，让更多的人协助产品的正常使用与上线。

（7）运营计划

说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户，产品经理是核心需求的把握者，参与到产品整体运营计划显得特别的重要。

（8）PRD迭代记录

这部分也是容易被忽略的一部分，尤其是核心的产品需求，在初版需求文档出来以后，没有后续的迭代记录，会导致产品迭代多个版本以后，不知道早期某些功能是如何考虑，又是如何一步步演变成今天这个样子。

PRD从第一版诞生以后，经过多次需求评审，设计评审，详细设计评审、用例评审，其中有许多细节，甚至页面布局、功能点都会有变化，当时可能都是通过邮件、会议纪要来说明，如果不整理到需求文档中，时间长了，或者是人员变化，可能就没有人知道这部分需求最终的实现方案了。

3、产品需求文档的撰写方法

做好产品需求文档的这十步，是经过长期的实践经验和反复验证而得到的，做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。

第一步：做好准备工作

你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。

建立良好的交流也非常重要，它会影响着产品团队。如果你的准备工作做的够好，你也会变得越来越有信心和说服力。

第二步：确定产品的目的

任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求，你的产品如何达到这个需求。

产品经理需要提出一个清晰、简明的价值主张，让它很容易被接受，要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。虽然这听起来很简单，但是也只有少数产品才有这样的价值主张。考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。假设你在做电梯的时候遇到公司CEO，他问你产品的意图是什么，你能在电梯到达之前回答这个问题吗？如果不能，你就还有工作需要做。也许是你的说明没有针对性，他可能表现出来和其他产品做的没有什么明显区别；也许你提出的观点不能和你的用户产生共鸣；也许你解决的是一个非常规的问题，可能你想应用一种技术。这个价值主张可能需要满足公司的产品战略。注意你不需要阐述太多的细节，从某些方面来说，一个有价值的观点应当是越简越好。

产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。例如，你的目标可能是：1）易用，2）零售价不足$100，3）和前期产品很好的结合。然后你需要说明如何去测算。对于“易用”这类项目，你需要明确指出产品可用性达到某个水平。这是通常用目标用户来定义。可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。

这里的关键就是让每个人都知道产品成功的时候是什么样，还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。

第三步：确定用户原型、用户目标和用户任务

现在你已经明白你想要解决什么问题，下接下来就要深入了解目标用户和顾客，在这步中，和你的PD（产品设计）紧密联系非常重要。

用户原型

在这个阶段，PM需要和很多用户交流，需要花费大量的时间去直接观察和讨论。现在我们需要对用户和顾客进行分类，然后决定那一类是我们的首要用户。

PM（产品经理）和PD（产品设计）需要首先确定类型是最重要的，然后尽量对这个用户群的特征进行详细的描述，以便使用这个模型去指导产品的设计。这个模型通常称其为“人物角色”。 虽然是想像的，但是应该是典型的、可行的和真实的，让你能够使用。这个想法来自与一个能代表这类用户的本质的原型。如果你不去精确的定位你的目标用户，你就只会存在模糊的概念，你会发现理解你用户的反应非常困难。你要倾向于设想，让你能更像你的用户。

用户目标（用户意愿）

一旦我们确定并描绘了我们主要的用户类型，我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单，但是解开根本问题是非常具有挑战性的，特别当你周围的人告诉你你已经解决了他们想要的。

从CEO、销售代表、工程师到客户，每个人都太兴奋而不能帮助你找到解决根本问题的办法，他们会告诉你在某个地方添加一个快捷按钮，或则添加一个功能仅仅是因为竞争对手有，或则是改变成他们喜欢的颜色。

最好的解决办法取决于清晰的了解到底什么问题需要解决，每个用户模型可能有不同的目的，需要在用户原型涉及的方面中进行寻找。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。

用户任务（tasks，用户为达到目标使用产品而需要做的任务）

掌握了用户原型与他们的目标愿望，我们就开始着手设计任务来满足他们的目标意愿，这是产品制作进程中最核心的部分，也是创造力和创新力被激发的地方。

许多优秀的产品仅是用更好更新的办法解决一个已有的问题，有时候这种办法仅仅是应用一个种新技术，但是大部分是来自深刻的见解而使一种新方法的产生。例如TiVo（美国市场占有率第一的数字录像机）在电视节目录制的老问题上面想出一个全新的办法，让顾客更加容易地实现他们的目标并且建立了电子设备一个全新的类别。

注意我们虽然谈到了目标和任务但是还没有谈到具体的功能，这些功能都需要达到用户目标而必须的。你以后会发现许多功能都是低优先级或则是完全多余的。

以“必须功能”这个理由可以排除很多功能。讽刺的是，你用越少的功能，你的产品被发现得越来越强大。这是因为产品的功能越少，你的用户就会发现并使用更多的功能，成功的使用越来越多的功能他们就认为你的产品非常强大。这些理由都是违反我们直觉的，我们大多数人都不能和我们的用户一样，我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。

第四步：定义产品原则

现在你需要开始把你的需求和用户体验定义成详细的要求。同时你仍然会面临着许多的决定和权衡，为你的产品标准作出最佳的决定是非常重要的。

在大多数的产品团队中，每个成员都有做好产品的原则，但很少有两个人有同样的想法，这些差异都会导致不可思议的结果。

尝试和制订一系列指导整个团队的产品原则是非常有价值的，这些原则需要具体到域名和项目。

第五步：产品原型和检验

这是一个拿出你想法的阶段，创造力和创新力拿出成就的地方.

很多人都容易犯一个常见的错误，他们对产品设计规范太有信心，结果一旦得到beta的测试他们就必须调整产品。但是肯定beta测试版并不是进行重大改变的时候，所以才会有许多首次发布的产品离目标太远。

对于许多产品来说，这个时候你可以用大量的原型做很多的实验。首先，下面的三个非常重要的测试你可能需要做

可行性测试

一个直接的问题就是产品是否可以开发，你的工程师和设计师应当介入技术的可行性调查和探索可用办法。有些办法是行不通的，但是有其他的办法可行是非常有希望的。

工程师会发现在产品的某个阶段不可能逾越，现在知道比以后知道要好。

可用性测试

产品设计师将要和你紧密工作共同提出产品功能，让它能适应不同的用户。可用性测试常常会找出遗漏的产品要求，同时确认产品最初的要求是否是必须的。在你拿出一个成功的用户体验之前需要多做一些测试工作。可用性的目的是在真正的用户身上测试，从产品目标用户得到质量反馈的测试是非常艺术和科学的。当然产品经理和产品设计将模仿使用，但是实际是没有人能取代真实的目标用户。

概念测试（Product Co