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

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

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

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

您的赞赏,是对我创作的最大鼓励。

评论( 22

登录后参与评论
  1. 期待自己走上PK台的那天。。。。 :oops:

    回复
  2. 很好的一片文章,虽然我不是做产品需求的,但是有这样的一篇需求文档的话,我们的工作将会轻松很多

    回复
  3. 可否直接贴一个实际工作中的PRD看看?

    回复
  4. 看了这么多关于PRD的文章,总算这一篇能看懂。

    回复
  5. :lol:

    回复
  6. 天天看我们产品经理被pia翔,那画面太美我不敢看。。。

    回复
    1. 回复

      产品经理要努力提升PRD水准,这样才不会总是被 :idea: 。。。

  7. 你倒是说下好的标准。 :arrow:

    回复
    1. 回复

      完成闭环,没有大的逻辑错误,通俗易懂,所见即所得 :idea:

  8. 上次看见别人直播吃翔了,过几天我也要直播了,好怕啊,怎么办? :roll:

    回复
    1. 回复

      没事,大胆假设,小心求证 :mrgreen:

  9. 我想认识加下这个史上最幽默产品经理,可是为啥在加微信公众号的时候不添加一个微信二维码让我扫一扫呢,而是让我用爪一个一个字母得去按呢?这个是遵循了那个产品思维?

    回复
    1. 回复

      因为人家不让放二维码啊 :?:

  10. 这是团队之间不和谐吧,很多功能并不是产品一个人说了算的,是要和开发、设计一起协同思考和讨论的,所以产品和其他人并不是对立的,而是求同的。

    在开发过程中也可能遇到突然的情况,比如某个细节当时开发没想到,现在遇到问题了,这个功能点可能就做不了了,需要重新修改PRD,这也是常事。

    回复
    1. 回复

      你说得也有道理,不过,最好还是让PRD错误少一些。

    2. 回复

      恩,赞同!把错误尽量提前预防、防病于未然是成本最低的方法~

  11. 直播吃翔那画面太美我不敢看。

    回复
    1. 回复

      小心哦,搞不好你也有机会体验 :mrgreen:

  12. prd闭环,这一节,“做产品无时无刻都需要思考产品闭环的问题”此句有语病。

    回复
    1. 回复

      感谢提出,下次我会注意的 :grin:

  13. 新人学习,很通俗易懂,多谢。

    回复
    1. 回复

      :roll:

加载中