8招走出产品评审的困境

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