B端产品经理如何开一个和谐的PRD评审会

产品经理在工作的过程中，最怕的就是评审，记得原来做技术的时候，每次产品妹妹抱着笔记本进入会议室，我们就有一种羊入狼群的感觉，每个工程师都跃跃欲试准备好怒怼产品，贯彻以一次评审通过为耻，以气哭产品妹妹为荣的评审精神；后来转型做了产品，发现真是天道轮回，互联网行业永远不缺杠精，自己的PRD设计的接近于高保真，需求带着十二万分的诚意，依然被怼的体无完肤。

随着斗争的不断深入，我也痛定思痛慢慢总结除了一些如何产品PRD评审的生存指南，尝试与技术团队融洽的开PRD评审会

1、突出你的业务专长

业务知识是产品经理的强项，而技术是弱项，哪怕你是一个技术职位转岗的产品经理，也不要用自己过去的技术背景来挑战当下的开发团队，这样做无异于自掘坟墓，试想设计一款套餐产品的报价功能时，如果你非要用SKU和价格属性的方式描述你需求，那最后大概率会演变成大家对SKU颗粒度探讨的技术细节问题上，既然做了产品经理，就要突出自己业务知识的强项，毕竟业务是你的主场，而技术永远是你的客场，所以在PRD评审会上一定要利用好你的主场优势，评审过程中尽量多用业务语言来描述你的产品，如果技术人员对某些关键词有疑问，再耐心解答。

2、先用价值来描述你的诉求

业内有句话叫“产品动动嘴，开发跑断腿”，在开发人员眼中，产品简直就是自己天天加班，找不到女朋友的罪魁祸首，每次评审会开发同学只会关注这个评审之后自己的工作量是否会增加，而不会关心产品的更新能给他们带来什么价值，所以在PRD评审时，一定要给开发人员讲清楚这个功能的价值，如果按时开发出来，对公司和产品帮助，毕竟产品做得好，能带来更多受益，开发人员才有工资拿，哪怕加加班赶赶工自然也就没话可说。

4、用流程图来配合你的需求

B端产品一般都是重业务的，所以功能的逻辑性很强，唯独也很多，往往一个功能，不仅要说明操作的流程，还要区分不同角色，不同组织，不同权限下的业务逻辑差异，如果只是通过语言和文字描述，很容易造成理解上的偏差，所以在描述功能的同时但请上来时候最好先给一个流程图，讲讲其中的逻辑关系，如果技术背景再强一点，最好用UML工具建个模型，也可以让技术人员刮目相看一下，对你的身份感也有些认同。

记一个B端后台产品的0-1诞生过程

6、给出实体间的关系

产品经理需要对你的需求进行一些技术化的改进，针对细化的业务逻辑，将实体拆出来，虽然说需要一点技术背景，但也不用真正像技术人员一样去设计模型，只需要定义出实体之间的n对m的逻辑关系，有了这个实体关系图，技术人员就会很轻松的设计出合理的数据库模型，对你的感激之心也会大增。

记一个B端后台产品的0-1诞生过程

7、用户故事的方式来表达需求

我们原来在迭代的时候，都是会将PRD拆分成若干的用户故事，用角色+场景+操作+权限+目的（价值）的方式来描述要开发的功能，UI和测试看完需求之后也大体能知道自己改怎么设计交互和测试用例，对你的好感度上升50%，评审会上可保持中立；同时开发人员根据你的描述也能预估一下技术难度和工作量，在心底默默的给你点赞。

8、给出完整的字典信息

每个PRD上都要给出可选项的字典值域以及是否必选、是否可多选等元信息，首先这个东东是只有产品知道的，你现在不给后面也还是要给的，届时给就会落一句“早干吗去了，非等我找你要才给”之类的埋怨话，而且频繁发消息问你，也会埋下双方日后难以沟通的苦果之种，哪怕是再简单的可选项也要给出值域，例如性别选项框，如果值域你空着不写，不排除有些开发没事找事的问你，人妖用户填什么？

9、PRD要考虑技术的体验感

最后就是输出PRD，将PRD当成一个产品，而技术人员就是你的用户，如何提升你用户的体验感呢？我的做法是将PRD的排版按“页面说明”、“业务逻辑”，“数据字典”分开，充分考虑技术人员的阅读习惯，减少他们肉眼去扫重要信息的时间，而且不同角色的开发人员，对信息获取也是不同的，就这样一个小小的改进曾经让我在产品复盘会上收到过两个正字的好评，全是“prd写的很清楚，思路清晰”，同技术人员的关系也提升不少，说白你如果在开发PRD的时候设身处地的为技术，UI，测试同学着想，他们也不会难为你。

记一个B端后台产品的0-1诞生过程

作为产品经理完成一次圆满的PRD并不会得到掌声，只不过少了一些埋怨和质疑，但这就是我们的日常工作啊，当你在会议室送走开发人员静静合上笔记本的时候，就是下一场评审战役的开始。**