BRD：Business Requirements Document，商业需求文档。

BRD指的就是基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。BRD是产品生命周期中最早的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。

好的BRD应有的特点：商业价值、资源评估、风险和对策三大块是一个BRD最重要的三部分。好的BRD应当有煽动性、导向性。在写BRD时应当充分考虑阅读人（通常是老板）的出身背景、知识结构及思考问题的一般方法，考虑到他在看了BRD后会有什么反应，他是怎样考虑的，而不是仅仅是将要表达的结果做一个简单的信息传递，应当做到未雨绸缪。通常要做到这种程度，需要很深刻的了解公司的高端愿望，在企业里做到信息对称，高端愿望解码正确。当然，如果写BRD的人在公司对老板的影响力非常大，也会对BRD增色不少。

BRD文档通常包括：项目背景、商业价值、功能需求描述、非功能需求描述、资源评估、风险和对策。

项目背景：我们在哪里？为什么要做这个项目？解决什么问题？可以列出一些数据说明项目的必要性。
商业价值：我们去哪里？最关键的重点！做了这个项目以后有什么价值？一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。
功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打包好的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会高点技巧性的东西，比如要砍掉的需求，俗称李代桃僵。
非功能需求描述：提一下重要的非功能需求。
资源评估：达成项目的目标需要多大的花费。
风险和对策：项目中可能存在的风险及应对策略。

BRD技巧：通过一系列的市场分析或调查，掌握到了一个潜在的、未被满足的大量用户需求，而这些需求背后将映射着一个广阔的市场空间。说明这个项目很有价值（社会价值——造福全人类？；商业价值——未来的赢收主体？；用户价值——引领用户潮流？比如说Iphone；市场价值——也许明年我们的市场份额就会扩大一倍；投资价值——我们将全面进入一个新兴的领域）。写BRD，不应该站在自已的角度来写这份报告，充分了解决策层，也就充分把握到了报告编写的要点。站在评审方的角度来写报告，你的报告成功的可能性就已经占了很大一部分了。

BRD实例：

让我们假设你的公司正在开发一个用户关系管理系统（CRM）。这个系统是协助其他公司的销售经理如何跟进产品销售过程，并分析得出关于销售的靠谱的预期的。那在这种情况下我们的BRD应该怎写呢：

A. 谁会面对这些问题？——世界五百强的销售经理。

B. 他们面对的时什么问题？——1.无法实时的查看交易进行状态；2.无法分析出一个可信赖的销售预期。

C. 建议的解决方案是什么？——创建一个基于页面的系统，能够查看实时交易进行状态，并分析出一个可信赖的销售预期。

BRD与PRD的差异

BRD不同于常见的MRD（Market Requirement Document-市场需求文档）和PRD（Product Requirement Document-产品需求文档），既然是用于产品实施之前的决策评估依据，必然对其文档（报告）的内容和格式要求够直观、精炼，要点突出。作为报告的撰写者，你必须让高层明白，你的报告中将展现出怎样的商业价值，如何用有力的论据来说服企业对你这个项目的认可，并为之慷慨的投入研发资源及市场费用。如果说PRD的好坏，直接决定了项目的质量水平，那么BRD的作用，就是决定了你的项目的商业价值。优秀的BRD文档，可以让决策层充分被你的报告观点所吸引，或许财务主管会因为报告呈现的低投入高产出的经济效益预测而蠢蠢欲动；或许技术主管会因为项目的牵涉面广泛而头疼不已；又或许公司的VP之流因之报告而看到了未来一年业绩的飞速发展的广阔前景。

说白了，BRD需要产品经理（产品设计师）像对待PRD一样，充分应用市场调查、用户研究、需求分析等各种设计手段来充分阐述报告的内容。基于这样的状况，显然不是给大家一份完整的BRD标准格式规范，就能够搞定一切的！哈，也许有人会说这有点危言耸听，不过我一向赞成，面对一切“产品”，都应该用设计的眼光看待它。你应该把决策层当作你的产品——BRD的受众群体，一切从这里开始。

