【内附文件】如何写好PRD？

周末午休小憩一会，突然惊醒后坐着发愣，身边娃的声音似乎都离我很远，好似头埋在水底听岸边虫鸣，微弱、遥远但清晰。

 

原因是梦里被好几个读者问同一问题：“如何写好PRD？” 结合之前也有很多人想要一份万能的PRD模板，仿佛只要对着模板填上内容，PRD文档就非常完美。

 

是这样的吗？这里有写PRD的7条经验想和你分享下：

 

1.必须把需求文档当成产品去对待。需求文档的用户是整个产品项目成员。准确、详细且完整的需求背景和业务流程相当于产品的战略层；页面的布局和排版样式相当于产品的信息架构层和表现层。

 

说句实话，连需求文档都写不好的产品经理应该也做不出啥像样的产品。

 

2.需求文档的核心是需求，而不是文档。重点是理清楚需求能帮助哪些用户（客户）在什么场景下去解决啥问题，那么对应需求表现就是用户路径图、功能流程图和功能逻辑。如果写需求文档需要花费6小时，至少有4小时花在业务沟通、用户沟通、竞品调研和业务目标上，写文档和原型图的时间不超过2小时。

 

连需求都没有挖掘清晰的需求文档，算啥需求文档呢？

 

3.假如不确定需求文档的颗粒度，那就越详细越好。优秀的需求文档犹如和优秀的人沟通一样，应该是清晰简洁的，太啰嗦会让人厌烦。文档写的粗线条就会丢掉很多细节，团队成员无法理解意图。如果你无法把控这个度，宁愿写的详细点、啰嗦点，重点是能让项目成员理解就好。

 

需求文档别做成了无效内容聚集地。

 

4.图比结构重要，结构比文字重要。能用图讲清楚的，就要用图去说明。可以用功能架构图、流程图、线框图或者概念图。切记图一定是跟着逻辑走的。图能直观的说清楚目的，图也是和项目组达到共鸣的最小量尺。

 

同样，文档结构也是写PRD的核心点。主流程和分支流程拆分，把异常情况和通用需求有效整理，都会提高可阅读性和自查的效率。也能避免功能太复杂，遗漏细节。

 

5.在项目开发的PRD文档，建议通过原型图+逻辑的形式输出，提高项目组的开发效率，也方便随时纠错。而在项目结束后，最好还是用word文档保存，便于留存和追溯。因为当你接手历史遗留项目时，你会感谢为你留下项目开发文档和留存文档的前任产品经理的。

切记，别给接替者挖坑。

 

6.如果有可能，在写完需求文档后，放置今天再读一遍，大部分情况下你会发现之前没有发现过的问题。有时候一鼓作气出来的内容会有一定的局限性。之后反复的看，会有不同的建议出来。这和项目复盘是一样的。

 

同理，如果你有时间去看几年前自己写的文档和做过的项目，也能会有惊喜的收获。

7.PRD是产品经理传达产品思考的阶段成果，在这之前，需要产品经理好好理解业务。

 

以上7条建议，看起来像是正确的废话，但是你操作后就知道了。术的层面，我为你准备了原来写过的PRD文档、自检清单和在工作中用到的交互设计清单，在工作中非常适用。希望能帮到你。

公众号私信回复关键词：“文档”，即可下载。

 

John时不时会在朋友圈输出自己的思考，可以一起交流。John微信号：

John每篇文章必将经得起时间的考验。觉得文章不错，可以帮John分享下。感谢。