8招走出产品评审的困境

21天Excel零基础速成训练营,导师带学+答疑辅导+实战作业,让你真正掌握Excel技能,了解一下>>

产品经理与开发相爱相杀, 评审会上互怼更是少不了,是否有方法可以让评审更顺利进行呢?

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

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

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

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

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

  • 如何科学面对其他开发的怼?
  • 如何优雅的回怼?
  • 开发说这个功能实现不了怎么办?

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

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

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

下面跟大家分享8招带你走出困境的方法。

在说这8点评审建议时,我觉得还是有必要去回顾一下这个关键词:会议。

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

01

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

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

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

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

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

准备会议阶段

要安排好时间、地点、座位等方面的工作。

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

出席会议阶段

提到了重要的5点:

  1. 积极参与
  2. 外表和讲话
  3. 倾听发言
  4. 处理问题
  5. 做备忘录

主持会议阶段

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

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

02

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

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

场景一:为什么要这么做?

在评审会上,一上来你跟他们解释一通,这个功能怎么做,甚至零碎地把多个功能一起进行解说。他们一脸懵逼,然后回了一句:“为什么要这么做?”

参与评审的同事在理不清原因的时候,一般都会这么问。他们的出发点很简单,就是:人性的疑虑,他们疑虑你所设计或迭代的功能。背景是什么、为什么这个时间段就要做这个、是否有必要或做了有什么好处。甚至,从他们本身自由的需求、私心角度,也会进行质疑。

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

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

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

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

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

以下是一些参考:

  1. 为什么做这个功能?
  2. 目的是什么?
  3. 有什么优势?
  4. 解决什么问题/?
  5. 有什么数据、论据的支撑吗?

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

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

假如你是某个电商网站的产品经理,电商集团需要对订单系统进行统一优化,优化方式包含了文案、ICON品牌识别、功能等方面。作为产品经理,在评审会上,把优化的订单功能的页面,放在了订单详情页、列表页入口等位置。但帮助中心-订单的位置和订单结算的位置,你并没有考虑到。

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

开发或测试同事,会持续向你施压:

  • “这个入口都没有啊”
  • “你让用户在订单结算这里看到的是旧品牌,在首页上看到新品牌,他们就懵逼了”
  • “你都没有想清楚,就来说”
  • ……

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

作为产品经理,你会怎么办?

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

那么,如何处理这种被遗漏的情况呢?

推荐一招:MECE法则(互相独立,完全穷尽)

MECE法则要求我们把各种相关的情况都要想清楚,不遗漏。当然,这是最佳状态。

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

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

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

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

但别怕,应该这样处理:

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

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

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

我的答案是:接受、认同并探询细化这个方案。让他们帮你一起想方法,提高了参与度,何乐而不为呢?要知道,评审会绝不是产品人一个人滔滔不绝的演讲,它也是一个沟通的会议。

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

场景四:太啰嗦了,到底想表达什么?

评审会上,你自信满满地表达了一通,但遭到了评审参与同事们的不理解。当你表达完成后,他们会质疑:“你到底要表达的是什么?”

站在对方的立场,主要原因是他们确实听不明白你说的是什么;功能很多,他们听不出重点在哪里。

质疑的问题带来的痛苦,更多的是来自能力本身。

试想,如果一句话能讲完的事情,要拆出2句话甚至5句话讲,听的人不耐烦,说的人也累啊。

何不简洁、高效一些呢?

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

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

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

这是让很多人“一句语塞”的话。

真的,你告诉我用户量多大。如果很大,我立马给你开发。

用户量不好评估,难道就这样乖乖就范吗?

  • “你能告诉我,微信开发语音对讲功能时,有多少用户量?
  • 你能告诉我,微信开发“附近的人”的功能,有多少用户量?”
  • ……

不好意思,还是通不过。

这叫只看趋势,不看自己。

当然,你也可以跟评审同事们讲,竞品都有这个功能了,我们为什么不做呢?

这叫只看竞品,不看自己。

我认为、我觉得,这些话也杜绝说(不是尽量)。

好,既然是你认为、你觉得。那么,为什么要这么做?你的判断被质疑了。

人格没有被质疑、专业被质疑了。

于是,要么默默忍受,要么开启回怼模式,战火不断……

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

如何做呢?这里的解决方案是:

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

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

什么意思呢?

量化的数据包含了:

  • 你真的知道这块产品会有多少用户量;
  • 你从市场同类数据中,找到了用户使用量。

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

——这是量化

什么是拿逻辑呢?

就是从A推导出B的吗,比如:美图APP,除了修图之外,能不能加个拍照呢?

这是简单到不能再简单了。美图,就应该增加拍照功能。这是自然而然的。

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

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

场景六:跟之前方案对比,这样做的目的是什么?好处是什么呢?

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

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

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

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

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

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

  • 成本优势/投入产出比;
  • 用户路径优势
  • 心智认知优势
  • 产品体验优势

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

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

场景七:砍掉这个功能,不做

面对这个场景,辛辛苦苦做好的功能,说不做就不做,自然士气被打击了。

当然,也不能糊里糊涂功能被砍掉啊!

建议:

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

  • 功能太臃肿了;
  • 很明显不合理,直接下答案;
  • 看你不爽。

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

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

如果功能真的是很臃肿,要倾听是否真的是这样。要知道,这种情况很常见。笔者在开过的评审会中,回顾来看,确实是有许多的功能显得有些臃肿,这是考虑不周全所致。

但如果真不是你的问题,那么就要据理力争。

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

  • 强调产品的用户价值;
  • 强调产品的企业价值;
  • 强调产品的优势和解决的问题
  • 适当时候,可以拿上级领导指示说明(不得已)。

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

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

场景八:历史原因,这个功能实现不了

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

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

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

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

1)是否真的实现不了?

行动:妥协或坚持

2)是否有曲线救国的策略?

行动:采用

3)是否可以部分修改,功能也要实现?

行动:妥协且坚持

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

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

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

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

这又是精彩的一仗了吧!

 

本文由 @阿艺师傅 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
1人打赏
评论
欢迎留言讨论~!
  1. 写得很好!基本囊括了要学习回怼的场景了,好的产品经理很容易就可以举一反三

    回复