MRD：Market Requirements Document，市场需求文档。该文档在产品项目过程中属于“过程性”文档。

该文档是产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。

MRD要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。

MRD就是对产品所在市场数据的整合，说白了，就是对市场分析后的结论体现，在这个文档中，需要体现的主要内容包括：

1、市场的问题和机会

在这个主题中，主要是要求产品管理者说明自己负责的产品现在所处的市场都有什么问题和机会、面对这个现实的市场，产品有什么问题和机会，以及产品所需技术面临的问题和机会。其实就是要求从市场层面、产品层面、技术层面来阐述问题和机会。

2、市场特征

在这个主题中，主要是要求产品管理者说明目标市场的现状和趋势。应该包括的信息有：目标市场特征、目标市场趋势、目标市场细分、目标市场时间约束。

3、用户特征

这里的用户是个广义的概念，它其实包括两个方面的信息：1、客户（customer）；2；购买者（buyer）。在这个主题中，主要是要说明这产品的目标用户的特征、细分、动机、影响因素以及用户期望（目标）。

4、使用者特征

之所以把这个主题独立出来，就是因为，无论什么产品，最终是要由具体的人来介入的，这类人才是产品的最终享受者，具体到产品上，其实我们日常分析的产品需求和功能都是基于他们考虑的。在这个主题中，要说明这类用户的特征、现实需要和相关联系。

5、市场的需求

就是把市场需求按类别描述出来即可，具体的标准，大家应该很清楚的，就是“描述性的语言来说明用户的期望”，主要包括的内容有：功能分类、开发环境说明、兼容性说明、性能说明、国际性说明、文档说明、外观说明、发布说明、支持和培训说明、其它说明、方案概述、技术概述。建议大家加一个表格，就是“需求概要表”，这个表格的作用就是用列举的形式来把所有市场需求记录下来，毕竟上面的内容都是描述性的，这个表格有助于快速浏览。这个表格应该包括的内容有但不仅限于：实现目标、约束条件、需求联系、原型、类型、优先级。

MRD主要用处是定义市场需求，可能是针对一个新产品也可能是旧有产品的一个增强型的功能，BRD是对于商业问题和解决问题的方法的简要定义，而MRD则更加的细节，他可能包括以下几点：

a. 解决这个商业问题的功能需求；
b. 市场和竞争对手分析；
c. 功能与非功能需求；（所谓非功能需求包括性能要求等）
d. 功能需求的优先级；
e. 需求用例。

MRD实例：

紧接着上面那个CRM的例子继续，MRD会定义需求，对需求进行优先级排序，同时描述需求用例。需求主要包括功能需求和非功能需求两种：

A. 功能需求：

必须能够在IE（6.0版本以上）和FireFox（1.5版本以上）上工作；
必须使用SSL协议保证通信能够被加密；
用户能通过交互界面输入以下字段的内容：用户名称、公司名称、联系方式、机会说明、销售额度等等。
…

B.非功能需求：

能够承担十万同时在线用户；
系统稳定性达到99.9%；
拥有英、德、日三种语言的用户使用说明。
…

PRD：Product Requirements Document，产品需求文档。

PRD是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。该文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。

PRD文档，基点依然是MRD中的内容，只是把重心放在了“产品需求”上，而产品需求本身是在MRD中有所体现的，区别就是在于，PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。该文档中，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。在一些国外的公司，是允许把MRD和PRD合并成一个文档的，通常叫做“Marketing & Product Requirements Document”。

产品需求文档侧重于产品需求的具体阐述，是BRD的延伸。如果说BRD可以决定要不要做以及做什么的话，那么PRD就解决怎么做的问题。商业需求文档侧重性价比的描述，产品需求文档侧重产品功能规划及实施，即想方设法实现BRD中提到的价值并使之最大化。该文档的内容主要包括产品定位、目标人群界定、用于满足用户哪些核心需求或解决哪些问题、同行竞品分析、差异化竞争优势、推广运营策略、盈利模式分析以及详细的产品功能规划（如业务逻辑、权限分配、功能模块设置、参数规格等）、产品实施路线图、非功能性需求（如界面UI风格、安全性、易用性、兼容性、性能等需求）。通过该文档，读者对整个产品有个全面清晰的了解。

