修订记录：
一．认识PRD（概念）
PRD：描述产品需求的文档
MRD和PRD之间的区别
1.PRD的目的
最主要的目的：使产品团队、公司管理层、客户以及其他相关部门对产品的认知与预期达成一致
2.PRD的对象
开发、设计师、测试、老板、项目经理、产品经理、运营、市场、销售、客户、财务……
3.PRD的表现形式
文字型：word、google docs、Wiki、
交互稿或原型：axure原型
PPT、图片、影像
4.PRD的原则
完整、准确、清晰、简洁、稳定、可执行
二． 如何撰写PRD（实操）
1.PRD的结构
文档头
产品概述
功能性需求
非功能性需求
2.文档头
A文档命名
推荐规则：【PRD】+产品名+产品版本 例如：【PRD】Product Hunt v1.0.1
B修订记录
推荐规则：文档版本+修订日期+修订内容+修订人 例如：
C目录
建议直接使用Word的自动生成目录功能
3.产品概述
A产品背景
规则：生态+需求可靠性+价值+成本
例如：Product Hunt的产品背景www.producthunt.com
（1）垂直化社区正在崛起，特别是科技与创业领域的网站，如人人都是产品经理、GrowthHackers.com等都在飞速发展（生态）
（2）早期通过linkydink制作的MVP共有30名内容生产者以及170多名订阅者参与，思路得以验证（需求可靠性）
（3）可以通过广告以及数据变现（价值）
（4）技术风险较低（成本）
B用户定位
规则：目标用户+需求（场景）描述
例如：Product Hunt的用户定位
（1）产品经理——乐于探索、把玩和学习有创造性的新产品。同时，他们也在持续关注工作上的潜在竞品。
（2）天使投资人——经常投资一些新项目，并积极寻找那些值得投资的初创项目。
（3）普通爱好者——喜欢了解一些新东西
C产品目标
规则：做什么+做到什么程度
例如：Product Hunt的产品目标
（1）将Product Hunt打造成分享与发现APP、硬件等各类最有创造性新产品的地方
（2）使用编辑精选的模式，使用户体验更接近于订阅博客
（3）营造产品极客扎堆的社区氛围
4.功能性需求
A产品框架
业务逻辑图
功能所处的流程，流程所处的模块
工具：MindManager、百度脑图……
Tip：建议引导读者直接查看Axure等原型文件的目录
B流程图
包括业务流程图和页面流程图
工具：Visio、ProcessOn
基础：用户视角的输入→输出
进阶：开发（客户端、服务端）、运营视角的处理流程
C功能总表
规则：功能名+功能简述+优先级 例如：
最好每条功能都能对应之前提到的产品目标
D功能详情
（1）用户界面
原型图、交互设计图
Axure绘制的产品原型
（2）界面描述
例如：
Tip1：在跳转关系后面标注对应原型（UI）图的页面编号
Tip2：若元素为填写的表单，则需在元素说明中注明：是否必填、校验规则、报错提示
（3）用户用例
例如：
Tip1：在流程后面标注对应原型（UI）图的页面编号
Tip2：在备选及异常流程前标注从基本流程的第几步开始
5.非功能性需求
性能需求、统计需求、营销需求、法务需求、质量需求、安全需求、运营需求、财务需求……
A统计需求
例如：
Tip1：统计事件的名称尽量简洁
Tip2：须精确描述触发统计条件的场景
Tip3：有些前端页面上的小改动会引发早前的统计代码不可用，需提醒开发确认
三．产品经理专业视角下的PRD要点（升华）
理念：PRD=产品
1.老板的需求
需求：主功能、预期收益
对策：结合功能的重要程度，而不仅仅是根据前端页面展示顺序撰写功能描述；将收益指标加入【产品目标】章节
2.设计师的需求
需求：单页复杂度、页面数、风格要求
对策：在没有UI的情况下使用原型图作为PRD的【用户界面】；针对异常状态页面要有明确的定义；对风格或在设计上有任何特殊需求都应在【界面描述】的备注栏中注明
3.开发的需求
需求：字少些、字多些
对策：精简文字，用图与表格等结构化方式描述需求；能用些伪代码更好；多琢磨，想清楚再写
4.测试的需求
需求：逻辑详尽
对策：完善【用户用例】的非基本流程；开发过程中及时更新PRD；与测试一起制订一份PRD描述自查清单
四．可能遇到的问题（复盘）
问题1：如何维护PRD？
PRD一定是需要维护的，更新的地方最好用不同的颜色做标注，要改文档头。改动之后，要通知相关人。
问题2：用原型代替PRD好不好？
形式不是问题，关键是能不能尽善尽美的表述。相对来说，还是推荐文档。
问题3：写细还是写粗，这是一个问题…
太细致会显得繁琐，可能谁都懒得看。太粗放就起不到PRD应有的作用。
问题4：人人都想做产品经理？
五．总结
PRD一定要及时更新，否则会影响其他工种