原标题：决战评审会——产品经理的打怪之路

本文从产品经理的角度，为我们盘点了一场好的评审会该是什么样的？面对可能出现的各种矛盾，产品经理该如何应对？

说起评审会，不论是刚入行的小白产品经理，或是资深大牛，一定都不会陌生。

我从事产品经理的工作3年，主持过、参加过的评审会大大小小有近百个。

回想起这个场合，联想到的词语有怒发冲冠（我怒或他怒）、扬眉吐气（磨叽了八百遍还是要乖乖做我的需求）、舌战群儒（一人舌战赢研发十人团队），也有语塞沉默（被怼无言，好吧我回去再想想），或一拍即合（万众一心众志成城）。

年轻的我时常感慨，为何每次剧本都不同。

评审会是各方一起讨论方案、充分沟通的重要场合，同时也会由于多方意见造成矛盾冲突。

那么从产品经理的角度看，一场好的评审会该是什么样的？面对可能出现的各种矛盾，产品经理该如何应对？

一、评审会上的矛盾有哪些？ 1. 产品经理和研发之间的矛盾

我常常思考，产品和研发这两种生物之间的历史矛盾根源到底在哪，后来逐渐认识到，非上下级关系中，所有提需求的和做需求的都存在天然的矛盾点。评审会也是这个矛盾的典型爆发场合，经常会出现的对话有：

A：我的需求是……

B1: “做这个有什么用”—研发对需求来源不认可，不赞同

B2: “你这个设计有问题啊”—研发对设计方案不认可，可能是方案的完整度或者可行性。

B3: “这个做不了”—研发对实现的复杂度提出质疑，认为代价太大。

以上三个回答任何一个可能都会让产品经理当场炸毛，如果再来几个回合，并且不再控制情绪的话，那么评审会就走向了它的注定结局—无结论无进展的撕逼大会。

2. 产品经理和老板之间的矛盾

产品和老板的矛盾通常会出现在前期的项目评审会上。 和研发的需求评审会不同，项目评审会是对方案的整体设计、可行性、合理性和市场需求进行评审，可能发起质疑的点会更多，也更加难以预测。

此外，产品经理需要应对不是职级平等的研发，而是公司高级管理层，这意味着对话会存在不平等，或许还会掺杂各部门之间或老板之间的复杂矛盾。

项目评审会上最致命的问题是被老板指出项目方案存在严重的缺陷，且不能在短期内克服。可能是技术实现上存在严重问题或与公司战略不符，这样的问题一旦出现，方案很可能面临流产。

另一个问题是被指出方案不完善，准备不充分的问题，虽说不足以致命，但是也会遭到老板的直接打击。例如，市场调研的结果不充分，没有足够说服力；产品的功能定位存在偏差；实现方案代价太大，整体得不偿失等等。

最后，即使方案整体没有被指出大问题，作为有资格指点任何问题的老板，可能也会对某个细节的产品功能提出意见，有时候还会被要求按照他的想法改进，而产品经理可能认为老板的想法并不优于自己的设计。

3. 研发自己之间的矛盾

试想一下，当产品经理拿着方案雄赳赳准备舌战群儒的时候，突然发现，对方辩友完全不朝我开火，反而内部明枪暗箭吵了起来。第一次经历这种场景的产品经理一定是突然懵逼搞不清局势。

当项目越大，参与的研发越多的时候，研发内部之间就很可能会出现矛盾。比较常见的有前后端之间的矛盾：一个功能是前端来实现还是后端来实现，彼此都觉得你做比我做更简单省事。所以有时评审会上表面双方都在diss需求，实际上是在互相diss。

另外，也有研发团队负责人和具体需求负责人之间的矛盾，矛盾点可能在于工期安排或具体实现方式上意见不一致，而这个矛盾在评审会上可能也表现为对需求的diss。

二、评审会应对策略 1. 面对老板：做充足准备，但不因权威而放弃思考

项目方案评审需要做全方位的充足准备，包括市场调研、数据分析、竞品分析、产品功能分析，而且在评审前应和研发进行一轮整体技术讨论，目的在于确认技术实现方案是否有明显阻碍。

另外，项目方案要获得自己直接主管的支持，通过直接主管能了解到更多公司层面的战略动态、项目评审要求和老板的关注点，做到心里有数。

进入项目评审会后，产品经理需要仔细应对各方提出的问题。如果是自己曾经考虑过的问题，需要清晰简明地陈述自己的调研结果和论证过程；如果不幸被从未预料到的问题降维打击，不如直接承认没有考虑到这点，并确定下一步工作。

