为评审发愁？8招带你走出产品评审困境

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

评审虽然是产品人的日常工作，但是仍然让很多产品人头疼。究其根本还是前期准备有疏漏，思考不够周全。练好评审这一招，需要从前期准备做起，如何完美都不为过。而评审中，更要见招拆招，助推产品上线。

作者：阿艺师傅

微信公众号：锌产品（ID：tntproduct）

题图来自 Unsplash，基于 CC0 协议

全文共 4795 字，阅读需要 10 分钟

—————— / BEGIN / ——————

湖畔大学产品模块学术负责人、著名产品人梁宁在《产品思维30讲》里提到了产品人，应用了丘吉尔的一句话“如果你到了地狱，那就继续保持前行。”

如果把产品日常工作中的一项重要内容——“评审”算作一个。那么，这绝对可以算得上是“走向痛苦中”去，而又不得不每天面对。

记得之前发生过程序员和产品经理因手机壳颜色而打架的事情，媒体闹得沸沸扬扬——真是一对生死冤家的既视感。

作为一枚产品人，笔者也深知，产品评审是推动产品落地过程中非常重要的一环。产品方案是否能通过是一项重要日程，做不好它，前期的许许多多的工作都白费了，还落一个不讨好的下场。

产品社群中，依然经常看到有产品新人甚至一些老油条在发问：

• 如何科学面对其他开发的怼？

• 如何优雅的回怼？

• 开发说这个功能实现不了怎么办？

其实绝大多数的问题并不深奥，但依然困扰着大家。评审不好，项目止步、没有NB作品、职业生涯受阻……各种心酸涌上心头。

如果遇到此类事情，有没有更好的办法去处理呢？

作为以解决方案为生的产品人，我们应该有自己的“解决方案”，去打破这些评审过程中遇到的“牢笼”吧！

下面跟大家分享8招带你走出困境的方法。在说这8点评审建议时，我觉得还是有必要去回顾一下这个关键词：会议。

只有知道我们做的是什么，才能做得更好。

一、会议是什么

在这里，并没有什么大咖开会议的绝技跟大家分享，只分享一本关于会议的书籍：美国Tim-hindel所著的《会议管理》。

在全球范围内，每天举办的大大小小的会议不下几百万场，而这些会议是否成功，是商务效率的一个重要指标。

我们可以想象，在旅途疲惫，穿越万里之后，来到一家公司参加一个合作协商的会议，在会议上并没有达到一些重要的成果。从投入产出比角度来看，这一趟旅途浪费的成本，平均每个经理人至少上万元；但后面，产出效果几乎为0。

产品评审会也是会议的一种，它的目的是达成某个决策和方案。当然，这是一种正式的、目标性极强的会议，既然要开，就要开得有效率一些；否则，走过场根本是没有意义的。

《会议管理》这本书把会议流程分为了准备会议、出席会议、主持会议。

1. 准备会议阶段

准备阶段要安排好时间、地点、座位等方面的工作。当然，有些公司在评审的时候，需要用到电视、投影仪、电脑等电子设备的辅佐工作。这方面需要提前进行调试和准备，防止在会议开始时再进行调整，让一干人在评审室里干等，确实也是沉闷的。

2. 出席会议阶段

提到了重要的5点：

1. 积极参与

2. 外表和讲话

3. 倾听发言

4. 处理问题

5. 做备忘录

3. 主持会议阶段

这本书里重点提及到了一点：研究出席者。

这并不是耍滑的需要，它的目的是知道参会人是谁，并且尊重与会人员。例如：在出席者中，包含了相关者（业务直接相关）、协助者（帮助完成某个功能或业务的解答等）、参与者（参与但不发言，主要做同步、理解内容等，例如运营、客服等部门）。

二、8招建议

基本了解了会议的情况后，我们会提出8招建议。

这8个建议，是针对我们熟知的8个被怼被质疑的场景，以及对应的解决方案。

场景一：为什么要这么做？

在评审会上，一上来你跟他们解释一通，这个功能怎么做，甚至零碎地把多个功能一起进行解说。

他们一脸懵逼，然后回了一句：“为什么要这么做？”参与评审的同事在理不清原因的时候，一般都会这么问。

他们的出发点很简单：人性的疑虑，他们疑虑你所设计或迭代的功能；背景是什么、为什么这个时间段就要做这个、是否有必要或做了有什么好处；甚至，从他们本身自由的需求、私心角度，也会进行质疑。

于是，你再次解释一通，总算把他们的疑惑进行安抚了；甚至，解释了一通，他们还是一脸懵逼。

