来自Silicon Valley Product Group的Martin Cagan讲述了PRD对成功产品的重要性，也细致的描述了好的PRD需要哪些步骤才能完成，非常具有参考价值。
原文：https://svpg.com/assets/Files/goodprd.pdf
概述/Overview
什么是PRD？Product Requirements Description。是产品经理用户描述想要构建的产品，驱动着很多团队的工作，包括产品、销售、市场、以及客服，对于一个产品公司来说，PRD至关重要。
PRD通过四个维度度来描述产品，包括但不限于__目的__、特征、功能、行为。
PRD区别于MRD(Market Requirements Description，市场需求描述), MRD描述的是市场的机会和需求，而PRD是满足MRD的产品。
PRD区别于PS(Product Strategy，产品策略)和PR(Product Roadmap，产品路标)，PS是以为两到五年的视角来定位产品要达到的目标，PR是描述完成PS的步骤，PRD这是PS中的具体产品描述。
优秀的PRD是如何产生的？
下面提到的是个步骤都是经过验证有效的过程，每一步都需要付出很多，但却能保证产生优秀的PRD。
1. 做好功课/Do Your Homework
你的目标是提出一个引人注目的产品，为了这个目标你必须研究你的客户，你的竞争对手，和你的团队能力，甚至包括可用的技术。
这里有很多的准备工作可以进行，一些讨论的细节可以在”Behind Every Greate Product”里查看。
你对项目的信心程度决定了团队最终是否能够成功，做好功课，你会更有信心，也会更有说服力。
2. 定义产品目标/Define the Product’s Purpose
每个产品都始于它满足“需要”，所以你必须了解“需要“，并知道产品是如何满足这个“需要”。
产品经理能够建立一个清楚简洁的价值主张非常必要，这样他就能轻易的告诉任何人这个产品是到底是什么。
在定义产品目标的时候，就会发现有些产品常犯的错误：
- 产品功能不聚焦，功能很多，却没有任何亮点
- 解决的事情产品经理以为很重要，实际上在客户那里却微不足道
- 产品解决的问题也许现实并不存在需求
- 为了一项新技术而为它找到产品宿主
产品需求需要明确这款特定产品的目标有哪些以及如何测量，并且这些目标也应该被优先级排列。
比如你的产品目标有三个：1、易用 2、售价低于100 3、向前兼容。你应该继续描述如何测量这些目标，比如价格目标是非常简单清楚的，但是“易用”就需要给出产品的要求的易用水平，这通常是根据目标用户来定义的。可用性工程师可以为给定类别用户评估产品易用性，也可以评估产品易用性问题的严重性，以及明确这里没有主要的可用性问题。
这样做的目的是让参与产品的每个人都知道成功的样子，产品团队在需要进行必要的设计和实现之间的平衡的时候有所依据。
3. 定义用户画像，目标以及任务/Define the User Profiles, Goals and Tasks
现在我们理解了要解决的问题，下一步就是深入理解目标用户和客户，在这个过程中，和产品设计师密切配合工作是非常重要的。
用户画像/User Profiles
目标用户和客户很多，我们必须把他们进行分类，确定哪些是主要的群体，哪些是次要的群体，并根据群体特性树立一个典型代表，用于作为后面和产品交互测试时候的用户画像。
如果你试图满足每个客户，结果往往是没满足任何一个客户，基于此我们应该把目标用户缩减到主要群体，因为只有这样你才能知道面对产品特征和功能的时候，目标客户会给出怎样的反应。如果不这样做，你常常会把自己当作目标客户，实际上客户往往和你想的并不一样。
用户目标/User Goals
一旦我们明确哪些是主要用户并了解其特点后，接下来我们就需要确认用户在使用产品时需要完成的主要目标。听起来并不难，实际上当周围人都告诉你他们以为的解决方案的时候，搞清楚问题的根本并不是那么容易。
其实只要给产品经理和设计人员足够的时间和自由度，让他们提出解决方案，一个问题往往会有更好的方法提出。
如果想要弄清问题的根本，就必须把问题和具体用户放在一起思考，因为不同的用户会有不同的问题描述角度和方法，我们常常犯的一个错误就是增加一个功能来解决一个并不是主要用户的问题。
任务/Tasks
接下来我们就应该设计任务来完成上述的用户目标，这个过程往往伴随着各种创意和发明，属于产品化过程的核心。
对于已知问题，有时候是因为新技术的时候带来了新方案，而优秀产品更多的时候是使用了更好的角度来观察问题并给出更好的解决方案。
我们这里没有提到功能，因为我们把功能理解为支撑完成任务代称目标的手段，在一些不好的产品中你会发现，功能堆积了很多，却只是为了解决一些低优先级目标和次要问题。
为了必要功能的易用性目标，我们完全可以放弃一些其他功能的设计，实际上，功能设计越少，反而用户越能感受到产品功能的强大，这是因为用户在产品使用过程中慢慢发现的功能，就更加顺利的重复使用。和我们的直觉相反，对于我们愿意花时间去学习并使用的功能，客户却懒得去弄。
4. 定义产品原则/Define your Product Principles
现在，关于用户需求和体验你已经形成了一些具体的想法，但是在整个产品的开发过程中，你还会面临无数的决策，再加上对于产品每个人的想法都不尽相同，所以指定一套产品规则可以让产品实现过程中做到有原则的取舍，走向成功。比如TiVo就定义了以下原则：
- 它是个娱乐设备/It’s entertainment, stupid
- 它是个电视/It’s TV, stupid
- 它是视频/It’s video, damnit
- 一切都很自然/Everything is smooth and gentle
- 没有深层次/No modality or deep hierarchy
- 尊重用户隐私/Respect the viewer’s privacy
- 可靠的应用，就像电视/It’s a robust appliance, like a TV
eBay的产品原则：
- 易用/easy to use
- 安全/safe
- 好玩/fun
5. 原型和测试产品概念/Prototype and Test the Product Concept
产品团队时常犯的错误就是对于产品规格过于自信，往往导致产品已经进入了Beta版本后，还需要做大的改动，这样很难做出优秀的产品。
我们可以通过各种原型测试，提前验证产品的需求和设计，这样既能提前发现问题又容易变更解决。
可行性验证/Feasibility Testing
工程师和架构师充分调研各种方案的可行性，也许有些尝试最终是无法实现的，但是有些方法途径被验证是可行的，这样心里才有底。
即使发现一个问题完全无法克服，那么更早知道这一现实也是非常重要的，如果是在产品开发过程的后期才发现这一点很可能束手无策。
可用性验证/Usability Testing
你的设计师将与你紧密合作，提出展示产品功能的方法，以便不同类型的用户可以了解如何实际使用产品。
在可用性测试环节，往往会发现一些被忽略的需求，也能发现一些伪需求，你应该多次迭代测试最终才能给出一个成功的用户体验方案。
产品概念测试/Product Concept Testing
可行性和可用性测试的通过，并不能保证客户会为此产品买单。我们需要知道用户有多喜爱这个产品或者评价我们正在做的事情，产品概念测试就是为了解决这个问题。
通过原型（也许是一个评估版本软件，也有可能是个3D打印模型），让用户能够进行最真是的操作，这样才能得到最真实的反馈。
之前原型测试有两个障碍，一是原型构建工具的匮乏，二是不了解原型和产品的差异，让原型的偏见影响到产品开发。现在这两个障碍都以小时，让人们更容易进行有效的产品概念测试，验证产品的概念是否真的被用户所接受。
6. 明确假定，并提出疑问/Indentify and Question Your Assumptions
如果你理解了问题，那你就应该知道哪些是做的假设，并对这些假设进行确认。
人类天性使然，对于一些做的既定假设我们无法感知，往往导致我们因为一个蜡烛而放弃了寻找灯泡的可能。就像在天文学早期，人们从未质疑过地心说这个假定。
7. 记录下来/Write it Down
因为PRD是面向团队所有人，所以记录下来很重要。
拘泥于形式，重要的是内容，具有可读性和可维护性，相对出厂的产品来说，我们并不那么在意PRD的美观。
PRD由四个部分组成：
产品目的/Product Purpose
就是画目标。
这个是团队的目标，当然越清楚越好，要确保目标的描述包括以下内容：
- 给出你要解决的问题，而不是解决问题的方案
- 产品对象是谁，公司？客户？用户？
- 细节描述很重要，前提是全景必须清晰。
- 描述产品使用场景
记住，虽然头脑风暴、口头讨论会有很多好的想法和方案产生，但是如果没有记录到PRD中，那就等于什么都没有。
特征/Features
产品需求的规格描述重点依然是需求本身，需要的呈现的也是需求，而不是解决需求的方法。
功能需要进行交互设计描述和用户场景描述，对于每个功能和相应的用户体验要清楚，然后给工程团队赋予更多的灵活度来找到最佳解决方案。
明确特征和对应用户的关系同样重要，当需要砍掉某个需求的时候，可以清楚的知道给哪些用户带来的具体影响。
发布标准/Release Criteria
发布标准并不是一成不变的，但是在PRD中应该确认最核心的标准，一般包括以下内容：
- 性能
- 可扩展性
- 可靠性
- 可用性
- 可支持性
- 本地化
日程安排/Schedule
产品的时间规划也许是最难的一部分，如果时间不能做到确定，那么规划肯定没有作用，对于时间规划应该描述时间范围的背景，动机以及目标窗口。只有这样，你整个团队才有可能和你一样为了目标窗口而努力，做出市场认可的正确产品。
8. 优先级/Prioritize
对于需求列表，产品经理一般会进行分类，比如：
- 一定/must-have: 必须完成的需求，如果没有完成，产品就无法上市。
- 想要/high-want: 非常想要的需求，希望可以出厂的时候完成这些需求，但是也不会因为需求没有完成而推迟产品上市。
- 有更好/nice-to-have: 锦上添花的需求，也许当前版本没有完成，但是产品团队会一直保持关注，希望后期的版本能够完成。
分类很好，但还不够，将需求从1到N进行优先级顺序排列会让产品往好的方向发展，原因主要是：
- 市场不等人。为了赶着上市砍掉一些功能是常见。你肯定希望团队先做重要的，最后在做简单的。
- 在整个产品开发周期中，随着问题的提出和解决，团队会因为能力提高而增加一些重要功能，优先级可以让你更好的做到权衡利弊额。
PRD是一个持续的过程，思维的敏锐或者懒惰直接导致产品的成功与否，决策越早，成本越低，也给后续的工作留下足够的时间进行工作计划。
9. 测试完备性/Test Completeness
此时，PRD初稿已经完成，接下来就是验证其完备性。比如工程团队是否足够理解产品目标？QA团队是否有足够的信息来编写测试用例？
产品决策人看了PRD后，可能会提出一些增加细节描述的要求，完成这些事情后，PRD就算合格了。
10. 持续管理产品/Managing the Product
把PRD贴在靶子上，在产品实现过程中，当遇到问题的时候就应该先去参考下PRD，如果PRD里没有涉及该问题就添加到PRD里。产品经理的工作就是按照PRD的要求快速解决问题，然后将这些决定记录在PRD中。
有了PRD的精确描述的帮助，任何时候去回顾产品过程的时候都会比较容易，因为只有针对PRD中合适的段落内容就可以了。
PRD是个有生命的文档，对每一项功能对实现保持跟踪记录。任何用于帮助描述PRD中的需求和目标的信息都可以涵盖到PRD中。
编写PRD过程中常见陷阱
“看花容易绣花难”，一个清晰的、有用的PRD比说的还要难，这个过程中会有各种陷阱，让人猝不及防，这里简单罗列以下常见的陷阱。
可用性测试做的太少或者太迟/Too Little or Too Late
如果从没进行过产品可用性测试(Usability Testing)的话，看到下面两种情况也不要惊讶：
- 真实客户对产品的反应是非常挣扎
- 很快就知道要做哪些来解决问题
需要做到的事情有：
- 多轮测试必须在计划里
- 测试要在需求阶段进行，而不是产品后期，因为那时候也许根本无法进行必要的改变了。
- 产品经理和设计人员如果在测试现场，会非常有帮助
- 更多关注人们的行为而不是说话，言行不一是人类的天性。
- 核心架构师，工程师或者产品经理观察测试环节同样很有价值，这样他们可以跟严肃的看到目标客户的好恶。
- 如果团队没有可用性工程方面的专家，建议通过外包合作
你不是客户/You not Customer
错误假设，“如果我喜欢产品，我的客户也会这样”。
什么和怎样/What versus How
在产品需求中，我们往往会无意识的深入到解决方案中，而忽略了解决方案面对的需求，特别是一个产品经理非常了解解决方案的时候，就会把具体使用的技术，方法放到PRD中，这会有很多负面影响。
首先，意识到问题和解决问题的方案的不同。一个问题会有很多不同的解决方案，如果使用解决方案来描述问题的话，就会给工程团队引入一些可能是错误的假设。
其次，拟定的解决方案会阻碍团队寻找更优方案，面向问题才能发现更多的技术和创新方法。
最后，产品经理如果越界进行解决方案定义，就会对工程团队形成挑战，解决方案是工程团队对产品实现的最大贡献。
细节太少/Too Little Detail
如果细节无法覆盖到，在盲区就会产生一些问题。
对于盲区，团队人员就会根据自己的经验进行假设，而这些假设也许就是错的，但是自己却不知道。
有些问题是必须在构建阶段才会暴露出来的，做到完全有预先准备也是不可能的，但是如果你想尽可能的减少这类问题，就只能通过让产品团队尽早复审产品规格，知道盲区在哪，心里做好错误假设的防备。
细节太多/Too Much Detail
与上述“细节太少”相反，如果细节太多，也会让团队因为无法完全理解细节到而导致沟通失败，或者因为为了满足这么多细节而导致产品无法赶上最佳上市时间。
当然细节多与少和具体的产品方向有关，对于一辆车或者一架飞机来说必须严格按照细节，而互联往产品则要粗放一些。
少即多/Less Is More
“投入更对的资源把产品功能做的更丰富，去攻占一个市场”，这是直觉想法，然而成功的产品往往反直觉的。
对于科技型产品，每一项功能的加入都会导致成本提高，主要体现在复杂度提升，维护成本高，客户支持成本高，等等，
实际上，在科技含量高的产品添加功能是成本很高的，往往会得到的会更少。因为添加功能会导致复杂度提升，增加客户支持成本，增加成本。保持产品的专注，才能把产品打磨好。
“The main thing is to keep the main thing the main thing” from Jim Barksdale, former CEO of Netscape Communications.
当然这并不意味着拒绝增加新功能，持续进化和满足客户期望是产品提升竞争力的重要过程，但是对增加功能应该做到审慎对待。
不少产品都有完美的开始，随着开发变得越来越臃肿，最后已经失去了最初的目标。
工程驱动需求/Engineering-Driven Requirements
工程师常常会以新技术或者难度大（有成就感）来说服产品经理完成一些本不该是产品需求的功能，所以产品经理应该保持对产品价值的专注，可以聆听团队的需求，但产品经理才是对产品最终负责的人。
“定义一个可以通过努力来实现的好产品，而不是不能实现的产品，或者让工程构建他们想要的产品”
客户驱动需求/Customer-Driven Reuqirements
与工程驱动想法，有些需求是来自销售或者市场人员，是他们和客户讨论交流的结果。
“在产品定义这个问题上，市场人员应该扮演的是辅助角色，而非主导角色”。
产品经理应该非常深入的理解客户问题，拥有足够的操作空间来提出一款产品满足大群体客户的需要。
对“定制需求”保持警惕，这往往是销售或者市场人员为了拿到订单用于和客户做的交换条件，“定制”意味着和通用版本的冲突，如果不冲突就会作为功能添加到通用版本里了。
对于初创公司来说，接受“定制需求”是非常普遍的营销手段，听起来问题不大，实际上这是一个明显的斜坡，一旦陷下去就很难往回爬，所以应该竭力避免。
产品业务的本质是开发一款产品能够被大多数客户成功使用，任何与其相反的目标都是危险的。
冲动也可以理性/Emotion Can Be Logical
一个成功的产品形成的过程中，冲动时常扮演了很重要的角色，不但是产品开发，即使公司运营也是如此。
参考工程团队评估需求的建议，产品经理往往会放弃一些优先级低的需求，但是这样以来产品会变得毫无亮点，实际上如果有冲动要求必须完成一些功能的话，产品就会表现出极大的竞争性。
有些功能的优先级也许未必很高，却起到“神秘调料”的作用，少了这个味道会让整个产品失色，所以明确哪些功能可以起到这个作用就变得非常重要，产品原型测试就可以帮助你找到这些功能。
标准化只会好上加好/Standard Is Better then Better
产品需要创新，但是不是在已经有了标准化的领域，你可以想象如果一辆租赁的汽车门锁位置很特殊，一个手机拨打电话的方式和其他手机也不一样，用户体验肯定是让用户困惑，而且为了这些刻意的创新还要额外投入很多资源，不要刻意的追求让产品看起来与众不同。
“Standard Is Better than Better”
如果你的产品用到了客户既有的知识和习惯，客户会更加欣赏你的产品，才有机会让他们尝试更多的创新。专注于价值本身的创新才是有意义的。
缴税/Pay Your Taxes
当产品迭代多次后，工程团队会以各种理由提出重构产品，包括可持续性，可扩展性，安全性，性能优化等方面，他们会把继续迭代下去比喻为在纸牌构建的房屋上工作，随手可能会崩塌。
实际上很少有产品可以经受重构，主要原因是客户并不能看见重构带来的价值，他们只会感到什么都没有变化，除了工期推迟以外。
为了避免陷入这种境地，我们对于每个版本的更新要预留空间用于优化基础，比如框架和性能，如果这些变化用户能感受到，作为产品经理就应该介入负责，否则就是白白的浪费钱。
需求和设计的差别/Requirements versus Design
一个困难的问题是，需求规格是否应该包含设计规格。需求是说明“What”, 而设计是“How”, 但是中间设计是描述产品应该有的样子以及希望和用户之间的交互模式。
注意，这里的“设计”是指用户交互，并不涉及内部系统和程序实现。
正反观点认为需求应该包含设计，因为：
- 需求和设计是耦合的，一起组成了用户体验。他们之间会相互影响。
- 如果不包含设计，设计完成后，需求需要大的修改
- 你将从设计过程中学到产品应该是什么的重要信息
- 一个包含设计的需求对于产品开发团队非常有用，因为他们可以更清楚的理解他们需要构建什么
反方观点则是不应该包含设计，因为：
- 只有需求完成了，一些活动才可以进行，包括设计，架构，应用，测试计划等工作，如果因为设计而推迟需求确认，会延后整个工程。
- 影响需求的不仅仅是设计，还有实现过程
- 我们越早开始，越早能明确问题
正反观点都有一定道理，然而就整体来看，大多数案例是这样的，一旦架构和应用开始进行，再回头进行更改基本很难，因为有很多理由可以拒绝，技术的，文化的，…
不幸的是，如果设计过程发现的确要变更需求，那么即使很麻烦，也必须能够改变。 这就是为什么最好尽可能地推迟架构和实施工作，直到完成设计为止，因为设计阶段的需求变更的成本远远低于构建产品的时候。
在eBay的经验告诉我，把设计放在需求里，直到设计完成后再开始应用开发。利用现代强有力的原型工具，即快速又成本低廉的创造产品模拟器，可以得到非常有价值的用户反馈。
总结/SUMMARY
在定义产品的过程中，“能够保持向市场传递价值”非常重要。来自竞争对手，消费者，架构等的干扰很常见，你需要理解这些需求，但是最重要的还是记住价值。