大多数产品经理,都容易走进的四个思维误区

4 评论 11482 浏览 43 收藏 29 分钟

编辑导语:产品经理在日常工作中会有很多需要思考的地方,比如在面对多方投来的需求时,要有对应的判断能力,理好头绪进行思考;本文作者分享了关于产品经理在工作中会遇到的四个思维误区和一些解决办法,我们一起来了解一下。

人的思考过程,是一个奇妙的过程,思维在脑海里流窜,横冲直撞又反复纠缠,最后扭成一团麻;所以常常会有人抱怨,脑袋里很乱,想不出头绪。

这是因为,大部分人的思考过程都是杂乱无序的,没有逻辑的,最后也没法形成有效的沉淀,更无法找到清晰的结论。

怎样把思维进行可视化的规整,最终系统化的沉淀下来,找到其中有价值的方向;其实这种可视化的规则,不止可以用工作中,用在生活中也一样。

领导讲话,都喜欢讲3点,这并不是信手拈来那么简单,这需要提前做好充沛的准备;很多说3点的人,都是提前思考过的,有备而来的。

逻辑好的人,往往善于归纳总结,把复杂包裹起来,把整理后的闪光点暴露出来,就像集线器,把各种线索都收纳到盒子里,把重要的插头暴露出来。

大部分人脑力最活跃的时候,往往是睡觉前、蹲厕所时,这时候你的脑袋里就像纪录片一样闪回各种生活片段。

也会自我探讨很多人生问题,但是当别人问你,刚才你都想了些什么?你会发现你突然脑袋一片空白,我刚才在想什么?

好像想了很多,却又都不记得了。除非在这漫无目的的脑力激荡中,你产生了让自己信服的idea,否则你很难记住自己都想了什么,所以大部分人这种碎片化的时间,都是毫无价值的浪费了。

而这种长此以往的漫无目的的脑力激荡,或者一种乱序的思考过程,会使我们很容易陷入思考的死胡同,走进思维误区。

就像我们小时候经常玩的“走迷宫”,最快走出迷宫的高手一定不是从入口开始一点一点摸索向前,而是从入口和终点双向入手,最终找到汇合点,就是最短的路线。

而一旦你开始漫无目的的去走进产品经理工作的这个“迷宫”里时,如果没有找到寻求最短路线的方法的话,走进误区就成了必然。

下面我们就为大家介绍几种大多数产品经理,容易走进的几个思维误区;希望各位以此为鉴,能够跳出思维的桎梏,真正提升寻求最优解的能力,而不是重复执行的能力。

一、“因果倒置”

不去思考现象背后的本质原因是什么,而是逃避思考,用现象本身作为原因去回答问题,这就是因果倒置的定义。

因果倒置问题看似不难理解,但却是产品经理日常最容易进入的思维误区。

  • “商品栏最近的订单转化率有点低。”——“一定要想办法提高,我们降价吧!”
  • “最近用户日活有点下降啊。”——“我们在首页加一个抽奖活动吧!”
  • “竞品在做分享有礼的用户增长运营活动。”——“我们也做一下!”

当你简单直接的去根据现象思考原因,那么你很可能已经犯了因果倒置的错误。

商品订单转化率有所降低,降价确实是一种提升方法,但很可能在粗暴的降价迎来短暂的订单繁荣之后,又陷入订单转化率下降的窘境。

订单转化率下降究其原因,很可能是商品橱窗展示不清晰、直观,或者是商品物流配送不及时,甚至是售后服务细节不到位、竞品最近在做营销推广活动等等。

订单转化率下降很可能是由以上多个指标共同影响决定的,只是影响因子不同,由一个主要影响指标及多个次要影响指标组成。

如果主要影响指标在于商品橱窗的设计问题,那即使降到成本价也无济于事。

再比如竞品在做分享有礼的用户增长运营活动,很可能是因为竞品业务模式、产品功能基本稳定,正处于快速增长期需要大量用户进行验证进一步打磨产品功能;但我们的产品目前业务正处于MVP验证阶段,产品定位及业务场景刚刚确定但产品功能还只是雏形。

此时若盲目的效仿,会让用户在使用不成型的产品功能时对产品产生负面情绪,影响用户量并会在前期产品没有做好相对应的风控策略时,召集大量的“羊毛党”刷奖;最后非但没有达到用户增长的目的,还损害了公司利益。