为什么不提前进行说明功能的目的呢？而等到他们质疑时候才解释？实际上，这样浪费了前面的解说时间。

时间就是效率，浪费时间，就是降低了效率。

造成此类质疑局面的原因，在于想不清楚，表达不清楚；本质上，还是想得不透。

这里，推荐一个提问工具：丰田五问法（日本丰田专家大野耐一提出）。简单来说，针对一个问题，连续问5次，直逼本质的提问、层层递进。

以下是一些参考：

1. 为什么做这个功能？

2. 目的是什么？

3. 有什么优势？

4. 解决什么问题/？

5. 有什么数据、论据的支撑吗？

当然，还有其他的自我提问的方法，这里就不细说了。

场景二：这个场景/因素/……方面有没有想到呢？

假如你是某个电商网站的产品经理，电商集团需要对订单系统进行统一优化，优化方式包含了文案、ICON品牌识别、功能等方面。

作为产品经理，在评审会上，把优化的订单功能的页面，放在了订单详情页、列表页入口等位置。但帮助中心-订单的位置和订单结算的位置，你并没有考虑到。

毫无疑问，说开火，就开火。

开发或测试同事，会持续向你施压：

• “这个入口都没有啊。”

• “你让用户在订单结算这里看到的是旧品牌，在首页上看到新品牌，他们就懵逼了。”

• “你都没有想清楚，就来说。”

• ……

对方的立场告诉你，你的工作是处于盲目优化的地方，很多都没有考虑到。

作为产品经理，你会怎么办？

首先，心态放平，态度谦虚（确实是你想的不周到），记录下来，评审后及时修改并同步即可。

那么，如何处理这种被遗漏的情况呢？

推荐一招：MECE法则（互相独立，完全穷尽），MECE法则要求我们把各种相关的情况都要想清楚，不遗漏。当然，这是最佳状态。

在考虑事情的时候，我们不妨从时间轴、次序、渠道、相关性等方面进行考虑，把产品方案想得更加完善。

说不定，下次评审时，一些想不到的地方你都想到了，也许开发会向你投快来钦佩的眼光。

场景三：这个方案并不是最好的

在评审环节，我们也会遇到这个情况。那么，开发、测试、UI等同事，就这么来一句，或许会让你胆战心惊。

但别怕，应该这样处理：

• 如果是对方感觉不对，但又说不出为什么，那么，仍然按照这个方案，但可以底下再讨论。

• 有更好的方案。

我们也许不相信开发、测试对产品的品味（这当然是不对的，产品人需杜绝高高在上感），但他们确实提出了一些方案。

如果方案较为离谱，那么自然是不过了。反之，如果方案比较靠谱，你自己又觉得比你的好，怎么办呢？

接受、认同并探询细化这个方案。让他们帮你一起想方法，提高了参与度，何乐而不为呢？

要知道，评审会绝不是产品人一个人滔滔不绝的演讲，它也是一个沟通的会议。

如果开发或测试仅站在他们自己的角度，去吐槽这个方案（比如开发的技术难度较大、测试繁琐）。此时，你要做好你的坐骑了，径直往前走。

场景四：太啰嗦了，到底想表达什么？

评审会上，你自信满满地表达了一通，但遭到了评审参与同事们的不理解。

当你表达完成后，他们会质疑：“你到底要表达的是什么？”站在对方的立场，主要原因是他们确实听不明白你说的是什么；功能很多，他们听不出重点在哪里。

质疑的问题带来的痛苦，更多的是来自能力本身。试想，如果一句话能讲完的事情，要拆出2句话甚至5句话讲，听的人不耐烦，说的人也累啊。

何不简洁、高效一些呢？

这里有个训练小技巧：在你设计功能之前，看能不能用一句话表达出来功能的目的。

这里推荐一个工具：黄金圈思考法，通过提出what、how、why的方式，促使大脑思考和解答问题。

场景五：用户量有多大？开发成本太高了

这是让很多人“一句语塞”的话。真的，你告诉我用户量多大。如果很大，我立马给你开发。

用户量不好评估，难道就这样乖乖就范吗？

• “你能告诉我，微信开发语音对讲功能时，有多少用户量？

• 你能告诉我，微信开发“附近的人”的功能，有多少用户量？”

• ……

不好意思，还是通不过。——这叫只看趋势，不看自己。

当然，你也可以跟评审同事们讲，竞品都有这个功能了，我们为什么不做呢？——这叫只看竞品，不看自己。

“我认为、我觉得”，这些话也杜绝说（不是尽量）。

