产品思维——产品经理的阿克琉斯之踵

AI时代,如何更快入行抢占红利得高薪?前阿里巴巴产品专家带你15天入门AI产品经理。了解一下>

面试好像永远会有一个终极问题:你觉得产品思维是什么?针对这个问题,有什么好的回答呢,让我们来看看笔者是怎么说的吧。

说实话,John也不知道怎么回答这个问题。似乎我们聊到思维的时候,思维永远处于顶层,它似乎难以琢磨但又无处不在——思维的境界从根本上决定了能力的边界,思维的层次从根本上决定了能力的层次。那么对于产品经理来说,产品思维本身就是一种重要的产品能力,而且这个能力会深刻影响其他能力。

在John的经验中,产品思维唯一关联性就是产品逻辑。产品逻辑讲究的是“聚类”、“递归”和“因果”。而产品思维需要首先将产品进行整理并合并分类排序,最后找到共通点。同样对于产品经理来说,产品思维另一个很重要的点——做产品一定需要注重逻辑的缜密性。我举一个例子,如下所示:

一、举例

以下说法正确的是:

A鲁迅原名周树人。

B人有两只手,十个手指头。

C中国有960多万平方公里。

D以上说法都不正确

答案解析:

正确答案是A:

小学课本文中说,鲁迅,浙江绍兴人,原名周树人,故A是正确的。B选项错的原因是,有一些残疾人士,只有一只手或者没有手,有两只手的人,有些人也不一定有10个指头,所以这个概念是以偏概全,所以不对。C选项错的原因是,地理课本上说,“现在,中国有960多万平方公里”;而明朝时期,国土面积最大时,比现在少一小半西藏和大半新疆,内蒙古全部和东三省小半土地,多出俄罗斯极少数土地。共710万平方公里。所以应该说现在的中国有960多万平方公里。所以正确答案是A。

正确答案是B:

A选项错的原因是,在语文课本中,我们所熟悉的鲁迅原名是周树人,但是在生活中,有一些人就是姓鲁名迅,课本中的鲁迅不能代指所有鲁迅,所以A选项错误。
C选项错的原因是,在地理课本上说,“现在,中国有960多万平方公里”,明朝时期,明朝国土面积最大时,比现在少一小半西藏和大半新疆,内蒙古全部和东三省小半土地,多出俄罗斯极少数土地。共710万平方公里。所以应该说现在的中国有960多万平方公里。所以C选项错误。

正确答案是C:

A选项错的原因是,在语文课本中,我们所熟悉的鲁迅原名是周树人,但是在生活中,有一些人就是姓鲁名迅,课本中的鲁迅不能代指所有鲁迅,所以A选项错误。

B选项错的原因是,有一些残疾人士,只有一只手或者没有手,有两只手的人,有些人也不一定有10个指头,所以这个概念是以偏概全,所以不对。

正确答案是D:

A选项错的原因是,在语文课本中,我们所熟悉的鲁迅原名是周树人,但是在生活中,有一些人就是姓鲁名迅,课本中的鲁迅不能代指所有鲁迅,所以A选项错误。B选项错的原因是,有一些残疾人士,只有一只手或者没有手,有两只手的人,有些人也不一定有10个指头,所以这个概念是以偏概全,所以不对。C选项错的原因是,在地理课本上说,“现在,中国有960多万平方公里”,明朝时期,明朝国土面积最大时,比现在少一小半西藏和大半新疆,内蒙古全部和东三省小半土地,多出俄罗斯极少数土地。共710万平方公里。所以应该说现在的中国有960多万平方公里。所以C选项错误。

的确这是非常无聊的问题。但是反射一个点就是我们在思考问题的时候需要考虑问题的全面性。那么做产品的时候怎么去应用产品思维呢?

二、观摩产品:思考产品背后逻辑

原来体验产品的时候,总是只会专注于表面,比如“我觉得这个功能不应该这么放置”or“这样的交互体验还是很惊喜的”,现在慢慢变成会更多的是去思考这几个问题:

  • 通过tab看整体的产品架构,各模块是怎么去串联的;
  • 主线模块的流程和逻辑;
  • 某个功能是如何实现的;
  • 他们的推荐策略是怎样的?从哪些维度去关联的。

当产品经理习惯这样去看产品后,就会很清晰这个产品背后的逻辑是什么,会理解别人为什么这么设计。特别是当别人迭代的产品需求与自己想的一样,就发现很多产品背后的逻辑是通的,不同的就是当前业务的场景和到达商业模式不同的角度和方法。

在《用户体验的要素》一书中,由外到里从“表现层、框架层、结构层、范围层、战略层”去思考并拆解产品,现在依然是拆解竞品最有效的方式之一。

再重温下这五层拆解模型:

表现层surface:你看到的是一系列的网页,由图片、文字、音乐、视频等元件组成。有些可以点击,具备某个功能,有些就作为一个静态呈现(就是拆分功能点和字段展示)。

表现层之下是产品的框架层skeleton:按钮、空间、图片和文本区域的位置,框架层用于优化设计布局,以达到这些元素的最大效果和效率——使用户在需要的时候,能记得标识并找到相应按钮(就是设计过程中遵循用户使用习惯去设计功能和展示交互)。