在运营层面上,很多初级运营喜欢猜用户是男是女、有没有谈恋爱、哪里生人、准备剁手购物吗、喜欢什么、工资多少这些没有多少意义的问题。

有意义的问题是,是男是女如何影响消费决策的?工资多少影响怎样的消费能力?有没有谈恋爱会否带来新的营销和消费场景?剁手购物要如何做精准推荐?

这些才是我们用户画像真正应该关心的问题。

不是因为我有了用户画像,才能驱动和提高业务,而是为了驱动和提高业务,才需要去建立用户画像,这是很容易犯的因果倒置的错误。

在产品层面上,很多人认为电商产品就是卖东西的,衡量电商产品的好坏是通过卖东西的数量来判断,淘宝之所以出名是因为淘宝的交易额最大,与淘宝拥有最多的卖家店铺数量有关。

而另一部分人则认为,电商产品是研究人们为什么买东西的原理,是去探索人们在什么场景下,什么条件刺激下更愿意买东西,研究的是用户需求场景,心里动机及社会环境影响。

一款电商产品是否做的好,取决于是否准确的控制了用户的行为与心理。

前者关注的是结果,将东西卖出去,卖的多只是产品的一种结果,而不是一种需求。

后者关注的是因,控制人们买东西的行为,才能左右卖东西的结果。

后者是需求,是考虑哪些商品会吸引消费者购买,用户最近有哪些购物兴趣点的迁移,用户是倾向于选择搜索商品名称后购买,还是通过淘宝内的商品推荐后种草下单,或者通过店铺直播过程中的指引而下单。

每个电商产品人都可以设计出直播模块、拼团平台、砍价玩法,但却只有后者,才能让这些功能发挥作用。

导致产品经理之间存在差距的原因恰恰也是如上面例子一样的因果倒置问题;看似简单的一个因果倒置问题,实际上困扰了大部分的产品人。

很多人看似很努力,看似在思考,但其实最后执行之后却事与愿违;很多人由此陷入绝望,认为自己没有天赋,不适合做产品经理,认为自己没有洞察力,认为自己差人一等,其实不然。

究其原因,是因为你陷入了因果倒置的思维定式,在怪圈中不断的重复着自己的错误。

如果看到这里你觉得自己也有类似的问题,那请你放下手头的工作停下来,认真思索是否找到了解决当前问题的本质原因,还是只是因果倒置的根据现象去简单的给出了一个解决方案。

请你付出足够的时间、足够的精力,去研究,去深入挖掘问题背后的本质,走出思维定式。

二、“陷入常规解法”

我们在日常的工作与生活中,总是会遇到各种各样难以解决的问题。

为了避免麻烦(其实主要是避免思考),我们经常会停留在原先普通的解决方式,或者借鉴其他人、其他公司的解决方法。

这种满足于常规解法的思维,限制了产品经理能力的提升。

在我们身边其实充斥着很多知识,宣扬对什么都适用,可以作为常规解的情况;看似很有道理,可以解决所有问题,但往往这种常规解并不是具体可以执行的对策,而只是泛泛而谈的一个指导方向,如果按照它的指导去做往往会很吃力。

举一个典型的例子,很多人在准备跳槽求职撰写个人简历时,都很容易陷入“满足于常规解”的错误定式。

如何检验自己是否犯了这个错误其实很简单,把自己撰写的项目经历或工作内容描述的主语换成其他人,从第三者的视角重新去阅读。

如果读完并没有违和的感觉,那这段项目经历或工作内容的描述很可能就是对谁都适用的常规解。

一般来说,常规解一定是浮于表面、通用、抽象的答案;比如“我主要负责系统的搭建及功能服务的优化,并对用户进行调研并跟踪反馈”,这样的一句工作内容的描述主语即使换成其他人,依然是适用的,而并不是你专属的,这就是常规解。

而“负责社区内容生产率的提升,通过精简界面、流程后置等手段将生产率指标提升18%”,这样的一句工作内容描述如果换成其他人就变的不再适合,因为它是你专属的,你独立完成的真实工作内容。

我们还可以思考下,当我们拿到一个问题,我们的思路是怎样的。

