如何写出一份可以征服研发的PRD？

                                                你连PRD都要被怼，还叫什么产品经理！

应该算是第一篇文章，我觉得标题起得应该还算不错，嘿嘿嘿嘿～～
其实我今天就是想和大家聊聊：PRD 「产品需求文档」以及如何写好一个PRD。
说得夸张一些，PRD的好坏直接决定了产品经理基本素养。曾经有一段时间，我对所有产品面试者的要求是，带一份PRD过来。如果面试过了，我会再看看PRD。为什么？因为面试能骗人而PRD很难骗人。因为这个原因，曾经被我枪毙了不少面试过关的童鞋。
我曾经看到过很多产品童鞋在PRD的评审会上，直接被研发怼得下不来台，也见过一些产品用一份PRD就把台下的研发搞得热情高涨，恨不得马上开工把产品做出来。
下面我就和大家说说，一份能够征服研发的PRD应该如何完成。
一份合格的PRD，应该至少包括以下五个基本要素：

产品背景：讲清楚这个产品为了什么而做；

可量化目标：产品上线后，奔着什么目标而去；

产品的基本运营方案or逻辑：产品上线后，怎么样保证产品的内容可以快速推广落地；

交互稿：交互逻辑清晰的交互稿；

产品逻辑描述：能够把产品内在逻辑写清楚的正文；

我看过的RPD里，绝大部分只包含4、5这两个部分。所以大家明白问题出在那里了吗？
下面我和大家讲解一下各点要怎么写、注意点是什么。
1. 产品背景
产品背景就是：要给团队介绍清楚，为什么启动这款产品或这次迭代；目的就是：为了把团队的想法统一，这样研发、运营也会知道发力点在哪里。
在产品背景里至少要交代清楚2点：

有数据支撑的产品、业务现状是什么样的。举个例子呗，举个例子呗，举个例子呗，举个例子呗，举个例子呗，举个例子呗，举个例子呗

产品要解决什么问题。这个问题描述得越细致就越好，也就是通常说的足够聚焦，千万不要大而空洞。比如解决人类吃饭问题，这种看着就没营养。如果足够聚焦，那么可以改成解决非洲某个贫困村庄的吃饭问题，这样就会具体很多，而且看上去也容易下手。

我举个真实的栗子，这个是在需求评审时，某PM用的产品背景介绍：



按照以上的内容罗列，其实不用说，整个团队也都知道，我们接下来的产品是为了解决物流速度慢的问题。通过有理有据的说明，被怼的概率直线下降，大家只会觉得这个太应该做了。
2. 可量化目标
可量化目标，这个东西就比较简单了。就是产品上线及运营一定时间后，预期产品、业务所产生的可量化变化情况。
这个时候很多童鞋会说，“啊啊啊啊，我做的东西没法量化呀～”之类的话，这种情况，按我前老板的说法就是：凡事不能量化的事情，一律都是没想明白的！言下之意就是：不能量化的事情咱们不干，就是那么霸气！
还是前面的栗子：解决人类吃饭问题，那么解决了多少叫解决，是一千万还是一个亿？吃饭问题怎么定义才叫解决，是一日三餐还是一日两餐甚至是保证一日一餐？如果这个问题要量化，那么至少要也应该写成：确保现在一日一餐的5亿人口，能够变成一日两餐，且每餐要保证XXX热量的摄入。所以，不能量化是因为没有想到问题的本质上去。
当然，还有一种情况，可能可以不要有量化目标，那个就是传说中的「老板项目」。不过你如果有足够勇气，敢于正面刚老板一次，我估计大部分老板一定会给你一个量化目标的。
还是上面的那个若干年前的产品，我把目标晒出来给大家看看：

其实定一个目标并不难，难点在于这个目标的合理性。
除了老板拍脑袋之外，主要的方式有：

参考行业通用标准；

参考竞对标准；

通过逻辑推导；

……

以后有机会这块可以详细讲讲。
3. 产品基本策略及运营方案
产品策略：就是产品本身需要覆盖哪些内容。运营方案：就是上线后，如何推广运营，保证产品能够快速落地。
没人使用的产品肯定不是好产品。产品策略是能够保证产品不会半途而废的要点。在很多大公司，产品上线没人鸟的情况太多了，这时就需要事先准备好靠谱的运营方案。
一般来说，第三点是绝大部分产品所欠缺的。在很多产品眼里，产品上线就完了，剩下好不好，估计要看“运气”。但事实恰恰相反，一个优秀的产品，在设计之初就会有策略和最基本的运营推广方案。
还是以解决人类吃饭问题为例子：
产品策略就是：贫困地区一律改种土豆（土豆的亩产高，适应性强），基本运营方案就是：选择100个贫困村庄开始试点，逐步推广等等。有了这样的内容作为依托，能够让整个团队放心跟你走。
还是上面的那个若干年前的产品，我把策略和方案也弄出来给大家看看：

红框部分就是产品策略，蓝框部分就是基本运营方案。大家看看感受一下，实际上的策略和方案比这个详细很多。如数据产品应用中就包含了搜索权重、活动报名等内容。
4. 交互稿、产品逻辑描述（PRD正文）
这两个内容，我放在一起说。因为这个是一般产品经理日常最最长用到的东西，也是一个基本功。
所以在这里，我只想提醒大家：交互稿和PRD正文，请做到有多详细就写多详细的地步。尽量不要省略，尤其不要让后端、前端、测试童鞋去猜你的意图。
在这里我不想整段的来贴PRD出来给大家，而是想举几个日常的例子，让大家能够感受一下：
[ol]

对于日期的描述。我经常看到PRD里面写【N天后，自动关闭】，那么这个天到底是自然日？工作日？节假日？还是说以事件发生的时间为起点，增加N * 24小时之后？

对于时间的描述。经常会有RPD里写【这里显示完成时间】，那么这个完成时间，到底要不要包含日期？时间精度如何是到分钟还是到秒？如果是到分钟，那么秒如何处理，是向上取整，还是舍去？
[/ol]
举个栗子，我再贴一小段RPD给大家看看：

大家可以看到在这一小段的内容里，包含了：

数据处理的细节；

异常情况的考量；

产品运营空间的预留；

……

这样的PRD正文，至少能够表明大家有对产品本身做了深入的思考。
到这里，一份合格的PRD的五个基本要素就说完了。
最后，我还想说：PRD其实表明了大家对于产品的通盘思考的结果，并不是单单的一个产品怎么做的内容。