产品新人系列(一)|PRD宣讲,应该关心什么问题
大部分人刚开始做产品经理时,都会经历过需求评审会上被多方Diss的场景。这篇文章,作者分享的经验,可以帮你平安度过。
产品新人面临的第一个难关就是需求宣讲总被开发Diss怎么办?本文从三个角度解答。
- 需求评审是什么
- 好的需求评审的标准
- 可能遇到的问题及应对办法
一、什么是需求评审
- 通常是一个会议:会上由产品经理传递产品方案和结论,让开发、测试都了解需求的细节和最终设计方案。避免开发辛辛苦苦写完代码,结果跟产品输出的方案大相径庭,导致双方撕逼打架。
- 需要什么:PRD文档+低保真模型/高保真模型
- 参与人包括:前端、后端、测试、UED、SE(架构师)、算法工程师(可选)等。
二、好的需求评审的标准
分点陈述,思路清晰,要求明确。
- 文档逻辑全面:产品更像规则的制定者,方案需要覆盖所有场景,包括功能影响范围、页面/功能流程、按钮交互逻辑。(这个要跟开发提前沟通)。
- 后台逻辑完整:比如涉及的接口和查询逻辑,异常情况判断。
- 演讲有重点:开会的时候技术可能没那么认真去听,所以一定要讲重点。必要时可以点名提问。
注意:⚠️会议是同步结论,而不是讨论。在会议主要讨论产品方案,技术问题是技术实现的问题,讨论角度不要跑偏。
三、可能遇到的问题及应对办法
会上一定会被开发质疑方案、甚至被你的产品同事质疑方案,这个时候要内核稳定,精准过招出击。
1)这个功能为什么要做?/做这个功能有什么意义?
问题拆解:问出这个问题,多半表明开发不愿意接受你的需求,可能是出于工期太满、难度太大、功能复杂的原因。这时候我们要给出一个答案,让开发自己说服自己,这个需求是有意义的。
应对策略:需求来源+优先级+功能价值+实现成本
例子:这个需求是XX领导提的(来源),希望能在10月份上线(优先级),有了这个功能之后用户可以实现学生认证,拿到多种权益,带动学生群体销量(功能价值)。工作量也不大,评估了是10个人天左右(实现成本)。
2)这个功能为什么要这么做而不是那么做?
问题拆解:开发觉得你的方案复杂,有更优解。
应对策略:
- 会前:一定要穷尽所有方案,考虑利弊,并可以提前和对应的开发沟通。
- 会中:理智阐述自己的想法,并询问开发他觉得更好的方案是什么,并展开讨论。方案影响因素:用户体验、功能影响范围、复用性等等。
- 会后:如果方案还有争议,会后再跟开发沟通。(此条不建议,优先把问题在会上解决是最高效的)
3)比问题多更可怕的是没问题!!
不怕开发提问,就怕开发不提问!这说明可能开发没有认真听你的方案!因为再简单的功能,都一定会有一些点是你可能没考虑到的。所以遇到没人提问要及时调动情绪,甚至可以点名对应的开发,看看对功能的理解是否到位。
四、真实案例
案例一:
刚开始做产品时,只知道自己埋头苦捋功能流程,梳理完之后再自己做一个设计出来。只跟产品沟通,没有跟技术沟通就上了评审会,结果因为功能逻辑漏洞太多,被驳回,开了二次评审。后续在开会前都会反复check方案的完整性、合理性,与至少一位开发沟通后再上会。
案例二:
功能有争议时,被技术一怼,就会被带跑偏,跟着技术的方案走。有时也会被领导带着走,他说啥就是啥。没有自己的立场。比如,一个欢迎弹窗,可放可不放,有人质疑太麻烦,我就不放;一个卡片样式,有图无图都可以,一旦被质疑,我就会跟着对方的节奏走。被带教的产品说,“产品要有自己的态度,一定要强势,不能被轻易改变”。只有你才能对用户负责,一些可做可不做的功能,一定要想清楚做不做,然后坚持自己的看法。
五、好的PRD文档参考
对产品来说,永远是思路>文档,但是一个好的文档可以反过来帮你check思路是否完整。
本文由 @猫头鹰的碎碎念老家 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
我经常是在跟业务方沟通完需求后,自己先预想一个解决方案或者设计思路,然后找开发确认可落地性以及有没有其他非业务层面的系统影响问题;一般开发都会给你一些建议和思路,可以基于与开发讨论的结果优化自己的设计方案。这样在需求评审的时候,比较好。但是需要注意的是,我个人觉得需求的沟通是两层,既要跟业务确认,也要跟开发确认的。并不是非得到需求评审的时候才去跟开发沟通,当然每个公司情况不一样。
对的,非常同意,有产品方案后要先跟开发和需求方预沟通,来调整方案。需求评审同步的应该是最终的确定版方案,请所有开发和测试一起审视。
写得不错,特别是找技术先过一遍这一点。