举个例子,当某个页面内广告位的CTR(点击通过率)下降了,我们第一时间会想到的处理思路是什么?

大多数人会首先将导致CTR下降的问题原因分类,逐一分析可能导致CTR下降的原因,并基于经验应用相关解决方案进行验证。

  • 样式问题:修改样式方案,多几个样式进行A/B TEST对比;
  • 内容问题:广告位显示质量较低,优化内容阐述角度,调整内容逻辑;
  • 布局问题:可能广告位位置有偏差,多布置几个位置进行A/B TEST;
  • ……

类似的,我们还能拆解出许多原因并进行定位与验证;这种思维惯性是:看到问题->解决方案->拆解->验证。可能有人会问,这种思维惯性会有什么问题?

1. 问题本身比解决方案更重要

当没有找到正确的问题时,所有方案都是无效的。

CTR(点击通过率)下降只是现象,不是问题。根据现象发散出足够多的问题,才有机会找到核心原因。

在大公司里对于个人工作岗位职能要求逐渐细化的背景下,我们能看到的问题会越来越少,找到正确的问题也更难。

2. 单一路线执行

不断拆解和执行方案A过程中,会导致引发问题B,问题B解决方案又会引发其他问题,导致解题思路越来越窄。

在资源时间有限的情况,更加不可能找到合适的方案;比如在样式A/B TEST过程中,发现A样式的逻辑有问题,去修改;发现样式不够多,去增加,增加的样式又有新问题。

3. 陷入低效率执行

因为没有跳出惯性思维框架,导致我们经常处于被动的处境下被动执行的状态。

当被上司不断提出新问题时,当被用户反馈各种吐槽时,当我们不停的在写各种方案时,当我们高效的执行了方案却没有得到好的结果时,想一想为什么我们会处于被动的状态?

4. 正确解法应该是什么?

再来看另外一种思路,先找到问题,判断哪些问题值得解决。再寻找有哪些机会点,再来拆解和验证。

找到问题:根据CTR(点击通过率)下降这个现象可以发散很多问题;比如如何让用户喜欢看内容,如何合理下发内容,如何让用户快速找到喜欢的容。

判断机会点:判断哪些问题是现阶段解决后,能带来最大价值的,整个思路是:发现问题->机会点->解决方案->拆解->验证。

一般的问题,按照第一种方式很快就可以找到解答思路,也很容易解决。

以至于很多人遇到问题时,就会惯性思维地采用这种思路,工作越久越容易有惯性。

一旦陷入这种“问题—方案”的思维陷阱后,甚至会在自己完全没有意识到的情况下,在面对工作中重要决策的关键节点时错失很多机会。

三、“浮于高级词汇”

“复盘,赋能,沉淀,倒逼,落地,串联,协同,反哺,兼容,包装,重组,履约,响应,量化,发力,布局,联动,细分,梳理,输出,加速,共建,支撑,融合,聚合,解藕,集成,对齐,对标,对焦,抓手拆解,拉通,抽象,摸索,提炼,打通,打透,吃透,迁移,分发,分层,分装,穿梭,辐射,围绕,复用,渗透,扩展,开拓…

转化漏斗,中台,闭环,打法,拉通,纽带,矩阵,刺激,规模,场景,聚焦,维度,格局,形态,生态,话术,体系,认知,玩法,体感,感知,调性,心智,战役,合力,心力,赛道,因子,模型,载体,横向,通道,补位,链路,试点…

颗粒度,感知度,方法论,组合拳,引爆点,点线面,精细化,差异化,平台化,结构化,影响力,耦合性,易用性,一致性,端到端,短平快,生命周期,价值转化,强化认知,资源倾斜,完善逻辑,抽离透传,复用打法,商业模式,快速响应,定性定量,关键路径,去中心化,结果导向,垂直领域,如何收口,归因分析,体验度量,信息茧房…”

首先我们先看下以上高级词汇。

产品经理不深入思考问题,而只是一味的在追逐看似专业的“高级”词汇,是非常危险的。

因为这样很容易产生一种错觉:“我已经全都明白了”,从而停止进行深入思考。

