PRD做不好,评审就是在直播吃翔

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

u=2769421979,3380392265&fm=23&gp=0

今天将讲解对于产品经理最重要的文档——产品需求文档(PRD)。

题目说PRD做不好,评审就是在直播吃翔,这事Glen一点都不夸张,搞不好,未来你也有机会体验一下。

  1. PRD是什么?
  2. PRD闭环:如何写一篇优质的PRD
  3. 注意事项

PRD是什么?

可以说,产品经理最重要的工作就是跟团队说清楚需求,只有说明白了需求是什么,才能让开发、设计、测试等去进行后续的工作。PRD是产品经理说明需求的不二选择。

什么是PRD?

PRD,产品需求文档(Product Requirement Document,PRD)的英文简称,这是一个产品经理为了跟其他项目成员说明需求的重要文档,也是PM参加需求评审会时,你的成果作品。

你可能还不知道需求评审会是什么,那我就简单讲一讲。需求评审会就是产品经理提出需求跟大家PK,让大家评估产品经理提出的需求,然后决定后续工作的会议。几乎所有的开发、设计、测试都会有忙不完的活,你凭什么让他们把你的需求优先开发,这将严重考验你和你的PRD。如果搞不好,你会被开发、设计、测试从头到脚批一遍,那个场面,就像在直播吃翔。

至于为什么会搞不好,很大程度就是产品经理没有把需求的各方面思考清楚,哪怕有一个逻辑没有思考清楚,或者漏掉了某个步骤,团队的其他人就会向你投来怀疑的眼光。如果一次评审会议中你被多次怀疑,那么不用想了,你就是在直播吃翔。

PRD是给谁看的?

首先,PRD是给产品经理自己看的。产品经理提出一个需求,那么实现这个需求的功能、逻辑,通过书写PRD的过程,能够慢慢梳理出逻辑。有人说:”我做高数微积分题全用心算完成,你那些功能、逻辑,我都能想得清清楚楚”。如果你真是这种人,那么拜托你,请加Glen私人微信,我要膜拜一圈。然而,这并没有什么卵用,因为别人做不到。。。

其次,PRD是给团队的其他人看的。一个产品经理,即便能够在脑海里想清楚所有的功能、逻辑,但是他不能保证团队的其他人也能在头脑里想清楚一切逻辑。所以,产品经理需要通过输出PRD,让团队其他人员理解需求的逻辑。

再次,PRD也是给老板看的。产品经理需要做某一个产品,在跟老板申请资源的时候,给出一份清晰的PRD能够让老板看明白你到底要做什么。

你知道PRD有多重要吗?

PRD的重要性,怎么夸大都不过分。

首先,PRD有证明需求的作用。你口头跟开发、设计、测试说一个需求,他们可能也口头上答应帮你做。然后,可能就真的没有然后了。。。接近项目上线,你突然发现他们没有做你的需求,这时你再去找他们,他们完全可以说你没有提出过需求,那场面,直接就是在吃翔。所以,产品经理需要认真写一份PRD,通过需求评审后,邮件群发给开发、设计、测试等大爷,有文件留底,到时候他们就赖不掉了。

其次,PRD有证明PM的作用。很多公司将PRD的修改次数作为作为评判PM水平的标准,还可能作为PM升级评定的参考因素。如果一个产品经理写的PRD平均修改次数过多,那将严重影响升级评定。

PRD闭环

PRD闭环

做产品无时无刻都需要思考产品闭环的问题。PRD作为需求的说明书,更是需要体现产品闭环。完成下面的步骤,你就能够写出一份优质的PRD了。

你的目的是什么?

这个是一份PRD最重要的地方,其实做一个产品,或者实现一个功能/逻辑,都不是困难的事,但是你得想好为什么要做这件事,或者说,你要确定做这件事所获得的东西是不是你自己想要的。这个问题想不清楚,后面的都是白搭。比如,你准备做一个游戏活动页,本来目的是为了拉新,但是目的没有把握好,后面做成了留存,那么你的KPI很可能就“呵呵”了。

实现目的所需要的功能?

在目的已经清晰、明确的前提下,PM得好好思考实现该目的所需要的功能,这些功能是实现目的的必经之路。最好给出功能列表,一个功能点都可以单列一条,并且和测试用例一一对应。

还可给出功能的应用场景,方便团队其他人理解该功能的作用。比如,一个简单的用户在某活动页兑奖的情景:

  1. 用户在购买某服务后,得到兑奖网址
  2. 用户输入该网址后,弹出活动页
  3. 用户点击“领取奖励”按钮,页面弹出注册/登录框,用户输入账号密码,登录成功,领取奖励

列出了功能点后,还需要对功能列表里的功能进行排序,得出 优先级 。暂时不做的需求,也要事先提出,放入需求池。

完成功能需要的逻辑?

