产品经理沟通法则:取势、明道、优术

艾伦魔拜 发布于2018年02月01日 标签:, ,

取势

所谓势,就是大方向。逆势而为,不进则退;顺势而为,扶摇直上。

作为产品经理,在沟通中能取的势就是天时地利人和。正所谓:天时不如地利,地利不如人和。其中,人和是最关键,但是这里的人和不是大家开开心心一团和气,而是有共同的价值观和目标。当目标和愿景一致了,便有了沟通的前提,一旦取得了这个势,沟通的过程可能曲折,但是方向始终坚定。

那么,如何确立共同目标,统一战线呢?明确愿景,大局为重,合纵连横,成就大我。

首先,我们应该站在较高的角度综合考虑问题,也就是我们常说的战略层。保证我们做出的所有决策都是基于公司愿景的、符合公司战略利益的,而不是出于部门KPI或是个人利益考虑(所以产品经理绝对不能甩锅啊)。大局观是会影响他人的,自己从大局考虑,影响其他部门同事也从大局观出发,当所有人都认同一个目标,那么就是仁者无敌,就不会出现所谓的撕逼情况了。

虽然,产品经理是用户的第一负责人,但是,我们更应该明确的是,用户是大家的用户,不是产品经理的用户,所有人都应该为用户负责。一旦出了问题(除非是明显的个人低级错误外),产品经理应该带头背锅,但不是单独背锅,因为公司的失误,是所有相关人员一起犯的。既然每个人身上都有一口锅,就没必要去甩锅。

所以产品经理是一个纵横家,游走在各个部门之间,为了公司目标,编织一张意义之网,网罗各方力量,顺目标而为。

明道

道,是一种规律,万事万物都有其规则,沟通也有相应的规律。

沟通之道—-个人魅力

条理性是个人魅力非常重要的体现。产品经理在沟通时应该遵守金字塔原理,在口头沟通时,结论先行,然后阐述理由。在书面沟通时,写明背景、冲突、疑问、结论。阐述理由时,应条理清晰,使用演绎推理或归纳推理;群体沟通时能用图的不要用字,能用表的尽量不用图。自己理清思路,有条理地娓娓道来,方便对方理解,沟通就会顺畅很多。

知识的广度也是一个非常重要的个人魅力体现。沟通的过程一定要始终保持双方在一个频道上,否则就是鸡同鸭讲,无效沟通甚至产生歧义。但是,产品经理需要沟通的对象很多,如何才能在沟通时跟任何一方都能保持同一频道呢?那就需要丰富的知识储备和认知宽度,产品经理需要懂技术、懂运营、懂测试,这样才能跟各方愉快的沟通(也能防止被坑哦)。所以,产品经理要把自己打造成一个T型人才—-既有专业的深度,又有知识的广度。

专业性也能为个人魅力加分不少。产品经理在规划功能和设计流程时,应该始终体现自己的专业性,因为只有展现出专业,才能赢得别人的信任。每个人都愿意跟着专业的“老司机”走,而不是被新手带沟里。

所以,当有人质疑你:为什么toast的时间是1.5s时,你因该说人类视觉暂留达到最大值的最短时间是1.5s,大于这个时间,提示过重造成干扰,小于这个时间,达不到提示效果;当有人质疑你为什么设置5个项而不是其它数字时,你应该用人类短时记忆的有效项目数为7±2来解释;当有人质疑你为什么要激励用户时,你应该从斯金纳操作条件反射谈起;当有人质疑你设计的用户奖励过少时,你应该从“德西效应”出发跟他聊一聊····

沟通之道—懂人性

用户是人,所以产品经理要懂人性;沟通对象也是人,所以懂人性才能更好地沟通。

人有互惠性。沟通是一门妥协的艺术,我们在说服别人按照我们的意愿行事的时候,也要给予一定的付出或妥协。比如我们在提需求的时候,就可以把核心的需求掺杂在非核心需求中,必要时牺牲掉非核心需求(或降低优先级下个版本再实现),做出让步,进而保全核心需求。

人有利己性。虽然在取势中谈到团队目标一致性,但是不可避免的每个人都有利己的私心,其它部门的人也要维护自己的利益、部门的利益。所以,当产品取得成绩的时候,应该将相关人员都带上。当提需求的时候,如果不是紧急需求,也需要考虑一下其它部门的时间安排,尽量不在别人忙着赶进度的时候,提额外的需求。

人有情感性。虽然身在职场,应该公事公办,但是人的情感性就决定了,人不可能不带个人感情进入工作。有时候在会上,争面红耳赤都解决不了的事情,会后一句哥们(姐们),请他喝杯咖啡,就愉快的达成了共识。所以产品经理要想沟通顺利,平时也要攒人品,偶尔请个下午茶,陪哥们抽个烟聊聊人生,组织一下聚餐···毕竟没有什么是一顿饭决绝不了的事情,如果有,那就两顿~

优术

人生就是一场修行,术,就是一个个的技能点。与不同的角色沟通,我们就需要使用不同的具体技能。

与Boss沟通

