新闻资讯门户
互联网、云计算领域最新资讯
首页 > 互联网

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

  1. 对于日期的描述。我经常看到PRD里面写【N天后,自动关闭】,那么这个天到底是自然日?工作日?节假日?还是说以事件发生的时间为起点,增加N * 24小时之后?
  2. 对于时间的描述。经常会有RPD里写【这里显示完成时间】,那么这个完成时间,到底要不要包含日期?时间精度如何是到分钟还是到秒?如果是到分钟,那么秒如何处理,是向上取整,还是舍去?

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

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

  • 数据处理的细节;
  • 异常情况的考量;
  • 产品运营空间的预留;
  • ……

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

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

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

 

未经允许不得转载,或转载时需注明出处:西部数码新闻资讯门户 » 如何写出一份可以征服研发的PRD?
分享到:更多 ()

网友评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

中国领先的互联网域名及云服务提供商

为您提供域名,比特币,P2P,大数据,云计算,虚拟主机,域名交易最新资讯报道

域名注册云服务器