如何提升产品团队整体PRD的输出质量?

玩新媒体,引流、转化、留存3大难题如何破?通过6周系统学习,这些问题都能解决。了解一下>>

本文作者从自身经验出发,结合案例对产品团队如何输出高质量的PRD这个问题进行了梳理分析,希望能给你带来启发与思考。

还是在做互助的时候,团队里有个小姑娘,虎头虎脑,很有冲劲。因为工作的原因,许久没有联系以前的小伙伴了。 前一阵子,突然接到她的电话,很是开心。

当然她找我也不仅仅是叙旧,更多的是关于团队管理的一些探讨。 我觉得有些内容还是挺有意思的,也就试着写一写。

一、望闻问切

搞清楚问题,是解决问题的第一步。

根据她的描述,大致是说研发团队吐槽产品这边整体输出的PRD质量比较低,需要反复沟通,影响整体的工程开发效率。

所以她的问题,一言以蔽之:如何提升产品团队整体PRD的输出质量。

我们试着拆解一下这个问题:

首先是”整体”,代表着团队目前人员能力参差不齐,有高手也有菜鸟。一般来说,主要是菜鸟拉低了团队的整体水平,其应为重点关注对象。

其次是”质量”,代表着受众(工程团队)对目前的质量不是很满意。一般来说,RD所说的PRD质量主要是指两点:

  1. 可读性差: 表述方式没有逻辑,关键信息要找很久,找到了还要读几篇才能理解的意思,或者还是无法理解需要和产品再次沟通确认。
  2. 内容不详细: 开发中需要的物料(文案/图片/逻辑)不全,需要提示PM补充。

二、对症下药

1. 使用模板

由团队水平最高的PM(可能是PMleader/也可能是组内的产品专家)制订一份模板1.0,并在团队内部讨论确认试用。

使用同一模板的好处有两点:

  • PM不用担心自己考虑的不周全,因为模板是团队最高水平的人出的,基本上该考虑的点都会以模块的形式体现。完成每个模块的填写,及时把该考虑的事情都考虑了。
  • 提升PM撰写PRD效率,类似于研发的开发框架。支持产品集中精力在每一个具体模块填写上。

2. 建立品控机制

  1. PM输出PRD (基于模板)
  2. PMleader评审: 把握方向/业务流程/核心逻辑
  3. PMteam评审: UE/文案/逻辑
  4. 工程评审: 引导研发积极反馈PRD工程盲区
  5. PM输出工程版PRD (前提: 已针对流程中暴露的问题,完成修改或解释)

3. 升级模板

没错,又是模板。

即使是组内专家写的模板,也不一定就会让团队买账。

无论是对于产品团队还是工程团队,管理者都要引导大家科学的思考问题。

明确方向正确性的同时,要承认任何经验性的东西都会有个本地化的过程(否则就是经验主义,生搬硬套),需要在各个流程中不断的复盘修正,这需要大家的支持。

产品团队leader善于引导团队成员积极捕捉异常(内部评审/工程评审中那些不同的声音),推进模板的定期讨论升级迭代。

进一步激发研发团队反馈的积极性与理解(能做到这点,即使你现在做的不是很好,产研的沟通成本也会降低很多,因为工程团队也会在这个阶段帮你消化一些隐形的工作量,例如减少不必要的争吵)。

4. 重新认识工程评审

在大多数产品经理的认知里,工程评审就是告诉研发”我需要你做什么”,这没错但不严谨。主观上的忽视了PRD中的存在的技术盲区(个人认为术业有专攻,这个盲区是一定存在的,是不是大小的问题),可能是经验不足,也可能是自负或是自欺。

组织工程评审会的时候,PM最好要强调一下评审的意义:目前的方案虽然经过PM内部评审了,但是还是会有些工程盲区无法完全覆盖,需要研发各位老板帮忙指出来(谦逊的暗示对方应承担的义务),避免给后续工程开发带来不必要的沟通成本,提升工程压力(暗示对方不履行义务的代价)。

三、缓解副作用

如下为管理者可能会遇到的一些挑战:

1. 新流程执行后,业务投诉产品决策流程过长,响应效率不如以前了

这种情况下,产品leader要主动引导业务方认识到事物本质: 你要的是交付周期(提出需求到上线)更快,不是决策周期更快。

  • 修改前: 没有品控机制,产品决策周期短,PRD质量低,产研沟通成本高,最终交付周期长
  • 修改后: 由品控机制,产品决策周期长,PRD质量高,产研沟通成本低,最终交付周期短

过程对业务方没有意义,结果才是最重要的。

2. 一些小需求的处理,使用模板是不是太形式主义了

这种质疑很有价值,可以考虑孵化一个敏捷模板,类似于绿色通道一下,快速孵化业务需求。

3. PMLeader 即要1v1的评审还要参加团队评审,会不会很浪费时间

这个在实操过程中确实有些小技巧,例如。

  • 如果Pmleader对1v1中的需求很有把握(一般是些小需求,非敏感类,该leader为此方面的专家或者团队规模比较小),可以直接批准进入工程评审,没必要在占用其他产品的时间,组织产品内部评审了。
  • 1v1结束后,作为PMleader一定要相关的PM把会议中的TODO(修改点)和自己过一遍,确保没有遗漏,避免后续的反复沟通与确认。
  • 人的精力毕竟有限,如果你管理的团队比较大,一定要领用好导师这个资源,来分担你方案把关的工作。

4. 团队水平差不多,没有高手

互联网就是最好的老师,团队的高手也可以扩展理解为互联网。

5. 工程评审的时候研发还是不配合

一般来讲,是如下的工作没有做好,才会发生这种问题:

  • 没有及时反馈工程评审中TODO的结论,又在开发过程中反复沟通浪费了很多时间,研发承担了很多不必要的工程压力;(这种情况,没什么说的,一次是经验不足,两次就是态度问题了,管理者要及时介入提醒或警告相关的PM。)
  • 每次工程评审被指出来的问题总是相同的,RD的意见并没有被实质性的尊重。(这种情况,应该是管理者的责任,不是在机制建立之初没有针对产品团队做适当的引导和启发,就是在机制执行过程中有些放水,自己都不去提炼一些问题孵化,其他同学自然就不会认真对待。)

四、医者仁心

当然管理者不应只满足于具体问题的解决,更应追求对事物背后抽象出的规律参悟,以达到一通百通的境界。

如下是我总结的一些常规解决问题的思路,仅供参考:

  • 搞清楚问题 : 不要扩散,一下子想很多问题。 还是要聚焦,一个问题一个问题的去解决;
  • 梳理好现状 :不要着急出方案,搞清楚现有流程,理解清楚问题的诱因。要相信充分的信息收集,是理性决策的基础。
  • 规划好流程 : 打样,逻辑上不通的,执行就别想有效果。
  • 推进好迭代 : 不仅要自己明白,还要引导团队明白。目标是清晰的,道路是曲折的。
  • 升华好意识 : 不同的业务需要不同特质的人员,这点需要在实践中不断总结,不断强调。团队管理包含物理和精神两个层面,两者缺一不可。

好了,就写这些吧,希望对一些产品leader有一些启发吧~

 

作者:吴天,微信公众号「竹林杂记」(ID:pmwutian)

本文由 @吴天 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!