这部分其实就是将功能分成很多小的功能点,比如一个兑奖的功能,可以分拆成注册、登录、第三方登录等小功能点。实现了每个功能点的逻辑,就组成了整个兑奖功能。

这部分,我感觉是 实现产品体验的最重要阶段 。实现一个功能的逻辑,如何做到让用户使用起来不复杂,同时能够让开发工作量不要太大,同时还能让大部分情景能够正常触达正确的结果,这不是一件简单的事。

异常逻辑、危机处理?

大部分用户能够正常使用功能后,就需要思考一些异常逻辑和危机情况了。这一部分非常考验产品经理的逻辑思维,从深度、广度两个方面全面考验。这一部分也最容易被团队其他人发现逻辑漏洞,分分钟让你感觉在直播吃翔。所以,这一块大家要加把劲,争取想出每一种异常逻辑,做好危机处理。

还是以兑奖活动为例子说明,一个兑奖活动页,目的是为了让某客户端装机量上升,那么必须设定该活动页必须在该客户端中输入,才能跳出兑奖网址(该客户端带浏览器功能)。那么异常逻辑可能就有:

  1. 用户不在客户端里输入网址
  2. 用户在断网情况下在客户端/其他浏览器输入网址
  3. 用户超过活动时间后才输入活动网址

…………

争取需要的资源

完成上面的步骤后,就需要跟项目组要资源了。

  • 项目成员 :完成产品开发工作所需的程序员(前端、后台、运维等),设计师(交互、视觉),测试,运营,商务等。
  • 硬件资源 :服务器,宣传物品等

数据反馈

这部分也是非常重要的,你做出了一个产品,肯定是需要知道它的市场反馈如何,得到反馈后,才能决定下一步该怎么走。这里就需要设计数据反馈系统,订立考核指标。

  • 访问量
  • 转化率
  • 留存率
  • 用户活跃天
  • 产品收入
  • 任务、活动完成量、质量

完成以上步骤,一个完整的PRD闭环就做好了,这下子,可以去找其他人PK了,做得足够认真的话,应该就不用直播吃翔了,可以挺直腰板当大爷了。这个世界就是一个“ 要么你是大爷,要么我是大爷 ”的世界,各位还是争取自己当大爷吧。

注意事项:坑,还是很多的

这部分说明一下具体写PRD时,需要注意的事项。

换位思考

写PRD一定要时刻想着换位思考,你得想着你的文档是给开发、设计、测试等看的,语言上尽量好理解,尽量不要用形容词,描述功能时,可以尝试用开发的逻辑去思考书写方式。

不要求大求全

这部分是我踩的一个深坑,我之前总想着把所有的逻辑都整理在一个流程图上,然而这在很多情况下是不可能的,除非你做的这个产品比较简单。即便你真能够将所有逻辑整理在一个流程图上,那么这个流程图也会很复杂,不容易让团队其他人看懂。 功能最好分点说明,正常逻辑和异常逻辑分开说明

所见即所得

这是一个读图的时代,图片展现是最清晰明白的。有的功能点,逻辑比较复杂,这时可以考虑用原型图展现,原型图可以做到所见即所得。

实现进度如何?

在PRD之外,最好再做一个项目进度表,这份表格要做到及时更新,让整个团队知道项目的进度。

关于语病和错别字

一份优质的PRD,最好达到新闻稿的校验程度,基本不要有语病和错别字。语病和错别字太多的话,容易让大家觉得你很不严谨。

排版标准

排版一定要有一套标准,保证你的每一份PRD都按照同一份标准。排版力求美观大方,字体、颜色、字号、行间距等方面都需要有一定的选择。

好了,以上基本将PRD的理论知识介绍了一下, 我所说的,可能都是错的 。说了那么多,其实PRD的作用就是让其他人帮你干活。一个极致的情况,模仿全栈工程师,我提出一个“全栈产品经理”的概念。当一个产品经理强悍到精通策划、前端开发、后台开发、设计、测试、运营、商务等,那么这种人我称Ta为“全栈产品经理”。

如果你是全栈产品经理,那么上面我说的关于PRD的东西可能对你来说都是垃圾,你自己就能做完所有的事情,请你务必要加我微信,让我膜拜你一圈。但即便你是全栈产品经理,能一个人完成所有工作,但是完成时间肯定会很长,效率肯定会下降。所以,广大PM兄弟姐妹们,咱们还是老老实实写PRD吧!

感谢阅读!

#专栏作家#

Glen ,微信公众号:JiGlen,人人都是产品经理专栏作家,一名来自中山大学的产品经理。爱看书、喜欢码字、愿意走出去看世界。产品路上刚起步的新人,不喜欢严肃、高冷的氛围,喜欢在幽默中完成任务,力图成为 史上最幽默产品经理 ,欢迎交流。

本文系作者授权发布,未经许可,不得转载。

随意打赏

提交建议
微信扫一扫,分享给好友吧。