好，既然是你认为、你觉得。那么，为什么要这么做？你的判断被质疑了。于是，要么默默忍受，要么开启回怼模式，战火不断……

举个例子：

你在产品的订单列表上，增加了一个搜索功能。在评审会上，你把原型展示后，开发来了一句：“用户量有多大？”

如何做呢？这里的解决方案是：

• 可以拿量化的，尽量拿量化；

• 不可以拿量化的，拿自然而然的逻辑，简单到无法反驳。

杜绝：拿感觉、拿竞品、拿大咖、拿公司领导镇压……

什么意思呢？

量化的数据包含了：

• 你真的知道这块产品会有多少用户量；

• 你从市场同类数据中，找到了用户使用量。

你从兄弟部门的埋点中，拿到了这个比率；再乘以用户数，就得到使用量。——这是量化

什么是拿逻辑呢？

就是从A推导出B的吗，比如：美图APP，除了修图之外，能不能加个拍照呢？这是简单到不能再简单了，美图，就应该增加拍照功能。

当然，还有其他的方法，还有一个绝招。那就是开发非常信任你，你打个招呼，提了一些，他们立马就做。

这是建立在你的专业能力之上的，如果你是这样的人，请忽略刚才所提到的建议。

场景六：跟之前方案对比，这样做的目的是什么？好处是什么？

例如：某电商网站浏览记录入口功能，放在二级页面还是一级页面呢？评审会上开发问你，为什么要把入口前置？

对方的立场是：这是功能的迁移问题。

首先，请杜绝抛出这样的一句话：“这个功能很简单就能实现啊。”

好的，那我们遇到此类提问，如何解决呢？

此时，你要明确告诉对方，优化这个功能的作用和意义。

有以下的告知策略可以参考：

• 成本优势/投入产出比；

• 用户路径优势；

• 心智认知优势；

• 产品体验优势。

例如：把这个入口放在一级入口，用户会更加方便进入这个最近浏览的页面。之前调研了浏览记录页面的PV和UV，量级非常大，可见用户还是比较在意这个入口的，能减少直达商品详情页的路径。

这是从用户路径上的说明，其他几点你也可以进一步展开。

场景七：砍掉这个功能，不做

面对这个场景，辛辛苦苦做好的功能，说不做就不做，自然士气被打击了。当然，也不能糊里糊涂功能被砍掉啊！

咨询提出决定的这名同事，他/她的回答可能有以下几种：

• 功能太臃肿了；

• 很明显不合理，直接下答案；

• 看你不爽。

遇到这个情况，作为产品人，我们自然不爽。辛辛苦苦孵化的“功能”，咋能说不做就不做呢？

我建议以更加客观的态度去审视他们的回答。

如果功能真的是很臃肿，要倾听是否真的是这样。要知道，这种情况很常见。回顾笔者开过的评审会来看，确实是有许多的功能显得有些臃肿，这是考虑不周全所致。但如果真不是你的问题，那么就要据理力争。

可以从以下几个方面跟对方阐述，为什么要做这个功能：

• 强调产品的用户价值；

• 强调产品的企业价值；

• 强调产品的优势和解决的问题；

• 适当时候，可以拿上级领导指示说明（不得已）。

杜绝：一味强调产品功能是多么好。要知道，如果产品确实是好，评审要不一定过，现场的评判非常重要。

心态飘起来，跟对方硬抗，严重不建议。

场景八：历史原因，这个功能实现不了

这句话是不是听到油腻了？或者至少听过。

在评审过程中，如果听到开发这么说，也不要着急，你的工作还没有白费。

产品人要善于审时度势。此时，要跟对方进行进一步“切磋”。

那么，在“切磋”过程中，可能会遇到以下几个方面的情况：

• 是否真的实现不了？行动：妥协或坚持

• 是否有曲线救国的策略? 行动：采用

• 是否可以部分修改，功能也要实现？行动：妥协且坚持

告知对方，会后进一步讨论这个功能的取舍或采用其他的解决方案。

以上，就是8条产品人常遇到的问题及对应的建议了。

03

为了少走弯路，提高科学评审的能力和水平，还是建议产品人把评审这一步修炼好，做好产品前的准备功夫。

即使没有遗漏做得妥妥当当，在评审中还是会遇到许多的质疑、追问、妥协、被怼等情况。不用急，见招拆招，做好一个产品评审，为后续产品落地的硬仗（产品进度管理、突发情况等）做好准备。

这又是精彩的一仗了吧！

—————— / END / ——————

每个「在看」，都是一次鼓励 ▼