如何写好产品需求文档解读
产品需求文档
很多产品在正式上线前都有BETA版本或者内测版本，或者叫灰度版本，目的是在测试产品的一些核心功能或 者性能。这部分内容不是必须的，但如果需要，需要给出在此阶段要实现的目标或测试、衡量标准。
一般情况下非功能性需求包括以下几个部分：产品营销需求、运营需求、财务需求、法务需求、使用帮助、 问题反馈等。这些信息构成了产品上线的完整内容，也很好的体现了产品经理的综合素质。
在与团队沟通变更时，需要以一种开放的心态，从团队成员的角度、产品未来的发展趋势、市场格局的变化 正确的提出变更需求，始终保持产品方向的正确和团队成员目标的一致。
的相关内容
文档撰写
文档意义
文档核心
该文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD 中的内容技术化，向研发部门说明产品的功能和性能指标。
该文档中，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加 详细，并进行量化。在一些国外的公司，是允许把MRD和PRD合并成一个文档的，通常叫做“Marketing & Product Requirements Document”。
的写作方法
1
写前准备
2
梳理需求
3
原型设计
4
撰写文档
5
用例文档
在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助 我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。因为这是第一步，所以我们不需 要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。
例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求 只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不 用刻意的追求信息的全面。
产品需求文档(PRD)撰写方法
产品需求文档（PRD）撰写方法第一步：做好准备工作你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。
你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。
你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。
这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。
建立良好的交流也非常重要，它会影响着产品团队。
如果你的准备工作做的够好，你也会变得越来越有信心和说服力。
第二步：确定产品的目的任何一个好的产品都开始于一个需求。
你必须清楚的了解这个需求，你的产品如何达到这个需求。
产品经理需要提出一个清晰、简明的价值主张，让它很容易被接受，要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。
虽然这听起来很简单，但是也只有少数产品才有这样的价值主张。
考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。
假设你在做电梯的时候遇到公司CEO，他问你产品的意图是什么，你能在电梯到达之前回答这个问题吗？如果不能，你就还有工作需要做。
也许是你的说明没有针对性，他可能表现出来和其他产品做的没有什么明显区别；也许你提出的观点不能和你的用户产生共鸣；也许你解决的是一个非常规的问题，可能你想应用一种技术。
这个价值主张可能需要满足公司的产品战略。
注意你不需要阐述太多的细节，从某些方面来说，一个有价值的观点应当是越简越好。
产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。
例如，你的目标可能是：1）易用，2）零售价不足$100，3）和前期产品很好的结合。
然后你需要说明如何去测算。
对于“易用”这类项目，你需要明确指出产品可用性达到某个水平。
这是通常用目标用户来定义。
可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。
如何写好产品需求文档PRD
如何写好产品需求文档PRD作者：Martin Cagan ，Silicon Valley Product Group译文：曾毅（Eary）译者注：本译文受本人学识以及对行业了解程度的影响，难免有误。
概述：产品需求文档（product requirements document，PRD）描绘出公司将要创造的产品。
它影响着公司的产品团队的成果,公司的销售额、市场和客户满意程度。
它要为公司提出更重要，更有价值的产品。
产品需求文档需要清楚简明的表达出产品的目的、效果，功能，表现。
产品开发团队将使用这份文档开发出产品并检验，所以PRD需要提供足够的信息。
一份优秀的产品需求文档不一定会作出优秀的产品，但是无疑的没有一份的好的产品需求文档就更难作出好的产品。
产品需求文档和市场需求文档的区别：我们需要区分PRD和MRD（market requirements document 市场需求文档）。
简单通俗的说MRD描绘出市场机会与市场需求，PRD是描绘满足市场机会和市场需求的一个产品。
产品需求文档和产品战略文档（Product Strategy）、产品发展路线文档（Roadmap）的区别：产品战略描绘出2-5年产品的发展方向和蓝图而产品发展路线文档描绘出不同的阶段到达这个目标；产品需求文档则是在这个蓝图中某一个阶段的详细需求产品。
小注：1.不同的公司和行业会使用不同的术语、方式表现出产品需求。
类似的，有的团队会使用针对性的文档单一的去描述市场、产品、功能、界面，有的还会有一系列的文档。
为表达我们的目的，我们使用朴实易懂的文字“产品需求”以及取其英文单词首位“PRD“来命名它。
我们有意不提及我们认为应当区分的市场需求文档。
2.这篇文章是在Ben Horowitz, President and CEO of Opsware的见解基础上产生的。
十步做好产品需求文档做好产品需求文档的这十步，是经过长期的实践经验和反复验证而得到的。
产品需求文档8要素
产品需求文档（Product Requirement Document，PRD），是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。
它是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是对市场需求文档中的内容进行指标化和技术化，产品需求文档质量的好坏直接影响到研发部门是否能够明确产品的功能和性能。
产品需求文档对任何一个产品经理来讲都不会陌生，它是衡量PM整体思维的标准，PM的整体思维体现在：1、提炼核心需求；2、思考满足核心需求的方式；3、评估方式优劣，选定方案；4、思考功能概要；5、思考支撑功能和关联功能；6、细化设计功能；7、子功能（功能间迭代）。
而产品需求文档就是将以上思维整体走向表达出来，同时将产品的思想提炼出来，用文字表示给开发者，给UI、给视觉、给老板……产品需求文档给的是一种思想，将产品的整体思想和核心需求灌输给产品的相关人员，因此说PRD 具有承上启下的功能，上接MRD，下对MRD进行技术性的描述。
那么应该如何撰写产品需求文档？本文将为大家引导性讲解一下产品需求文档的主要内容和大致的撰写思路。
在撰写产品需求文档之前，首先要做好以下几点准备工作：1、了解你的用户、竞争对手、产品团队的实力和需要的技术。
你需要从用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。
2、确定产品的目的，任何一个好的产品都开始于一个需求。
你必须清楚的了解这个需求，你的产品如何达到这个需求。
产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。
可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。
这里的关键就是让每个人都知道产品成功的时候是什么样，还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。
3、确定用户原型、用户目标（用户意愿）和用户任务（用户为达到目标使用产品而需要做的任务）。
3.产品需求文档（PRD）的撰写
3.产品需求文档（PRD）的撰写产品需求文档是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。
该文档是产品项目由“概念化”阶段进入“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
在PRD中，基点依然是MRD中的内容，只是把重心放在了“产品需求”上，而产品需求本身是在MRD中有所体现的，区别在于，PRD要把MRD中“产品需求”的内容独立出来，并加以详细的说明。
在撰写PRD时，要注重对MRD内容进行继承和发展，把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。
该文档侧重的是对产品功能和性能（即“产品需求”）的说明，相对于MRD中同样的内容，要更加详细，并进行量化。
一些国外公司允许把MRD和PRD合并成一个文档，通常叫做“Marketing & Product Require ments Document”。
【小提示】关于PRD的错误认识。
1）PRD无原始数据支持，只是按个人经验、部门要求或者领导指示进行撰写。
2）在PRD中，只重视“产品功能”的描述，而缺乏对产品其他指标项的说明。
3）照搬别人的PRD模板，来源于何处，不知道，将去向何处，也不知道，无头无尾，是一个被割裂的文档。
那么，如何完成一份优秀的产品需求文档呢，下面的一些标准可以供参考：（1）让“有用性”更加准确分析人员应将从用户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。
通过这些分析，用户就能得到一份“需求分析报告”，此份报告使分析人员和用户之间针对要分析的产品内容达成协议。
报告应以一种用户认为易于翻阅和理解的方式组织编写。
用户要评审此报告，以确保报告内容准确完整地表达其需求。
一份高质量的“需求分析报告”有助于分析人员分析出真正需要的产品。
（2）让“有用性”可验证和可实现对用户方而言，各项需求应当都是可验证的。
产品经理必备文档-如何写好PRD需求文档
如何写好PRD需求文档一、PRD Product Requirement Document 产品需求文档，核心是将需求描述清楚。
二、PRD 的维度、质量可以体现产品经理如下素质：1、对产品理解的逻辑思维；2、在相关领域的认知；3、专业的深度；4、对产品全局的认识。
三、好的PRD解决的问题：1、体现产品需求。
(产品研发团队成员、开发、测试、运营)2、体现产品价值、意义。
3、准确度高、产品扩展性好、受用户欢迎。
四、从用户侧分析好的PRD应该具备的要素或必要条件。
1、了解清楚PRD的阅读对象，使用者。
产品、开发、测试：了解本次需求的背景和详细要求，以及每个需求点未来的优化方向或对用的价值。
用户方代表：了解PRD中描述内容是否是自己期望中的需求，是否符合及覆盖到了自己的预期。
产品经理同相关角色确认开发任务的重要依据。
五、完整的RPD具备的要素：1、文档命名和编号：目的：在产品迭代中，区分不同阶段的功能及需求。
格式一：**产品V1.0RPD_V2前面的V1.0是产品迭代的编号，后面的V2 PRD的版本号。
格式二：**产品***需求PRD_V22、文档的版本历史：编号：记录修改的顺序。
文档版本：显示当前修改的内容归属版本，一般一次修改为一个版本。
章节：具体到修改内容所属功能模块，以便阅读人及时找到修改后的内容。
修改原因：为什么要修改需求。
日期：需求文档修改时间。
修改人：需求内容修改者。
3、目录：文档完成后直接更新模板中目录，用千了解文档结构。
4、引言：产品概述及目标：解释说明该产品研发的背景及核心功能。
产品Roadmap：不需要全部规划好所有阶段目标，但要记录每个关键阶段完成的核心任务，对产品未来发展趋势的一种预估。
预期读者：文档的使用对象。
成功的定义标准和判断：旨在说明产品的目标。
参考资料：PRD 的参考资料。
名词说明：对名词的解释。
5、需求概述：需求概览（业务流程图、需求清单）：对产品整个业务流程发生过程做图形化展示；对产品整体功能流程的阐释；对本次要开发需求任务分类，给出简明扼要的需求描述及优先级。
产品经理如何编写产品需求文档？
作为产品经理，经过思考输出的内容主要有两个，一个是产品需求文档，一个是产品原型。
所以经常有人会戏称产品经理就是写文档和画原型的。
记得刚开始做产品经理时，为了写好需求文档，在网上找了好多模板，反复对比研究，用了一个目录最多的，然后进行内容填充。
写过几次之后发现，自己为了填充模板花费了大量时间，而模板中的很多项目并不符合实际工作情况，反而成为了工具的奴隶。
所以为了避免以后类似情况的发生，需要认真思考如何才能编写出适合自己的产品需求文档。
一、什么是产品需求文档？与产品相关的几种文档：BRD 商业需求文档、MRD 市场需求文档、PRD 产品需求文档。
以完整的产品生命周期来说，在写PRD之前，先要写BRD和MRD。
BRD 商业需求文档的编写是站在公司角度，面对的是公司老板和高管，从战略层面回答“我们要不要做”，是推出新产品还是改变原有产品方向。
MRD 市场需求文档，是对BRD的补充和细化，分析市场机会、竞争情况、产品定位、发展策略等。
也就是说BRD和MRD主要分析了我们要不要做，如何做，产品的发展和推进的策略是什么，不会涉及到产品的具体需求细节。
而PRD 产品需求文档，则是主要对产品需求细节进行说明，描述功能逻辑和相关流程。
产品需求文档是产品经理把用户需求转化为产品需求的最终体现。
在整个过程中，经过了市场分析、需求调研、需求分析、产品设计等若干环节，最后以产品需求文档的形式呈现，可以是word、PPT，甚至是手绘卡片。
前期深入的思考和分析才是文档的核心。
当然也不是说文档的形式的不重要，作为产品经理的输出物，体现产品经理的基本功和脸面，所以在明确目的的前提下，要使产品需求文档发挥最大的价值。
二、为什么要编写产品需求文档？1、更加深入理解产品需求。
把用户需求转化为产品需求，才是产品经理的核心能力。
例如用户想要一匹更快的马，如果用户是想更快的到达目的地，那么我们可以为用户提供汽车，但如果用户是想赛马比赛上获得好成绩，那么我们就应该从专业角度为用户选择一匹优良的马。
产品需求文档 - 产品需求应该怎么写
产品需求应该怎么写读前思考1 写产品文档的核心目的？1.执行层面：从产品视角拆解运营或者业务的需求，给下游的合作伙伴（技术，交互，测试，用研，数据等）一个可阅读，可转换到对应工作域的文档2.合作层面：公司内外部合作既有单纯阳光，也有趋利避害，但不管环境如何，从走正道的角度来讲，每做一件事一个需求，对上下游合作伙伴讲的清楚价值，能够让大家充分达成共识，拿到结果，这会让合作变得更加顺畅，低成本和充满信任感2 产品文档的形式和颗粒度？1.形式：我比较推崇在线的工具，便于多人编辑和共享2.颗粒度：讲清楚价值，要做的事情即可，尽可能还是要结构化，简单透彻无废话，体现专业性模板如下一背景背景：为什么要做这个项目？优先级：为什么非做不可？客户：解决谁的问题？价值：带来什么价值？其它...1.建议结构化1,2,3...的表述2.简单触及本质，赘述比较多说明没有思考透彻二目标可量化的价值：项目做了能达成什么业务结果，什么数字化目标...1.目标应该是清晰且必答的2.应尽量是可以拆解的量化目标三运营节奏运营节奏：项目上线了之后，谁来负责运营，谁为结果买单，运营节奏是什么注意：运营、产品、技术的视角，对于项目的理解是不同的，核心是多一些视角保障项目能够落地拿到预期结果1.运营同学：XXX2.运营节奏：XXX 这里重要的是让运营同学背靠背，很对项目运营模棱两可，上线后就逐渐流产了四业务\产品流程主要是让项目参与人能够快速了解项目全貌，各自有侧重点，参与人不了解全貌和重点的需求评审效率会很底下，因为大家都是从懵逼状态开始听的注意：流程图要讲清楚起点和终点，角色、产品域之间的关系，既让大家一眼能看懂业务流程是什么，也能明确知道产品流程在其中如何发挥作用的1.形式：推荐使用泳道图的方式2.工具：process on ， draw.io , axure rp 都是不错的工具（工具不重要，讲清楚即可）五需求列表及优先级需求列表及优先级，是让项目参与同学尤其是产品自身，拥有一个俯视视角，能够不至于一下陷入到具体细节里面去；这种视角的思考体现的更多的是产品经理对于自身产品和系统的了解，把控全局的专业力，MVP小步快跑敏捷性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1.PM如何写好产品需求文档1.1十步做好产品需求文档做好产品需求文档的这十步，是经过长期的实践经验和反复验证而得到的。
可能这里描述的不是很全面，但他已经足够让你做一个成功的产品需求文档。
做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。
1.2第一步：做好准备工作你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。
你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。
你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。
这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。
建立良好的交流也非常重要，它会影响着产品团队。
如果你的准备工作做的够好，你也会变得越来越有信心和说服力。
1.3第二步：确定产品的目的任何一个好的产品都开始于一个需求。
你必须清楚的了解这个需求，你的产品如何达到这个需求。
产品经理需要提出一个清晰、简明的价值主张，让它很容易被接受，要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。
虽然这听起来很简单，但是也只有少数产品才有这样的价值主张。
考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。
假设你在做电梯的时候遇到公司CEO，他问你产品的意图是什么，你能在电梯到达之前回答这个问题吗？如果不能，你就还有工作需要做。
也许是你的说明没有针对性，他可能表现出来和其他产品做的没有什么明显区别；也许你提出的观点不能和你的用户产生共鸣；也许你解决的是一个非常规的问题，可能你想应用一种技术。
这个价值主张可能需要满足公司的产品战略。
注意你不需要阐述太多的细节，从某些方面来说，一个有价值的观点应当是越简越好。
产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。
例如，你的目标可能是：1）易用，2）零售价不足$100，3）和前期产品很好的结合。
然后你需要说明如何去测算。
对于“易用”这类项目，你需要明确指出产品可用性达到某个水平。
这是通常用目标用户来定义。
可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。
这里的关键就是让每个人都知道产品成功的时候是什么样，还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。
1.4第三步：确定用户原型、用户目标和用户任务现在你已经明白你想要解决什么问题，下接下来就要深入了解目标用户和顾客，在这步中，和你的PD（产品设计）紧密联系非常重要。
用户原型在这个阶段，PM需要和很多用户交流，需要花费大量的时间去直接观察和讨论。
现在我们需要对用户和顾客进行分类，然后决定那一类是我们的首要用户。
比如你正在做一个像eBay一样的互联网拍卖服务，你同时拥有买家和卖家，在这之中还有使用频率少的用户和经常使用的用户，不难想象还有个别特殊的用户，比如团体公司采购者。
PM（产品经理）和PD（产品设计）需要首先确定类型是最重要的，然后尽量对这个用户群的特征进行详细的描述，以便使用这个模型去指导产品的设计。
这个模型通常称其为“人物角色”。
虽然是想象的，但是应该是典型的、可行的和真实的，让你能够使用。
这个想法来自与一个能代表这类用户的本质的原型。
举个例子：“里昂是一个超级卖家，46岁，男性，居住在Fresno，经营小型摩托车配件。
虽然他开着一个小店，但是他的生意大部分来自EBay,每个月平均有400多次交易。
他出售的东西品种非常多，但是他最受欢迎的商品还是哈雷戴维森的负重袋。
他自己拥有两个哈雷，还开着1993年的丰田皮卡。
里昂已经结婚了还有两个小孩。
里昂买电脑仅仅是因为他需要使用EBay,除了eBay和电子邮件很少再使用其他东西。
里昂已经在EBay上销售产品已经三年了，他学会了在eBay应该掌握的东西，他非常自豪的拥有超过5000的信用度。
如果EBay更改了网站，特别是销售的过程方面，对于他来说改变习惯、学习这些变更是非常困难的。
里昂已经形成了自己的习惯，星期一列出销售的商品，星期五拍卖结束，设法让在收到货款的几个小时内出货。
”但愿这样的描述能让你了解里昂和知道他是怎么来的。
当我们考虑新功能时，我就要问问自己里昂会是什么发应，为了让他能顺利的使用这个功能我们需要做什么。
注意缩小范围，让他仅仅描绘必不可少的。
满足所有人是徒劳的，通常最后没人会满意，所以尽量提出几个最重要的和最流行的角色描述是非常重要的。
同样，如果你不去精确的定位你的目标用户，你就只会存在模糊的概念，你会发现理解你用户的反应非常困难。
你要倾向于设想，让你能更像你的用户。
用户目标（用户意愿）一旦我们确定并描绘了我们主要的用户类型，我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单，但是解开根本问题是非常具有挑战性的，特别当你周围的人告诉你已经解决了他们想要的。
从CEO、销售代表、工程师到客户，每个人都太兴奋而不能帮助你找到解决根本问题的办法，他们会告诉你在某个地方添加一个快捷按钮，或则添加一个功能仅仅是因为竞争对手有，或则是改变成他们喜欢的颜色。
最好的解决办法取决于清晰的了解到底什么问题需要解决，每个用户模型可能有不同的目的，需要在用户原型涉及的方面中进行寻找。
有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。
用户任务（tasks，用户为达到目标使用产品而需要做的任务）掌握了用户原型与他们的目标愿望，我们就开始着手设计任务来满足他们的目标意愿，这是产品制作进程中最核心的部分，也是创造力和创新力被激发的地方。
许多优秀的产品仅是用更好更新的办法解决一个已有的问题，有时候这种办法仅仅是应用一个种新技术，但是大部分是来自深刻的见解而使一种新方法的产生。
例如TiVo（美国市场占有率第一的数字录像机）在电视节目录制的老问题上面想出一个全新的办法，让顾客更加容易地实现他们的目标并且建立了电子设备一个全新的类别。
注意我们虽然谈到了目标和任务但是还没有谈到具体的功能，这些功能都需要达到用户目标而必须的。
你以后会发现许多功能都是低优先级或则是完全多余的。
以“必须功能”这个理由可以排除很多功能。
讽刺的是，你用越少的功能，你的产品被发现得越来越强大。
这是因为产品的功能越少，你的用户就会发现并使用更多的功能，成功的使用越来越多的功能他们就认为你的产品非常强大。
这些理由都是违反我们直觉的，我们大多数人都不能和我们的用户一样，我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。
1.5第四步：定义产品原则现在你需要开始把你的需求和用户体验定义成详细的要求。
同时你仍然会面临着许多的决定和权衡，为你的产品标准做出最佳的决定是非常重要的。
在大多数的产品团队中，每个成员都有做好产品的原则，但很少有两个人有同样的想法，这些差异都会导致不可思议的结果。
尝试和制订一系列指导整个团队的产品原则是非常有价值的，这些原则需要具体到域名和项目。
用TiVo举例，在产品团队工作开始时，以下这些产品规范就被建立，并在团队里传达：1.它是娱乐的2.一个傻瓜式的电视3.一个该死的视频设备4.平滑柔顺的5.没有模式和深层次6.尊重观众的隐私权7.像电视一样强大这些规范很大的影响到产品的定义而且在很大程度上加大了难度，但是他们确实是成功产品的来源。
比如易趣的口号就是：1、易于使用2、安全3、有趣它将在该项目中，在面对众多问题而做出决定的时候进行指南。
1.6第五步：产品原型和检验这是一个拿出你想法的阶段，创造力和创新力拿出成就的地方。
很多人都容易犯一个常见的错误，他们对产品设计规范太有信心，结果一旦得到beta的测试他们就必须调整产品。
但是肯定beta测试版并不是进行重大改变的时候，所以才会有许多首次发布的产品离目标太远。
对于许多产品来说，这个时候你可以用大量的原型做很多的实验。
首先，下面的三个非常重要的测试你可能需要做。
可行性测试一个直接的问题就是产品是否可以开发，你的工程师和设计师应当介入技术的可行性调查和探索可用办法。
有些办法是行不通的，但是有其他的办法可行是非常有希望的。
工程师会发现在产品的某个阶段不可能逾越，现在知道比以后知道要好。
可用性测试产品设计师将要和你紧密工作共同提出产品功能，让它能适应不同的用户。
可用性测试常常会找出遗漏的产品要求，同时确认产品最初的要求是否是必须的。
在你拿出一个成功的用户体验之前需要多做一些测试工作。
可用性的目的是在真正的用户身上测试，从产品目标用户得到质量反馈的测试是非常艺术和科学的。
当然产品经理和产品设计将模仿使用，但是实际是没有人能取代真实的目标用户。
概念测试（Product Concept Testing）光是可用和可行是不足的。
真正的问题是你的用户想要购买吗—你的用户有多喜欢-你做的有什么价值。
这测试可能与可用性测试联系在一起。
对于一部份小产品，您的想法写在纸就足够了，但是对于多数产品，为了预计产品是否达到目标，复杂用户互作用或新技术的使用、某种形式原型都是非常重要的。
原型也许是一个物理设备，或者它也许是软件产品的一个预览版本。
关键是它需要足够现实，您能用原型在实际目标顾客身上测试，并且他们可以给您质量反馈。
以前做原型主要有两个障碍。
第一是缺乏良好的原型工具，需要花费很多的时间制作原型；另一个是管理方不知道原型和真实产品的区别，在不可预计的情况下，按照最终产品来要求原型。
今天有优秀的原型设计工具可以让工程师或设计师快速的制作原型，可以有效的模拟未来的产品以达到必要的程度让实际用户进行测试。
而且大多数管理者都知道模仿和实际的区别—就如同缩小比例的房子模型和真实的家一样。
在实际去做产品之前去检验你的产品是非常重要的。
一旦实际的工程开始，做出重要的变动会变得非常困难，花费也会变得很高。
1.7第六步：验证和质疑当你认为你弄懂了你需要解决的问题，现在是时候开始验证和质疑假设。
假设甚至当作不知道是很容易的，但是切勿把不可知的结论当作指引，那会妨碍你获得成功。
天文学最初定义是研究太阳和其他行星如何围绕自己转，本身的定义就是一个臆断，反而阻止人们获得真相。
1.8第七步：写当然你需要把这些都写下来，大多数的PRD都是word文档，但也有一些是帮助文档，PowerPoint，或则写在白纸上。
当然用什么格式不是很重要，重要的是让团队成功能轻松的看懂，不会遗漏，还有就是PRD可以随着项目开发而更新。
记住对话是两个人之间的，但是PRD是要沟通整个小组。
你也要记住获得产品的销售才是重要的，所以不必担心要有什么漂亮的外观、PRD写的有多厚，只要它是可读的、可理解的、是需要的内容。
PRD文档主要有四个部份组成产品用途你的工作就是指出目标，团队需要知道他们的目的是什么，目标说明要尽可能的明确，请确保你的内容包括：*那些问题你要解决，不是解决方案*谁是目标用户*细节很多，但是大图片必须清晰*情景描述多开展集思广益的会议和临时口头的讨论，从而更好的写出来，更会让团队深入了解。