产品需求文档和产品战略文档（Product Strategy）、产品发展路线文档（Roadmap）的区别：产品战略描绘出2-5年产品的发展方向和蓝图而产品发展路线文档描绘出不同的阶段到达这个目标；产品需求文档则是在这个蓝图中某一个阶段的详细需求产品。

PRD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。

PRD文档一般可以包括以下内容：

该产品的远景目标（vision）
目标市场和客户（target market and customers）的描述
竞争对手分析（competitive summary）
对产品主要feature的比较详细的描述
这些feature的优先级
初步拟定的实现进度安排
用例（use cases），这可以是较粗略的大致描述，未必一定要UML Use Case图。
产品的软硬件需求
产品的性能要求
销售方式上的思路、需求（直销还是渠道？直销怎么做？渠道怎么做？）
技术支持方式上的思路、需求（提供什么样的技术服务？）

在一个完整的PRD中，最好对产品的10个产品需求项指标进行说明，分别是“功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、产品外观要求、产品发布要求、产品支持和培训要求、产品其它要求”。

MRD往往从市场需求角度描述产品的需求，而PRD更加关注产品本身的需求，会详细描述各种特性与功能的细节，PRD中还常常包括用户界面和用户流程。如果一家公司的MRD不包括各种特性与功能的细节需求和用户需求用例的话，这些内容就会由PRD来描述。

PRD实例：

继续上面的CRM项目，在这个项目中PRD文档应该包括的内容是：

登录界面应包括用户名、密码字段，还应该有“忘记密码？”提示文字链；
“联系我们”界面应该让用户可以输入姓名、电话、Email…
“销售预测”界面在生成年度预测报告前，应该有5个步骤，每个步骤用户都会输入一些限定条件，每个步骤的详细说明如下：
…

PRD文档除了上面描述的这些功能逻辑外，还应该包括一些详细的需求用例。

FSD：Functional Specifications Document，功能详细说明文档。

FSD这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。功能详细说明文档从具体执行的角度定义产品的功能需求，FSD会对每一个界面和功能做出非常细节的定义说明，并能够直接交付技术人员进行开发。我们再来对比一下MRD、PRD还有FSD的不同，MRD是关注于市场需求的需求定义，PRD是关注于产品本身的需求定义，而FSD是关注于定义功能的细节设计，这个设计会以技术人员熟悉的格式撰写，并直接交付技术人员进行开发，FSD还包括确定的UI设计，界面各个部分细节都已经被确定。这篇文档通常由产品分析师、技术负责人或者项目经理来撰写，总之这个文档的作者一般都隶属于技术团队。这篇文档一般是无数页的word或者其他的文本文件格式文档。相应的，有很多内容，比如表结构设计，要由项目经理来编写了。

产品需求文档（product requirements document，PRD）描绘出公司将要创造的产品。它影响着公司的产品团队的成果,公司的销售额、市场和客户满意程度。它要为公司提出更重要，更有价值的产品。产品需求文档需要清楚简明的表达出产品的目的、效果，功能，表现。产品开发团队将使用这份文档开发出产品并检验，所以PRD需要提供足够的信息。一份优秀的产品需求文档不一定会作出优秀的产品，但是无疑的没有一份的好的产品需求文档就更难作出好的产品。

产品需求文档和市场需求文档的区别：我们需要区分PRD和MRD（market requirements document市场需求文档）。简单通俗的说MRD描绘出市场机会与市场需求，PRD是描绘满足市场机会和市场需求的一个产品。

产品需求文档和产品战略文档（Product Strategy）、产品发展路线文档（Roadmap）的区别：产品战略描绘出2-5年产品的发展方向和蓝图而产品发展路线文档描绘出不同的阶段到达这个目标；产品需求文档则是在这个蓝图中某一个阶段的详细需求产品。

