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

本文作者从自身经验出发，结合案例对产品团队如何输出高质量的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协议