老板说的总是对的,老板说的总是对的,老板说的总是对的。重要的事情说3遍,这倒不是溜须拍马,而是基于以下逻辑:

  • 老板也是人,他有自己的想法,有自己存在感的需求,也有自己的KPI要背,也要跟投资人交代。他做的一些决定,有我们作为产品经理看不到的一些需求方,有他的不得已。
  • 老板站的角度更高,掌握的信息和资源更多,很多我们觉得不对的,或者不可能完成的事情,对他来说却不一定。很多时候我们觉得错了的决定,很可能他看到了更大的问题,只是两害相权取其轻。又或者,他眼光长远,在当前看来是错误的方案,放在长远来看,是有利于长期发展的。
  • 与老板沟通时,我们更多的是提出一个或多个可行方案,然后分别阐述优劣,并尽可能地争取使我们觉得更优的方案被采纳。但是,决定权在老板那里,经过一番努力,如果最终采纳的不是我们的方案,也要遵照执行,毕竟这关系到团队的效率。哪怕最后错了再改,也比过程一直争论不休,项目无法推进来的好,更何况,对错尚未可知呢?

与UI设计师沟通

UI设计师像是一群游侠散仙,他们对美有执着的追求,和个性的表达。他们偏重于感性和直觉,所以在沟通的时候,我们不能用逻辑和强权去压制。而且,UI界面的美丑是任何人都可以评论上两句的,这个说好看,那个却说不好看,他们也很无奈。

所以我们在跟UI同学沟通设计稿时,一定要给出核心的设计目标和理念,明确大的设计方向,切记使用“我觉得···”。审美是因人而异的,但是设计的规则和目标是统一的。我们只要抓住核心目标,剩下的就交给设计师了,让他们专业的人做专业的事,给予足够的发挥空间。

与RD沟通

程序猿这样的形象已经非常深入人心了。与他们沟通的方式与UI恰恰相反,与开发沟通一定要用逻辑规则,用丝丝入扣的推理和论证征服他们。切记不能挑战他们在技术领域的自尊心,比如说:这个功能很简单,没什么做不了的,我们以前···很容易就搞定了。到时候怼你一句:you can you up,no can no bibi!那就没的聊了。

所以,当产品经理面对开发甩过来的一句“这个功能做不了”时,我们应该像分析用户需求那样,挖掘深层的含义,有针对性的去沟通:

  • 时间来不及。绝大部分是这个情况,这就需要产品合理的排期,预留15%~20%的时间余量,以应付这一类的问题。如果时间已经来不及了,那就需要另做权衡:是把功能放到下个版本实现,还是砍掉一些这个版本的低优先级功能让出时间,又或者发挥一下个人魅力,陪开发加加班搞定。
  • 开发觉得这个功能做了意义不大。这也是很常见的问题,开发本身对你的设计不认可,但是又觉得谈用户体验、谈场景撕不过你,所以只能用这个方法搪塞了。这个时候就只能以理服人,再次用逻辑、规则、论证的方式说服他们并达成一致。当然,一些有产品思维的开发也会提出他的方案,这时也不妨一起讨论一下,说不定他的方案确实更好呢?
  • 真的是技术上实现不了。这种情况也有,但是少见,真要是遇到了,也只能要么多给点时间,下个版本好好研究一下再上;要么,妥协一下,用其它略差一点的方案曲线救国,再图优化。(怎么办呢,难道还真找个程序猿祭天啊?)

与运营沟通

运营是产品需求的主要来源之一。运营是一群脑洞大,强跳跃性思维,撕逼能力也比较厉害的物种。他们一般会提很多需求,需求之间有时候没有关联,甚至是矛盾的。提出的需求每次都是紧急,巴不得希望你今天下班前就上线。但是换位思考一下,他们是整个公司背负KPI压力最大的部门,提一些紧急需求;提一些只对眼下数据有提升,但是对长期利益无益的功能也是情有可原的。

与运营沟通最核心的一点就是用数据说话。所以产品设计中做好数据埋点,平时做好产品数据分析,必要时把数据拿出来佐证,达到沟通目的。当运营提出新的需求以配合活动时,我们应该让运营拿出活动方案,一来可以排除掉很多拍脑袋需求,二来可以根据活动的力度,范围,时间长短等要素来灵活应对。如果是活动力度较小的短期活动,可以用一些第三方活动平台提供的功能,如H5形式的抽奖,大转盘,有奖小游戏等;如果是投入较大,时间跨度也较长的活动,可以先开发简化版小范围试验,收集数据,根据数据表现来决定下个版本此功能的走向。

经过上面的分析,你会发现,沟通不是“对话”这么一个点,沟通是一个面,是一个系统。所以,想解决沟通问题,就要系统化的去着手。取势、明道、优术,就是我的沟通方法论。

沟通是一个包治百病的庸医,任何事情都可以通过沟通解决,但是却需要大量的时间。在这个高度分工的时代,沟通正变的越来越重要,我们能做的,就是不断提高沟通效率,降低沟通成本。

文: 胡小Q 发布于人人都是产品经理