Don't let anyone rush you with their timelines, as everything in life happens according to our time, our clock. ——Daviiwong
PRD是什么？
A product requirements document (PRD) is a document containing all the requirements to a certain product.
迄今为止，这是我知道的关于产品需求文档（PRD）最好的字面定义，完整表达了产品的一切。
- 让周边用户明白一款产品应该做什么
- 让专业人士定义一款产品应该怎么做
不揣测、不定义，只是准确传达需求，让技术专家给出需求的最优解。
A PRD is written to allow people to understand what a product should do.
PRDs should, however, generally avoid anticipating or defining how the product will do it in order to later allow the professional and technical engineers to use their expertise to provide the optimal solution to the requirements.
需求来源生活，产品经理体验生活，切身感知需求。需求宽泛，因而需要从两个维度理解产品需求文档：
- BRD/MRD和TRD的连接器
一个观点发酵于用户、客户（MRD）->产品经理产品化（PRD）->技术研发可视化（TRD）。
- 向上对MRD内容的继承和发展
- 向下将MRD内容技术化
- PRD产品需求的百科全书
狭义上，PRD侧重对产品功能和性能的描述，广义上，完整包含产品的战略和战术。内容上，可阅读、可理解、可衡量。
- 战略上：市场调研、产品定位、目标用户、竞品分析...
- 战术上：需求范围、功能内容、结构框架、业务流程...
这一系列文章内容侧重的是战术思考。
产品效率工具的定义
产品需求文档的本质上是一个产品工具（product tool，简称Pt），是产品经理的刻画外部客观世界的媒介，一种表达方式。人们普遍认为只有技术研发才是非常专业的工作，并拥有特有的行业开发工具，如微软visual studio、Code，苹果Xcode，而产品经理的工作都局限于经验性的操作，没有任何专业性可言。
NO. 产品经理是一个强专业性的工作。
很多产品经理的工作是从写产品需求文档开始的，我也不例外，并且我一直都觉得很幸运，因为这是一件有确定性的事。产品三年工作至今，我似乎更加喜欢借助PRD输出需求的本来样子。随着工作需要、个人理解，产品工具——产品需求文档/PRD持续迭代，最大程度适配解决问题的效率，刷新最优解。
在产品设计过程中，写产品需求文档是一件极为有仪式感的事。因而，一直以来我更愿意称之为<设计文档>。
产品工具之《产品需求文档/PRD》设计文档的全过程：
一、设计文档的三个前提
《礼记·中庸》有言：凡事预则立，不预则废。从产品需求文档的定义出发，发现文档不是目的，而是确定的结果。因而动笔之前，需要做好三个方面的准备工作，这里不赘述细节，仅给出概括性内容（计划以独立文章详细描述）。
1、前提一：需求管控
得到用户的诉求，沟通确认用户基本需求后，借助需求工具实现需求的量化管控。我们需要将想法梳理转化为结构化、可实现的产品需求。
- 列出圈定产品功能特性、内容范围
- 画出产品结构图、核心业务流程图
- 设计信息架构图，指出重点元要素
- 规划产品路线图，绘出迭代roadmap
保证产品经理对产品需求的理解，为产品需求文档注入一定的可靠性、准确性。
2、前提二：原型设计
当我们清楚知道产品的需求之后，产品需求由概念化阶段进入到图纸化的阶段，验证制定的用来满足用户需求的解决方案和界面设计的可行性。
- 快速绘制草稿，推演讨论假设
- 敏捷工具定型，模型灰度验证
- 完整原型交互，细致考虑落地
论证需求产品化的流程MVP，增强产品需求文档的易理解、可视化、可理解。
3、前提三：文档输出
需求管控、原型设计完成了产品需求的预备粗加工，进一步置于一个怎样的表达范式中对外呈现。一个基础文档内容结构是对需求内容的扩展和压缩。
- 设计文档信息内容
- 设计需求信息内容
- 匹配需求内容结构
有很多穷尽信息的手法，借助思维导图、表格文档，再将文字内容文档化。
这些准备帮助PM/用户清晰的理解产品需求，并且越来越清晰。当完成以上三个准备工作，产品经理对需求已了然于胸，写文档自然如有神助，而不是一堆不知所云的YY之词。
二、PRD的输出形式
产品经理迭代至今，产品需求文档可依赖的交付载体日益多样。起初，我是不愿意讨论形式的问题的，因为过于强调形式无形之中会反向削弱需求内容本身的重要性。三年产品一线亲自实战，我逐渐意识到在一个好的形式的的加持下，传递表达事半功倍。主流的PRD形式：
- WORD文档，易于存档
- AXURE原型，简化阅读
- 云协同工具，实时同步
所述三种形式一致采用了“文字+图片”的表达元素，而工具一切的迭代都为提高内容输出的效率。做产品的同学都有一个共同感受：有时候，时间确实很紧。
除了要选择PRD的表达载体，那么文档内容本身的容量和密度还需继续判断，从文档内容粒度上讲，产品需求文档/PRD分为：
PRD内容结构取决于：
- 产品需求粒度，是从1到N老产品的小幅优化，还是从0到1的新产品全新开发；
- 团队协作模式，是独立团队版本全量开发模式，还是全域内需求分发模式；
我曾切碰到文档交付的麻烦，刚入职新团队时，对新团队的分工协作模式一知半解，就自以为是沿用以往日的PRD模式交付，不符合要求，影响理解效率而被邮件投诉。
产品需求文档（PRD）是一款产品的全生命周期的记录，知晓每产品的每一个细节变化的原委。
产品需求文档（PRD）是一款专业的产品管理的效率工具，产品经理的必须掌握的专业产品工具。
【产品经理的效率工具】系类将以主题形式呈现，下一篇将分享《产品工具之产品需求文档/PRD》实战篇，设计一个产品需求文档/PRD，敬请期待。
生如白溪，一苇以航。
我是白苇，很开心在产品世界遇见你。
Date：2018年10月01日 6:00am
