修订记录：

修订记录

一．认识PRD（概念）

PRD：描述产品需求的文档

MRD和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流程图

包括业务流程图和页面流程图

核心业务逻辑vs业务流程vs页面流程

工具：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一定要及时更新，否则会影响其他工种