PRD宣讲,应该关心什么问题

1 评论 1502 浏览 4 收藏 6 分钟

大部分人刚开始做产品经理时,都会经历过需求评审会上被多方Diss的场景。这篇文章,作者分享的经验,可以帮你平安度过。

产品新人面临的第一个难关就是需求宣讲总被开发Diss怎么办?本文从三个角度解答。

  1. 需求评审是什么
  2. 好的需求评审的标准
  3. 可能遇到的问题及应对办法

一、什么是需求评审

  • 通常是一个会议:会上由产品经理传递产品方案和结论,让开发、测试都了解需求的细节和最终设计方案。避免开发辛辛苦苦写完代码,结果跟产品输出的方案大相径庭,导致双方撕逼打架。
  • 需要什么:PRD文档+低保真模型/高保真模型
  • 参与人包括:前端、后端、测试、UED、SE(架构师)、算法工程师(可选)等。

二、好的需求评审的标准

分点陈述,思路清晰,要求明确。

  • 文档逻辑全面:产品更像规则的制定者,方案需要覆盖所有场景,包括功能影响范围、页面/功能流程、按钮交互逻辑。(这个要跟开发提前沟通)。
  • 后台逻辑完整:比如涉及的接口和查询逻辑,异常情况判断。
  • 演讲有重点:开会的时候技术可能没那么认真去听,所以一定要讲重点。必要时可以点名提问。

注意:⚠️会议是同步结论,而不是讨论。在会议主要讨论产品方案,技术问题是技术实现的问题,讨论角度不要跑偏。

三、可能遇到的问题及应对办法

会上一定会被开发质疑方案、甚至被你的产品同事质疑方案,这个时候要内核稳定,精准过招出击。

1)这个功能为什么要做?/做这个功能有什么意义?

——问题拆解:问出这个问题,多半表明开发不愿意接受你的需求,可能是出于工期太满、难度太大、功能复杂的原因。这时候我们要给出一个答案,让开发自己说服自己,这个需求是有意义的。

——应对策略:需求来源+优先级+功能价值+实现成本

——例子:

这个需求是XX领导提的(来源),希望能在10月份上线(优先级),有了这个功能之后用户可以实现学生认证,拿到多种权益,带动学生群体销量(功能价值)。工作量也不大,评估了是10个人天左右(实现成本)。

2)这个功能为什么要这么做而不是那么做?

——问题拆解:开发觉得你的方案复杂,有更优解。

——应对策略:

  1. 会前:一定要穷尽所有方案,考虑利弊,并可以提前和对应的开发沟通。
  2. 会中:理智阐述自己的想法,并询问开发他觉得更好的方案是什么,并展开讨论。方案影响因素:用户体验、功能影响范围、复用性等等。
  3. 会后:如果方案还有争议,会后再跟开发沟通。(此条不建议,优先把问题在会上解决是最高效的)

3)比问题多更可怕的是没问题!!

不怕开发提问,就怕开发不提问!这说明可能开发没有认真听你的方案!因为再简单的功能,都一定会有一些点是你可能没考虑到的。所以遇到没人提问要及时调动情绪,甚至可以点名对应的开发,看看对功能的理解是否到位。

四、真实案例

案例一:

刚开始做产品时,只知道自己埋头苦捋功能流程,梳理完之后再自己做一个设计出来。只跟产品沟通,没有跟技术沟通就上了评审会,结果因为功能逻辑漏洞太多,被驳回,开了二次评审。后续在开会前都会反复check方案的完整性、合理性,与至少一位开发沟通后再上会。

案例二:

功能有争议时,被技术一怼,就会被带跑偏,跟着技术的方案走。有时也会被领导带着走,他说啥就是啥。没有自己的立场。比如,一个欢迎弹窗,可放可不放,有人质疑太麻烦,我就不放;一个卡片样式,有图无图都可以,一旦被质疑,我就会跟着对方的节奏走。被带教的产品说,“产品要有自己的态度,一定要强势,不能被轻易改变”。只有你才能对用户负责,一些可做可不做的功能,一定要想清楚做不做,然后坚持自己的看法。

五、好的PRD文档参考

对产品来说,永远是思路>文档,但是一个好的文档可以反过来帮你check思路是否完整。

本文由 @猫头鹰的碎碎念老家 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 写得不错,特别是找技术先过一遍这一点。

    来自重庆 回复