再如果产品经理和某位老板就一个问题产生了争执，例如产品的某个功能，而经过一两轮的交流彼此互相没有说服。

这种场景我常常看到的结果都是产品经理自动认为老板说得都是对的，听老板的话既政治正确又可以偷懒省得再想。

然而产品设计具有整体性，尤其是某些复杂系统改一处功能会影响一片，所以盲目听从权威也可能会给自己挖坑。

所以，面对老板的“指点”，不如更进一步问清楚他为什么想这么修改，是否有其他更好方法达到老板的要求，也符合自己的设计原则？

这样的思考和做法都不难，只是在面对权威时，产品经理要时刻提醒自己不能放弃思考。

2. 明确优势，掌握主动

许多产品经理在面对研发时很害怕被技术知识压制，研发甩上几个技术名词就能掌握对话主动权。岗位知识的优势确实能在对话中碾压对方，所以反过来看， 产品经理的岗位知识积累也足够能压制研发，尤其是一些复杂系统设计时相关的业务知识（金融、仓储物流、教育等），或者是用户、市场相关的一手信息。

那么在阐述需求的时候，可以多用以上知识铺垫背景信息，让研发明确这个需求是经过严格论证的，不是一拍脑门想出来的。同样也可以用行业知识佐证产品设计的合理性，我之所以这么设计是有原因的！总之，明确自己的优势，获得对话中的主动权。

3. 听懂他说的话才是反驳他的第一步

听懂对方表达的意思，明白他的逻辑，才是发起反驳的第一步。

这一点从奇葩说的辩论就能看出来， 只有听懂对方的逻辑，拆他的论点再明确自己的观点才是说服人的过程，否则双方只是无休止地阐述自己的想法，根本没有形成有效沟通。

在评审会中，面对表达能力一般不太好的研发群体，要努力听懂他的言外之意，辨认出此时讨论的矛盾点在哪里，是在需求本身？还是研发内部的分工问题，或是工期问题？

产品经理不要把所有的矛盾都转化成自己和研发之间的矛盾，而是要尽量把对方和自己拉到统一战线，我们是一起完成一个工作。

4. 始终扮演问题解决者的角色

在评审会的讨论中，产品经理要始终扮演问题解决者的角色，不是对抗，不是撕，而是把握局面，不要让沟通陷入死胡同。

当方案遭到阻碍时，多问自己是否还有其他解决办法。

例如：当研发说这个设计太影响性能的时候，可以想想是否能另外通过分页、预加载等方法解决性能问题，而不要生杠“我的设计不会有性能问题”。

同时，面对技术方面的问题，产品经理要敢于大胆发问，引导研发解决问题。

例如研发在听到一个功能后，第一反应觉得实现起来很复杂，这时不要直接跳到“他说实现复杂就是想让我改需求”的假想里，可以理性询问难点在哪儿，能不能解决，或者是否需要研发内部再讨论一下。产品经理参与到问题解决的过程中，对构建彼此的信任也很有好处。

以上这两个技巧在情绪理智的时候都很容易做到，然而一旦到了针锋相对，矛盾爆发的时刻就很容易失控。

所以最后这一点尤为重要， 扮演解决问题的角色，要求产品经理在推进方案上比团队其他任何人要更坚定，而坚定意味着当团队觉得困难重重，负面情绪高涨的时候，产品经理需要理性看待当下的困难，寻找可用的资源来解决，不是一起沉迷于困难和矛盾中，无休止争论。

5. 善用沟通技巧，打造自己的人设

几乎所有的产品经理招聘要求里都有“善于沟通”这一条。在我看来，善于沟通的含义是能用别人理解和接受的方式表达信息，同时又能精准地理解别人反馈的信息。在评审会上， 善于沟通的本质在于提升效率。

关于沟通中的技巧，大家可以找专门的书来学习。我在这里想澄清的是，产品经理并不一定都要学成巧舌如簧。打造自己的人设，形成有效的信息交换即可。

例如：

• 我看过软萌妹子的产品经理，脾气甚好，温文尔雅，经常能让大家在讨论中多几分耐心。
• 也有扑克脸的大叔产品经理，不苟言笑但是总能理解每个人表达的观点并且提出更好的方案。
• 还有强势的御姐，虽然表达犀利，但有实力相配，还是会自然获得团队成员的信任。

还是那句话，形成有效沟通，把方案推进下去才是核心。

对产品经理来说，评审会绝非只有撕逼和争吵，理性看待会议中的各类矛盾，明白评审会在产品方案推进中的作用，找到自己的角色和立场。玩转评审会，你的方案才能真正变现！

本文由 @产品经理北极星 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议游戏网