如何写好产品需求文档：

做好产品需求文档的这十步，是经过长期的实践经验和反复验证而得到的。可能这里描述的不是很全面，但他已经足够让你做一个成功的产品需求文档。做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。

第一步：做好准备工作

你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。建立良好的交流也非常重要，它会影响着产品团队。如果你的准备工作做的够好，你也会变得越来越有信心和说服力。

第二步：确定产品的目的

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

产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。例如，你的目标可能是：1）易用，2）零售价不足$100，3）和前期产品很好的结合。然后你需要说明如何去测算。对于“易用”这类项目，你需要明确指出产品可用性达到某个水平。这是通常用目标用户来定义。可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。这里的关键就是让每个人都知道产品成功的时候是什么样，还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。

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

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

用户原型：在这个阶段，PM需要和很多用户交流，需要花费大量的时间去直接观察和讨论。现在我们需要对用户和顾客进行分类，然后决定哪一类是我们的首要用户。比如你正在做一个像eBay一样的互联网拍卖服务，你同时拥有买家和卖家，在这之中还有使用频率少的用户和经常使用的用户，不难想象还有个别特殊的用户，比如团体公司采购者。

PM（产品经理）和PD（产品设计）需要首先确定类型是最重要的，然后尽量对这个用户群的特征进行详细的描述，以便使用这个模型去指导产品的设计。这个模型通常称其为“人物角色”。 虽然是想像的，但是应该是典型的、可行的和真实的，让你能够使用。这个想法来自与一个能代表这类用户的本质的原型。

举个例子：

“里昂是一个超级卖家，46岁，男性，居住在Fresno，经营小型摩托车配件。虽然他开着一个小店，但是他的生意大部分来自Ebay,每个月平均有400多次交易。他出售的东西品种非常多，但是他最受欢迎的商品还是哈雷戴维森的负重袋。他自己拥有两个哈雷，还开着1993年的丰田皮卡。里昂已经结婚了还有两个小孩。里昂买电脑仅仅是因为他需要使用Ebay,除了ebay和电子邮件很少再使用其他东西。里昂已经在Ebay上销售产品已经三年了，他学会了在ebay应该掌握的东西，他非常自豪的拥有超过5000的信用度。如果Ebay更改了网站，特别是销售的过程方面，对于他来说改变习惯、学习这些变更是非常困难的。 里昂已经形成了自己的习惯，星期一列出销售的商品，星期五拍卖结束，设法让在收到货款的几个小时内出货。”

但愿这样的描述能让你了解里昂和知道他是怎么来的。当我们考虑新功能时，我就要问问自己里昂会是什么反应，为了让他能顺利的使用这个功能我们需要做什么。注意缩小范围，让他仅仅描绘必不可少的。满足所有人是徒劳的，通常最后没人会满意，所以尽量提出几个最重要的和最流行的角色描述是非常重要的。同样，如果你不去精确的定位你的目标用户，你就只会存在模糊的概念，你会发现理解你用户的反应非常困难。你要倾向于设想，让你能更像你的用户。

用户目标（用户意愿）

一旦我们确定并描绘了我们主要的用户类型，我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单，但是解开根本问题是非常具有挑战性的，特别当你周围的人告诉你你已经解决了他们想要的。从CEO、销售代表、工程师到客户，每个人都太兴奋而不能帮助你找到解决根本问题的办法，他们会告诉你在某个地方添加一个快捷按钮，或则添加一个功能仅仅是因为竞争对手有，或则是改变成他们喜欢的颜色。最好的解决办法取决于清晰的了解到底什么问题需要解决，每个用户模型可能有不同的目的，需要在用户原型涉及的方面中进行寻找。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。

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

掌握了用户原型与他们的目标愿望，我们就开始着手设计任务来满足他们的目标意愿，这是产品制作进程中最核心的部分，也是创造力和创新力被激发的地方。许多优秀的产品仅是用更好更新的办法解决一个已有的问题，有时候这种办法仅仅是应用一个种新技术，但是大部分是来自深刻的见解而使一种新方法的产生。例如TiVo（美国市场占有率第一的数字录像机）在电视节目录制的老问题上面想出一个全新的办法，让顾客更加容易地实现他们的目标并且建立了电子设备一个全新的类别。

