首先，产品需求文档，Product Requirement Document，简称PRD，其存在的目的主要有3个：对产品需求的完整描述、开发测试的唯一依据、后续历史追溯和备案。有如下两个重要的基本原则：
第一，其终极目标是指导设计和开发，建立对于项目的共同理解 。所以在书写的时候，要对阅读对象的理解能力和知识水平以及对这个项目的了解程度都要有个大致的判断，确保每个人都可以看得懂。既不倡导事无巨细地记录，也不倡导凡事只讲个要点。
第二，文档是一个不断更新的过程。在产品概念设计阶段，根本没有办法写设计的具体需求和测试计划。早起产品文档扮演的角色就是记录那些已经确定的概念和目标，到产品中后期，大家都明白做什么了，也确定了一些用户流程和屏幕细节，文档的整个骨架才会慢慢支撑起来。这意味着，我们一定要做好版本控制。
理想的PRD文档具备4个特点：
完整——各功能点无遗漏、无缺失；
高效——从方案确定到文档完成耗时短；
准确——无歧义、结构合理、便于开发测试人员阅读和理解；
低成本沟通——讨论、评审、后期修改，流程合理，沟通顺畅。
一篇完整的产品文档包含十个部分：
1. 产品概览
大概用三四句话左右高度描述一下我们会做一个什么样的产品以及为什么要做这样一个产品。
2. 问题与机会
描述我们通过这个产品需要解决的问题，或者是我们正在寻求的机遇。一般来说，这段话的作用在于让人阅读后明白我们为什么要花时间做这件事，以及明白了这件事的意义所在。
3. 产品目标与范围
基于SMART原则来制定的一系列产品目标。其中最重要的是要定义什么是产品的成功。这一点在产品开发时越早提出来越有优势，慢慢会发现是一切决策的依据。
产品范围不仅定义我们决定花时间去做的事，也包括了决定放弃的功能。明确把这些不做的东西也列出来，有利于在未来讨论时不用反复出现“那我们做不做这个？做不做那个”的讨论。
4. 产品需求
产品需求指的是一小列通过用户的视角撰写的声明。例如“我希望通过这个产品我可以实现……”它不需要包含具体的实施细节，也不需要写具体的界面元素。它们只是对于产品成功的一些具体表现。
5. 产品原则
这里面会提到一些设计和技术的原则，例如facebook的设计原则就是：universal, clean, consistent, useful等等。不同的产品会需要不同的原则。例如对于2B的一些企业级软件，安全和易用是非常高的原则。然而对于一些消费者产品，趣味性和创新可能更为重要。
6. 用户故事
之前已经有人提到了用户故事，里面讲到了用户故事的三大元素：谁，是什么，为什么。这是一个比较直接的表述。一般在设计师眼里，会考虑更多的场景，动机，用户行为以及最终的价值实现。所以一般一个产品，会支持若干个优先级的用户故事。每个用户故事是描述了一段独立的end-to-end的使用体验。它包括：用户画像，使用场景, 使用意图, 步骤, 产品价值（产品如何帮助用户实现价值），以及优先级。
一般优先级最高的进入MVP（minimal viable product), 然后依次类推，优先级最低的进入backlog，大家有空有资源再考虑实现。
7. 设计细则
这里包含的是设计的细节。产品经理需要提供原型图，也可以让设计师来提供更加专业的设计稿。
8. 衡量指标
这一块讲的是具体如何衡量一个产品的成功。指标性的东西来帮我们判断自己的努力是否有了预期的回报。
9. 依赖物
这一点比较容易被人忽略，但是往往很重要。因为产品经理是对一个产品最有全局观的人，所以一定要说清楚，哪些交付物得走在哪些交付物的前头，交付物和交付物之前是什么样的关系，这样对应的负责人才有一个清晰的认识，不致于误了开发时间。
10. 测试计划
测试计划是一系列需要在产品发布之前做的测试，确保在各种使用情境下，产品都不会有意外发生。测试计划一般需要产品经理与测试一同完成。
最后，有一些容易忽略的细节，特别是初级产品汪们一定要牢记：
所有页面都要说明“从哪来，到哪去”
各种错误提示、断网跳转等
输入框里各种限制：为空？字符？字数？空格？
别写“与线上保持一致”
大版本一定要有上线时间表
原文来自：公众号：产品经理日记
