PRD是什么？
迄今为止，这是我知道的关于产品需求文档（PRD）最好的字面定义，完整表达了产品的一切。
不揣测、不定义，只是准确传达需求，让技术专家给出需求的最优解。
需求来源生活，产品经理体验生活，切身感知需求。需求宽泛，因而需要从两个维度理解产品需求文档：
这一系列文章内容侧重的是战术思考。
产品需求文档的本质上是一个产品工具（product tool，简称Pt），是产品经理的刻画外部客观世界的媒介，一种表达方式。人们普遍认为只有技术研发才是非常专业的工作，并拥有特有的行业开发工具，如微软visual studio、Code，苹果Xcode，而产品经理的工作都局限于经验性的操作，没有任何专业性可言。
NO. 产品经理是一个强专业性的工作。
很多产品经理的工作是从写产品需求文档开始的，我也不例外，并且我一直都觉得很幸运，因为这是一件有确定性的事。产品三年工作至今，我似乎更加喜欢借助PRD输出需求的本来样子。随着工作需要、个人理解，产品工具——产品需求文档/PRD持续迭代，最大程度适配解决问题的效率，刷新最优解。
在产品设计过程中， 写产品需求文档是一件极为有仪式感的事 。因而，一直以来我更愿意称之为< 设计文档 >。
产品工具之《产品需求文档/PRD》设计文档的全过程：
《礼记·中庸》有言：凡事预则立，不预则废。从产品需求文档的定义出发，发现文档不是目的，而是确定的结果。因而动笔之前，需要做好三个方面的准备工作，这里不赘述细节，仅给出概括性内容（计划以独立文章详细描述）。
得到用户的诉求，沟通确认用户基本需求后，借助需求工具实现需求的量化管控。我们需要将想法梳理转化为结构化、可实现的产品需求。
保证产品经理对产品需求的理解，为产品需求文档注入一定的可靠性、准确性。
当我们清楚知道产品的需求之后，产品需求由概念化阶段进入到图纸化的阶段，验证制定的用来满足用户需求的解决方案和界面设计的可行性。
论证需求产品化的流程MVP，增强产品需求文档的易理解、可视化、可理解。
需求管控、原型设计完成了产品需求的预备粗加工，进一步置于一个怎样的表达范式中对外呈现。一个基础文档内容结构是对需求内容的扩展和压缩。
有很多穷尽信息的手法，借助思维导图、表格文档，再将文字内容文档化。
这些准备帮助PM/用户清晰的理解产品需求，并且越来越清晰。当完成以上三个准备工作，产品经理对需求已了然于胸，写文档自然如有神助，而不是一堆不知所云的YY之词。
产品经理迭代至今，产品需求文档可依赖的交付载体日益多样。起初，我是不愿意讨论形式的问题的，因为过于强调形式无形之中会反向削弱需求内容本身的重要性。三年产品一线亲自实战，我逐渐意识到在一个好的形式的的加持下，传递表达事半功倍。主流的PRD形式：
所述三种形式一致采用了“文字+图片”的表达元素，而工具一切的迭代都为提高内容输出的效率。做产品的同学都有一个共同感受：有时候，时间确实很紧。
除了要选择PRD的表达载体，那么文档内容本身的容量和密度还需继续判断，从文档内容粒度上讲，产品需求文档/PRD分为：
PRD内容结构取决于：
我曾切碰到文档交付的麻烦，刚入职新团队时，对新团队的分工协作模式一知半解，就自以为是沿用以往日的PRD模式交付，不符合要求，影响理解效率而被邮件投诉。
产品需求文档（PRD）是一款产品的全生命周期的记录，知晓每产品的每一个细节变化的原委。
产品需求文档（PRD）是一款专业的产品管理的效率工具，产品经理的必须掌握的专业产品工具。
【产品经理的效率工具】系类将以主题形式呈现，下一篇将分享 《产品工具之产品需求文档/PRD》实战篇 ，设计一个产品需求文档/PRD，敬请期待。
生如白溪，一苇以航。
我是白苇，很开心在产品世界遇见你。
Date：2018年10月01日 6:00am