注意我们虽然谈到了目标和任务但是还没有谈到具体的功能，这些功能都需要达到用户目标而必须的。你以后会发现许多功能都是低优先级或则是完全多余的。以“必须功能”这个理由可以排除很多功能。讽刺的是，你用越少的功能，你的产品被发现得越来越强大。这是因为产品的功能越少，你的用户就会发现并使用更多的功能，成功的使用越来越多的功能他们就认为你的产品非常强大。这些理由都是违反我们直觉的，我们大多数人都不能和我们的用户一样，我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。

第四步：定义产品原则

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

在大多数的产品团队中，每个成员都有做好产品的原则，但很少有两个人有同样的想法，这些差异都会导致不可思议的结果。尝试和制订一系列指导整个团队的产品原则是非常有价值的，这些原则需要具体到域名和项目。

用TiVo举例，在产品团队工作开始时，以下这些产品规范就被建立，并在团队里传达：

1.它是娱乐的
2.一个傻瓜式的电视
3.一个该死的视频设备
4.平滑柔顺的
5.没有模式和深层次
6.尊重观众的隐私权
7.像电视一样强大

这些规范很大的影响到产品的定义而且在很大程度上加大了难度，但是他们确实是成功产品的来源。比如易趣的口号就是：1、易于使用 2、安全 3、有趣

它将在该项目中，在面对众多问题而作出决定的时候进行指南.

第五步：产品原型和检验

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

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

1.可行性测试：一个直接的问题就是产品是否可以开发，你的工程师和设计师应当介入技术的可行性调查和探索可用办法。有些办法是行不通的，但是有其他的办法可行是非常有希望的。工程师会发现在产品的某个阶段不可能逾越，现在知道比以后知道要好。

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

3.概念测试（Product Concept Testing）：光是可用和可行是不足的。真正的问题是你的用户想要购买吗？你的用户有多喜欢？你做的有什么价值？这测试可能与可用性测试联系在一起。

对于一部份小产品，您的想法写在纸就足够了，但是对于多数产品，为了预计产品是否达到目标，复杂人机交互或新技术的使用、某种形式原型都是非常重要的。原型也许是一个物理设备，或者它也许是软件产品的一个预览版本。关键是它需要足够现实，您能用原型在实际目标顾客身上测试，并且他们可以给您质量反馈。

以前做原型主要有两个障碍。第一是缺乏良好的原型工具，需要花费很多的时间制作原型；另一个是管理方不知道原型和真实产品的区别，在不可预计的情况下，按照最终产品来要求原型。今天有优秀的原型设计工具可以让工程师或设计师快速的制作原型，可以有效的模拟未来的产品以达到必要的程度让实际用户进行测试。而且大多数管理者都知道模仿和实际的区别——就如同缩小比例的房子模型和真实的家一样。

在实际去做产品之前去检验你的产品是非常重要的。一旦实际的工程开始，作出重要的变动会变得非常困难，花费也会变得很高。

第六步：验证和质疑

当你认为你弄懂了你需要解决的问题，现在是时候开始验证和质疑假设。假设甚至当作不知道是很容易的，但是切勿把不可知的结论当作指引，那会妨碍你获得成功。天文学最初定义是研究太阳和其他行星如何围绕自己转，本身的定义就是一个臆断，反而阻止人们获得真相。

第七步：写

当然你需要把这些都写下来，大多数的PRD都是word文档，但也有一些是帮助文档，PowerPoint，或则写在白纸上。当然用什么格式不是很重要，重要的是让团队成功能轻松的看懂，不会遗漏，还有就是PRD可以随着项目开发而更新。记住对话是两个人之间的，但是PRD是要沟通整个小组。你也要记住获得产品的销售才是是重要的，所以不必担心要有什么漂亮的外观、PRD写的有多厚，只要它是可读的、可理解的、是需要的内容。