而一旦你面对的是一个同样喜欢高级词汇的产品经理或通过这些高级词汇对你产生“你已经全都明白”的职场新人,一旦他们向你传达积极的反馈,对你提出赞赏,这会产生恶性循环,让你进一步的停止进行思考,变得越来越浮躁。

这是一个可怕的思维定势,让产品经理因为掌握了高级词汇,而停止思考与进步。

比如说,要打造“流量闭环”,建立“产品矩阵”,聚焦“垂直领域”,贯通“关键路径”…用这些话无论是在产品设计时提出决策思路,还是在沟通会上输出自己的观点,都是缺乏说服力的。

因为这些词汇仅代表了一种抽象的理论与方法,而非能够给出具体性指导的关键意见;这些所谓的高级词汇在说出来的时候就已经表明,你的思维已经局限在了这些抽象的理论上,而非处于自身思考的转化输出。

例如目前非常流行的“中台战略”。

这个词非常火爆,无论大大小小的公司,不管中台适不适合自己的公司都要蹭一下热度,纷纷喊出了要向中台转型的口号。

但真的是无论什么公司、什么业务都需要中台吗?“中台”一词源自于2015年,马云参观一个著名的游戏公司Supercell之后提出。

简言之就是“小前台、大中台”,随即阿里就成立中台事业群,并取得了很好的成效。中台可以理解为一个公共的、抽象的后台。

提炼各个业务条线的共性需求,并将这些打造成组件化的资源包,然后通过接口的形式提供给前台各业务部门使用。

可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷,最大限度地减少“重复造轮子”的项目。

大中台基于的一个前提是,大量的积累。在这个前提下进行的提炼抽取才是有价值的。

如果没有足够的积累,盲目的进行抽取,抽取出的接口没有通用性,不但无法提升效率,反而会一些无用功。

什么样的企业适合中台?

  • 业务线多且复杂,通过搭建中台,可以有效地将业务线统一,将数据打通。
  • 快速发展的企业,通过搭建中台,可以快速搭建新的业务线,避免重复造轮子。

什么样的企业不适合中台?

初创型企业,初创型企业,业务线单一,没有足够的积累,搭建的中台无法发挥作用,反而会浪费人力物力,拖慢开发的进度。

应用“中台战略”是需要通过具体的、缜密的思考,找到符合自己公司或业务前提下,提升当前工作效率、缩减成本开支的方法,而绝不是一句空话。

当然,通过上面的例子我并不是在否定“高级词汇”的价值。经过深思熟虑后的“高级词汇”,是很有意义的。

因为比起掌握“高级词汇”本身,有意义的是为找到“高级词汇”背后的底层原理、基本概念、操作方法而进行学习与探索的时间,付出的努力与思考、实践的过程。

如果思考的过程是由你全程参与,熟练掌握融会贯通后,向部门内或公司领导层进行传达与传授。

让“高级词汇”成为公司的共识与基本认知,并帮助公司解决了持续已久的业务痛点,那么这个“高级词汇”才算有了更重大的意义。

四、“惯性范围分类”

惯性范围分类指的是,产品经理过度着眼于将当前所处的项目、产品、目标用户按照一定的范围、维度去分类,然后将分类后得出的结果作为问题解释的思维定势。

这种思维惯性其实非常常见,不只是产品经理,我们在平常生活中也经常会发生。

比如,一个程序员穿着搭配不好看,衣品不好,就会产生“一个人衣品不好”→“因为他是程序员嘛”→“程序员衣品都不好,没有审美”。

上面的判断看似很有条理性,实际蕴含着很大的逻辑漏洞。

且不说评价一个人穿着搭配好坏本身就是一个非常主观的问题,单纯说穿着搭配符合大众审美的程序员也有很多,也有很多从事传媒行业的人穿着搭配小众,无法被他人理解。

这样的判断不仅是犯了以偏概全的问题,还将分类范围定为了判断问题的标准。

上面的这种判断思路是很典型的惯性范围分类,即先给事件做分类,再通过该事件所属范围寻找问题的原因。

那么在产品经理的工作中,容易犯哪些类似的“惯性范围分类”的问题?有两个问题,即使是具备多年产品经验的产品经理,依然会惯性判断失误。

首先是,一部分产品经理会花费大量时间,去做用户画像分析,撰写精美的用户画像分析报告。

