快好知 kuaihz

如何写出一份可以征服研发的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出来给大家,而是想举几个日常的例子,让大家能够感受一下:

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

对于时间的描述。经常会有RPD里写【这里显示完成时间】,那么这个完成时间,到底要不要包含日期?时间精度如何是到分钟还是到秒?如果是到分钟,那么秒如何处理,是向上取整,还是舍去?

举个栗子,我再贴一小段RPD给大家看看:

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

数据处理的细节;

异常情况的考量;

产品运营空间的预留;

……

这样的PRD正文,至少能够表明大家有对产品本身做了深入的思考。

到这里,一份合格的PRD的五个基本要素就说完了。

最后,我还想说:PRD其实表明了大家对于产品的通盘思考的结果,并不是单单的一个产品怎么做的内容。

 

作者:超级大头,微信公众号:产品经理两三事

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:写出  写出词条  征服  征服词条  研发  研发词条  可以  可以词条  如何  如何词条  
产品

 B端项目调研提纲的设计与思考

在本文,笔者将从自己参与到B端项目的实践过程中,分享每个节点所参与到的工作内容。一起来看看。相信很多做过调研的同行,特别是新手,调研过程中经常会出现准备不足、内...(展开)

产品

 产品经理“进化”史

广义上来说,PM的历史即人类的历史。——P布斯石器时代让我们回到原始时代,每个部落都是小型社会,成员不过几十人,社会分工是提高整体生产力的不可或缺的条件。S部落...(展开)