PRD文档主要有四个部份组成：

1.产品用途：你的工作就是指出目标，团队需要知道他们的目的是什么，目标说明要尽可能的明确，请确保你的内容包括：

*那些问题你要解决，不是解决方案
*谁是目标用户
*细节很多，但是大图片必须清晰
*情景描述

多开展集思广益的会议和临时口头的讨论，从而更好的写出来，更会让团队深入了解。

2.产品功能特性：产品需求文档最主要的当然是需求。 具体的需求完全地将取决于您的领域，但是不管你是什么行业，您的产品团队将受益于陈述需求的清楚，毫不含糊的要求，而不是模糊的解决方案。

描述每个功能的互动设计和使用案例。您必须非常清楚每个功能和用户体验，还需要给工程团队留下足够多的灵活自主空间。同样重要的是确定那些要求满足哪个目的。这里就需要提到“需求跟踪”，对于关键的产品这是一个重要的流程。每种产品规范可能受益于清楚确定那些要求满足哪个目的，如果某人决定削减要求，想要深入了解就会非常困难。从要求到目的明确说明将会是文档更加清晰。

3.发布标准：发布标准经常是不断变化的，但是好的PRD应该考虑到为每种标准定一个最低要求。典型的如：性能，可测量性，可靠性，可用性，可控性。

4.时间进度：其中很困难的一个问题就是描述产品需要的时间进度表。随便列出一个时间是没用的，你需要描述环境、动机、预计目标。你需要整个团队都和你一样达到预计目标，最终完成一个成功的产品。

第八步 优先级

除了明确的要求，对每一个您的要求给予优先和排列秩序是很重要的。多数产品经理，如果他们给予优先级，一般都是表明要求是否是“必须有， “重要”或“希望拥有” (或其他一些分类系统)。分类是很重要的，不可掉以轻心。产品经理对任何一个标记“必须拥有”都需要有高度的标准。如果还没有找到必须拥有的功能意味着产品还不应该产生。所以小心标注“必须拥有”，这些标注“必须拥有”的功能直接反应出产品的核心价值。“重要”的分类也很重要，在产品销售前只要有机会就要满足这些功能。“希望拥有”产品团队也应该注意到，即使大多数也都没有实现，在未来版本也适当的慢慢实现。

这些有时候是不够的，从1到n每一个分类优先排序都是很重要的。有几个原因：

首先，上市时间总是被关注，并且日程表经常下降，您说不定被迫使削减有些特点为了尽快进入市场。你也不想产品团队先开发简单的功能而放松重要的功能，导致最后客户使用的关键功能还没完成。其次，在产品设计和开发阶段，团队将会发现更多的问题产生并解决这些问题，所以很有可能有更多关键功能出现。优先顺序会可以帮助你如何平衡以容纳更多的功能。也就是说如果不给出优先级和重要等级，其他相关较少的因素也会跟着无法确定。

整个PRD是一个不断完善和思维提高的过程，明朗锐利就是可以成功产品的，模糊就是失败的产品。在争论最激烈的时候也能容易做决定，并且帮助工程师做出计划。

第九步 测试完整性

现在你有一个PRD草稿，你需要测试它的完整性。工程师是否可以充分了解并达到目标？OA Team（质量管理团队）是否有足够的信息来做出测试计划，是否可以开始做案例？当投资人或相关人审核了PRD，确定了各个需要说明的方面，所有的问题得到解决，现在你就可以按PRD进行产品开发。

第十步 管理产品

在产品实施期间，就算是最好PRD，也有不计其数的问题，产品经理的任务就是迅速解决问题并记录在PRD。如果你做了你的工作并准备记录在PRD，项目审查就会变得非常简单，因为任何一个部分都历历在目。记住PRD是一个“活”的文件，在要跟踪记录在产品开发期间的所有功能过程。最后你会发现很多额外的东西，如果你认为是必要的就在PRD中写进。