这个习惯其实是从快消行业延伸而来,为了对自己产品的用户进行深入的了解,从而将传统的用户研究的模式进行继承。

利用定性、定量的方式,将自己的用户分成一类或多个类型的群体,并找到他们的典型特征,比如女性、27~32岁,收入14000~25000元,喜欢奢侈品等等。

快消行业中热衷于做这样深入的用户画像分析与研究是有原因的;因为行业内的主要竞品因为都是标准化生产线产出的产品,所以产品的同质化问题比较严重,甚至于市场上不同公司的产品,或者同一公司不同子品牌的产品,在功能上其实没有太大差别,谁都无法从产品质量上或产品功能上占领市场。

为了占领用户心智,通过品牌推广与线下广告投放,以及产品降价促销等模式,强化用户对自己产品的认知,进一步化强化品牌在用户心中的地位。

此时,找到一个细分的用户群体是很重要的,了解用户的行为习惯及消费观念是有必要的。

但对于C端互联网产品而言,用户选择产品的标准不在于定价,主要差别在于用户体验。

而用户体验的优劣标准是一个相对标准化的评判标准,不会因为用户群体的细微差别而产生较大的差异。

换句话说,评价一个互联网产品的用户体验好坏有相对统一的标准,不会因为群体的不同而有什么大的变化。

产品经理更应该思考从如何从用户体验这个维度上去提升产品价值,而非去研究产品当前用户的行为偏好与生活、消费习惯,在这个时候做用户细分和对细分群体进行画像实际上就没有太大的意义了,它并不会为我们的产品设计提升有效的结论输出。

但即便如此,互联网企业的UED(用户研究)以及市场团队,还会将用户细分和用户画像分析作为自己的一项非常重要的工作。

撰写大量有深度、内容详实的用户画像报告,但你要明白这些报告的撰写目的是更好的为公司做精准的广告投放,为品牌方提供公司用户属性的合理依据,或更好的开展相关的市场运营工作。

而作为产品功能设计责任人的产品经理而言,这些报告成果对你的价值非常有限。

同样的问题,很多互联网公司通过后台数据分析或用户调研的方式,将使用自己产品的忠实用户或者长期活跃用户作为自己产品的核心用户来研究。

在他们的意识里,用户只分为忠诚用户和非忠诚用户,而忠诚用户是本产品生存发展的基础。

而对于互联网产品,特别是处于稳定期的产品来说,忠实用户不一定代表核心用户,他们可能仅仅是对产品选择不敏感的“懒惰用户”。

他们还在使用这个产品的原因可能不是因为他们经过多方对比后发现该产品体验更好、功能更全面,而仅仅是他们“懒得”去换一款更好用的产品。

这个时候如果把大部分的工作重点都放在对这类用户的调研分析上,会出现重大的资源浪费,因为他们的特征并不能代表当前市场的需求和产品未来的发展趋势。

反倒是那些非忠实的、流失、沉睡用户,他们对于产品的认知相对有深度,对产品功能和调性的变化特别敏感,这些用户才应该是产品团队需要特别关注的对象。

惯性范围分类的问题在于,将判断一个问题的逻辑基础建立在常规分类下的普遍认知,而非通过现实条件利用逻辑思考去解决问题。

按范围分类,绝不是逻辑性的说明;因为即使做出再精准的分类判断,依然没有直接回答“为什么会导致这种现象”。

#专栏作家#

穆宁,公众号:穆宁说,人人都是产品经理专栏作家。北邮硕士,前京东平台、百度商业化产品经理。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 我有个困惑,我这个人本身比较枯燥,不喜欢看直播,不喜欢网文,不喜欢玩弄那些app,偶尔会用银行app,购物app也是直接找到目标下单即可。像我这样的,怎么设计好的产品呢,毕竟大众都不像我这样

    来自上海 回复
    1. 我也是这样哈哈哈,还觉得资本嘎不到我的韭菜

      来自江苏 回复
  2. 之前有个老板超级喜欢高级词汇,前一两次听还觉得有点新意,后面发现反反复复就是那些,没有什么有价值的具体战略和产品方向。每天还是在压下面的人做各种各种营销,打折,拉新的项目,根本就没在管怎么构建核心竞争力。

    来自香港 回复
  3. 好!深入浅出!受教了

    回复