作者：
yixiang
来源：
锌产品（ID：tntproduct）
正文：4912字
预计阅读时间：4min
文章类型：产品经理·评审
湖畔大学产品模块学术负责人、著名产品人梁宁在《产品思维30讲》里，提到了产品人，应用了丘吉尔的一句话“如果你到了地狱,那就继续保持前行。”如果把产品的日常工作中一项重要的内容----“评审”算作一个，那么，这绝对可以算的上是“走向痛苦中”去而又不得不每天面对。
记得前1年发生过程序员和产品经理因手机壳颜色而打架的事情，媒体闹得沸沸扬扬，这真是一对生死冤家的既视感。
作为产品人一枚，笔者也深知，产品评审是推动产品落地过程中非常重要的一环。产品方案是否能通过是一项重要日程。做不好它，前期的许许多多的工作都白费了，还落的一个不讨好的下场。
产品社群中，依然经常看到有产品新人甚至一些老油条在发问：
“如何科学面对其他开发的怼”
“如何优雅的回怼？”
“开发说这个功能实现不了怎么办？”
这些问题的困扰，绝大多数的问题其实并不深奥，但依然困扰着大家。
评审不好，项目止步、没有NB作品、职业生涯受阻...
各种心酸涌上心头。如果遇到此类事情，有没有更好的办法去处理呢？
作为以解决方案为生的产品人，我们应该有自己的“解决方案”，去打破这些评审过程中遇到的“牢笼”吧！
下面跟大家分享8招带你走出困境的方法。
在说这8点评审建议时，我觉得还是有必要去回顾一下这个关键词：会议。
只有知道我们做的是什么，才能做的更好。
在这里，并没有什么大咖的开会议的绝技跟大家分享的。只分享一本关于会议的书籍：
美国Tim-hindel所著的《会议管理》。
在全球范围内，每天举办的大大小小的会议不下几百万场，而这些会议是否成功，是商务效率的一个重要指标。
我们可以想象，在旅途疲惫，穿越万里之后，来到一家公司参加一个合作协商的会议。在会议上并没有达到一些重要的成果。从投入产出比角度，这一趟旅途浪费的成本，平均每个经理人至少上万元，但后面，产出效果几乎为0。
产品评审会也是会议的一种，它的目的是达成某个决策和方案。
当然，这是一种正式的、目标性极强的会议。即：要开了，就要开的有效率一些。否则，走过场根本是没有意义的。
《会议管理》这本书把会议流程分为了准备会议、出席会议、主持会议。
准备会议阶段：
要安排好时间、地点、座位等方面的工作。
当然，有些公司在评审的时候，需要用到电视、投影仪、电脑等电子设备的辅佐工作。这方面需要提前进行调试和准备。防止在会议开始时再进行调整，让一干人在评审室里干等，确实也是沉闷的。
出席会议阶段：
提到了重要的5点：
1积极参与
2外表和讲话
3倾听发言
4 处理问题
5 做备忘录
主持会议阶段：这本书里重点提及到了一点：
研究出席者。
这并不是耍滑的需要，它的目的是知道参会人是谁，而是尊重与会人员。例如：在出席者中，包含了相关者（业务直接相关）、协助者（帮助完成某个功能或业务的解答等）、参与者（参与但不发言，主要做同步、理解内容等，例如运营、客服等部门）。
《会议管理》这本书里有许多的作者浓缩的技巧，如果大家有兴趣，还是可以翻翻看的。也可以找我获取电子书。
基本了解了会议的情况后，我们会提出8招建议。这8个建议，是针对我们熟知的8个被怼被质疑的场景，以及对应的解决方案~
▼
场景一：“为什么要这么做？”
在评审会上，一上来你跟他们急头白脸的解释一通，这个功能怎么做，甚至零碎的把多个功能一起进行解说，他们后来一脸懵逼，然后回了一句：
“为什么要这么做？”
参与评审的同事在理不清原因 时候，一般都会这么问。他们的出发点很简单，就是：人性的疑虑。他们疑虑你所设计或迭代的功能，
背景是什么、为什么这个时间段就要做这个、是否有必要或做了有什么好处。甚至，从他们本身自由的需求、私心角度，也会进行质疑。
于是你再次解释一通，总算把他们的疑惑进行安抚了。甚至，解释了一通，他们还是一脸懵逼。
为什么不提前进行说明功能的目的呢？而等到他们质疑时候才解释？这样实际上，浪费了前面的解说时间。
时间就是效率。浪费时间，就是降低了效率。
造成此类质疑局面的原因，在于：想不清楚。表达不清楚不是理由，本质上，还是想的不透。
这里，推荐一个提问工具：丰田五问法。一位日本丰田专家大野耐一提出的。简单来说，针对一个问题，连续问5次，直逼本质的提问、层层递进。以下是一些参考：
1 为什么做这个功能
2 目的是什么
3 有什么优势
4 解决什么问题
5 有什么数据、论据的支撑吗？
当然，你还有其他的自我提问的方法。这里就不细说了
▼
场景二：““这个场景/因素/..方面有没有想到呢？”
案例1：假如你是某个电商网站的产品经理，电商集团需要对订单系统进行统一优化，优化方式包含了文案、ICON品牌识别、功能等方面。作为产品经理，在评审会上，把优化的订单功能的页面，放在了订单详情页、列表页入口等位置。但在帮助中心-订单的位置和订单结算的位置，你并没有考虑到。
毫无疑问，说开火，就开火。
开发或测试同事，会持续向你施压。
“这个入口都没有啊”
“你让用户在订单结算这里看到的是旧品牌，在首页上看到新品牌，他们就懵逼了”
“你都没有想清楚，就来说”...
对方的立场告诉你，你的工作是处于盲目优化的地方，很多都没有考虑到。
此时，一万只CNM路过...
作为产品经理，你会怎么办？
首先，临时解决方案是，心态放平，态度谦虚（确实是你想的不周到），记录下来，评审后及时修改并同步即可。
那么，如何处理这种被遗漏的情况呢？
推荐一招：MECE法则（互相独立，完全穷尽）
MECE法则要求我们把各种相关的情况都要想清楚，不遗漏。当然，这是最佳状态。
在考虑事情的时候，我们不妨从时间轴、次序、渠道、相关性等方面进行考虑，把产品方案想的更加完善。
说不定，下次评审时，一些想不到的地方你都想到了，开发也许会向你投向钦佩的眼光。
▼
场景三：“这个方案并不是最好的”
在评审环节，我们也会遇到这个情况。那么，开发、测试、UI等同事，就这么来一句，或许会让你胆战心惊。
但别怕，应该这样处理：
1）如果是对方感觉不对，但又说不出为什么，那么，仍然按照这个方案，但可以底下再讨论。
2）有更好的方案。
我们也许不相信开发、测试对产品的品味（这当然是不对的，产品人需杜绝高高在上感），但他们确实提出了一些方案。
如果方案较为离谱，那么自然是不过了。反之，如果方案比较靠谱，你自己又觉得比你的好，那么怎么办呢？
我的答案是：
接受、认同并探询细化这个方案。让他们帮你一起想方法，提高了参与度，何乐而不为呢？要知道，评审会绝不是产品人一个人滔滔不绝的演讲，
它也是一个沟通的会议。
3）如果开发或测试仅站在他们自己的角度去吐槽这个方案（比如开发的技术难度较大、测试繁琐）。比如，增加了某个功能导致的产品难以兼容（针对不同浏览器的一大推的兼容代码）等私心，开发就会提问疑问。
此时，你要做好你的坐骑了，径直往前走。
▼
场景四：“太啰嗦了，到底想表达什么？”
评审会上，你自信满满的表达了一通，但遭到了评审参与同事们的不理解。当你表达完成后，他们会质疑：“你到底要表达的是什么？”
站在对方的立场，主要原因是：1）他们确实听不明白你说的是什么 2）功能很多，他们听不出重点在哪里。
质疑的问题带来的痛苦，更多的是来自能力本身。
试想，如果一句话能讲完的事情，要拆出2句话甚至5句话讲，听的人不耐烦，说的人也累啊。
何不简洁、高效一些呢？
这里有个训练小技巧：在你设计功能之前，看能不能用一句话表达出来功能的目的。
这里推荐一个工具：黄金圈思考法。
通过提出what\how\why的方式，促使大脑的思考和解答问题。
▼
场景五个：“用户量有多大？开发成本太高了”
这是让很多人“一句语塞”的话。
真的，你告诉我用户量多大。如果很大，我立马给你开发。
如果是一个用户，告诉你她想要这个，呵呵，不好意思。你将收到“谢谢，再见”
用户量不好评估，难道就这样乖乖就范吗？
“你能告诉我，微信开发语音对讲功能时，有多少用户量？
你能告诉我，微信开发“附近的人”的功能，有多少用户量？”
...
不好意思，还是通不过。
这叫只看趋势，不看自己。
当然，你也可以跟评审同事们讲，竞品都有这个功能了，我们为什么不做呢？
这叫只看竞品，不看自己。
我认为、我觉得，这些话也杜绝说（不是尽量）。
好，既然是你认为，你觉得，那么，为什么要这么做？你的判断被质疑了。（可能你的嗅觉有乔帮主的潜质）
人格没有被质疑、专业被质疑了。
于是，要么默默忍受，要么开启回怼模式。战火不断..
举个例子，你在产品的订单列表上，增加了一个搜索功能。在评审会上，你把原型展示后，开发来了一句：“用户量有多大？”
如何做呢？这里的解决方案是：
1）可以拿量化的，尽量拿量化
2）不可以拿量化的，拿自然而然的逻辑，简单到无法反驳。
杜绝：拿感觉、拿竞品、拿大咖、拿公司领导镇压..
什么意思呢？
量化的数据包含了：
你真的知道这块产品会有多少用户量。
你从市场同类数据中，找到了用户使用量。
你从兄弟部门的埋点中，拿到了这个比率。再乘以用户数，就得到使用量。
...这是量化
什么是拿逻辑呢？
就是从A推导出B的。比如：美图app，除了修图之外，能不能加个拍照呢？当然可以。
这是简单到不能再简单了。美图，就应该增加拍照功能。这是自然而然的。
当然还有其他的方法，还有一个绝招，就是开发非常信任你，你打个招呼，提了一些，他们立马就做。
这是建立在你的专业能力之上的。如果你是这样的人，请忽略刚才所提到的建议。
▼
场景六：“跟之前方案对比，这样做的目的是什么？好处是什么呢？”
例如：某电商网站浏览记录入口功能，放在二级页面还是一级页面呢？评审会，开发问你，为什么要把入口前置？
对方的立场是：这是功能的迁移问题。
首先，请杜绝抛出这样的一句话：
“这个功能很简单就能实现啊”
好的，那我们遇到此类提问，如何解决呢？
此时，你要明确告诉对方，优化这个功能的作用和意义。
有以下的告知策略可以参考：
1）成本优势/投入产出比
2）用户路径优势
3）心智认知优势
4）产品体验优势
例如：把这个入口放在一级入口，用户会更加方便进入这个最近浏览的页面。之前调研了浏览记录页面的Pv和uv，量级非常大，可见用户还是比较在意这个入口的，能减少直达商品详情页的路径..
这是从用户路径上的说明。
其他几点你也可以进一步展开~
▼
场景七：“砍掉这个功能，不做”
面对这个场景，辛辛苦苦做好的功能，说不做就不做，自然士气被打击了。
当然，也不能糊里糊涂功能被砍掉啊！
建议是：
1）咨询提出决定的这名同事，他/她的回答可能有以下几种：
..
遇到这个情况，作为产品人，我们自然不爽。辛辛苦苦孵化的“功能”，咋能说不做就不做呢？
于是，我建议以更加客观的态度去审视他们的回答。
如果功能真的是很臃肿，要倾听是否真的是怎样。要知道，这种情况很常见。笔者在开过的评审会中，回顾来看，确实是有许多的功能显得有些臃肿。这是考虑不周全所致。
但如果真不是你的问题，那么就要据理力争。
可以从以下几个方面跟对方阐述，为什么要做这个功能:
1 强调产品的用户价值
2 强调产品的企业价值
3 强调产品的优势和解决的问题
4 适当时候，可以拿上级领导指示说明（不得已）
杜绝：
小公举毛病：“我就要这个”
一味强调产品功能是多么好，要知道，如果产品确实是好，评审要不一定过，现场的评判非常重要
心态飘起来，跟对方硬抗，严重不建议。
▼
场景八：“历史原因，这个功能实现不了”
这句话是不是听到油腻了？或者至少听过。在评审过程中，如果听到开发这么说，也不要着急，你的工作还没有白费。