与框架层相比更抽象的是结构层structure:框架是结构的具体表达方式。框架层确定了页面上交互元素的位置,而结构层则是用来设计用户如何到达某个页面,并且在他们做完事情之后,能去什么地方。框架层定义了导航条的位置,以及导航条上各要素的排列方式,而结构层则确定哪些要素应该出现在导航条上,以及那些要素能去到哪里(就是功能的输入输出条件是什么?功能背后的流程、逻辑和策略是怎么思考的)。

范围层scope:结构层确定产品各种特性和功能最合适的组织方式,而这些特性和功能就构成了产品的范围层scope。某个功能是否应该成为产品的功能之一,就属于范围层要解决的问题。(就是为什么要做这些功能?版本迭代选取功能的策略是什么?)

战略层strategy:产品的范围基本上是由产品战略层strategy所决定的。这些战略包括了产品设计者想从产品得到什么,也包括用户想从产品得到什么(就是依托于产品本身的定位和用户需求说清楚产品经理做这个版本的策略)。

三、思考产品:设计更加友好的解决方案

所谓产品设计,就是设计一套解决方案,满足各种需求。

从产品整体看,各个功能组合起来,就是一套解决终极问题的方案;从单个页面看,交互和视觉也是一套解决方案,解决美观与功能之间矛盾的方案;甚至,文案一句话,也是一个产品,它也有其设计目的。

  • 微信朋友圈为了营造真正的好友社交圈,设计了屏蔽规则,防止营销泛滥;
  • 知乎为了让好答案好内容浮现,设计了「赞同」和「反对」的机制;为了解决类似问题的重复提问,设计「搜索+输入问题」功能的搜索输入框和问题重定向的机制;
  • 陌陌为了让产品内容更丰富但产品结构简单,设计了「发现」的标签页。

注:产品的每个设计都有原因。每个人都可以说出N个原因,但是若不了解产品团队当时的处境、战略目标,则这些原因的扯谈成分居多。

从整体框架到界面交互到文案,产品经理就是要不停面对新问题>分析问题>设计方案,不停循环。久而久之,也会有自己的一套思考和解决问题的思维方式。

在设计解决方案中,我会有意识的用「解耦」和「穷举」的思路去拆解问题和设计。所谓「解耦」就是把整体拆解成几个相互独立的模块,分析各个模块。

比如在设计微信小程序养成类游戏时,我需要去拆解获得来源和消耗是否成健康值状态,所以需要拆解几个模块:升级系数,获取系数,消耗系数,还有养成的难度系数等等。需要调整参数的同时生最后生成不同的难度递增曲线。通过任务A/B和养成商品A/B/C,就可以形成2*3种不同的策略。

四、执行产品:分步实施

越来越有一种感觉,大至整个产品方向,小至某个功能,都可以用「假设-验证」的循环来做产品。于是现在有个习惯,在设计完一个方案,不会马上开发,问自己几个问题:

  • 这个方案要解决的假设问题是什么?
  • 达到什么标准才能验证假设成立或错误?
  • 可否分几步实施?每一步的指标是什么?
  • 当前这个是最简单的方案吗?

想明白以上几个问题后,制定分步实施的策略。这样有两个好处:

一方面清楚知道产品的每次迭代的效果。在修改功能或调整策略,需要明晰哪些用户可能会被接受和抵触,那么需要做数据埋点分析来分析用户使用行为;

另一方面可以加快进度,及时调整。开发周期越长,项目烂尾的可能性越大。分步实施就像逐步攻城掠池,一步一步KO掉功能模块或修改。早日上线,多一天的测试,就可以知道之前的假设是否成立,并且做出调整。不少时候,在完成策略一和策略二之后,可以进行策略三。

但发现策略二的指标一直达不到时,这种情况下还会去开发策略三吗?我们应该庆幸一开始没有让策略一、策略二和策略三同时开发。

设计阶段就是和开发、设计沟通,也是要设计方案来协调资源和时间。有时调整一下界面的设计,可以让开发更容易;有时赶进度,需要简化功能;有时对A/B策略难以抉择用哪个,需要平衡。这样的协调方案也跟设计产品的思路差不多。想明白「为什么这样做」「怎么做是最简单」。

以上是通过通过产品经理角度观产品思维,我觉得是比较狭义的。(接下来就是John的胡言乱语)

我觉得广义的产品思维是结构化思维,适用于互联网的所有从业者,比如HR工作,产品思维也能发挥作用。HR将公司职位视为产品,员工视为目标用户。首先去主动、深入理解员工的需求,然后尽力在职位中去满足这种需求。而且像做互联网产品一样,根据员工的反应快速迭代。

产品思维体系化的建立过程应该是先从零乱、混沌的思维到逻辑化串联的思维然后到体系化的思维。

所以说为什么新人想转行产品经理时候,John给的意见就是跟好一个项目就够了。可能你看书、培训接收的是零乱的知识点,没有去更好地串联起来。当你真正地跟好一个项目,在过程中你就明白,我做了第一步,接下来第二步我应该怎么做。大多数人学得越多越焦虑,根本原因就是缺乏思维体系。是时候改变这种状态了,是时候构建自己的体系化思维了。

 

作者:John,产品狗一枚,微信公众号:产品狗聚集地。欢迎一起沟通交流。

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

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

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!