数据产品经理修炼手册:从零基础到大数据产品实践
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

1.3 数据产品经理的思维方式

曾经有人说,产品经理就是发现问题,并制定一套解决方案,组织一些人一起去解决问题,然后再持续不断地对解决方案进行优化和改进。在这个过程中,产品经理们做了一个又一个项目,迭代了一个又一个产品,积累了很多经验,在复盘和总结项目的时候,通常会发现有些方法是通用的,对于数据产品经理的日常工作,技能是我们的安家立命之本,但是在技能之上,更重要的是思维方式,它决定了我们做事情的方法、思路。对于一名数据产品经理来说,哪些方法论和思维方式是我们经常会用到的呢?

1.3.1 归纳与演绎思维

归纳法与演绎法是在写作过程中逻辑思维的两种方式。人类认识活动,总是先接触到个别事物,而后推及一般,又从一般推及个别,如此循环往复,使认识不断深化。归纳就是从个别到一般,演绎则是从一般到个别。

1.归纳法

归纳法是产品经理思考和总结的有效方法,是经典物理研究及其理论建构中的一种重要方法。归纳法透过现象抓本质,将一定的物理事实(现象、过程)归入某个范畴,并找到支配的规律性。就像我们在做竞品分析的时候,通过审慎地考察各种竞品,并运用比较、分析、综合、抽象、概括以及探究因果关系等一系列逻辑方法,推出一般性猜想,然后再运用演绎对其修正和补充,直至最后得出结论。总而言之,归纳就是从已知信息推理出一个结论。

要注意的是,归纳要从已知信息的共同属性推导出结论,如图1-5所示,通过已知信息可以归纳出结论。

归纳法的例子如下。

条件:我养的一只叫“一条”的猫喜欢吃鱼。邻居家养的一只叫“二饼”的猫喜欢吃鱼,叫“三万”的猫喜欢吃鱼,叫“红中”的猫也喜欢吃鱼……

结论:猫喜欢吃鱼。

图1-5 信息归纳

如何检验结论是否正确呢?可以通过结论倒推,看一看是否能够解释清楚,推导后的信息是否准确。在使用归纳法达成结论的时候,同时需要注意,千万不要在信息不全面的情况下犯以偏概全的错误。例如,人们熟知的黑天鹅的典故,讲的就是以偏概全的问题。生物学家在亚洲、欧洲、美洲发现的天鹅都是白色的,于是得出结论:天鹅就是白色的。后来,人们在澳大利亚发现了黑天鹅,一个与白天鹅颜色完全不同的个体。这就是犯了以偏概全的错误。如果想要避免以偏概全,就需要对得出的结论进一步用事实验证,从多个角度证实或证伪。因此,只有掌握全面的材料和事实,才能归纳出结论。不要只通过少量的事实就妄下结论,这样对业务发展影响很大,可能误导方向。

2.演绎法

演绎就是发散,类似于我们在画思维导图的时候,从一点出发,发散出很多相互独立、不相关的点,再一步步发散出去,不断穷举出想到的点。演绎法从一般到个别,即以一般的原理为前提论证个别事物,从而推导出一个新的结论。演绎法的例子如下。

条件:猫喜欢吃鱼,我家养的“一条”是一只猫。

结论:“一条”这只猫喜欢吃鱼。

其实,演绎法再发散一些就是不断联想,由一点出发,不断联想出相关的事物,例如现在去医院看病挂号特别难,特别是专家号。如果我要做一个挂号的App,那么做了就会有很多人用吗?很多人用了会带来什么问题?……这也是打开产品经理思路的一种方式。

演绎的方式:大前提—小前提—结论。

大前提:一个客观事实。

小前提:属于上面那个事实的子范畴,子范畴就是其中的一个点,包含在事实的基础上。

结论:根据相关性得出结论。

在数据产品经理的现实工作中,归纳和演绎的应用是十分广泛的。一个业务是由很多部分归纳组成的,会受到很多具体化的指标影响,所以在定义一个问题时,我们可以对问题进行归纳。例如,每个电商平台都会关注交易额(GMV),而GMV又是受用户流量、转化率和客单价三部分影响的。其中,用户流量受推广来源流量、新用户流量、老用户流量等指标影响,跳出率和购物车流失率等指标会关系到转化率情况,客单价又不是一成不变的,很多时候新老用户的客单价都不相同,因此可以用图1-6进行逻辑划分。这样,当交易额出现异常情况时,我们便可以通过图1-6分析影响交易额的指标,一步步定位是什么原因引起的问题。

图1-6 交易额的逻辑分层

1.3.2 数据思维

我们先看一下数据、信息和知识这三个概念。

数据就是数值,是一种客观存在,是通过观察、实验和计算得出的结果,并随着社会的发展而不断扩大和变化。特别是在现在的移动互联网时代,数据不再是仅仅限于字面上的数字,图片和视频都是数据,我们开车或者骑行中的轨迹也是数据,甚至身体的健康状态信息等也都属于数据的范畴。

信息是对这个世界中人或者事的描述,泛指人类社会传播的一切内容,它比数据更加抽象。1948年,数学家香农在题为《通信的数学理论》的论文中指出:“信息是用来消除随机不定性的东西”。信息是被组织起来的数据,是为了特定的目的,对数据进行有关联的组织和处理,赋予数据以具体意义,从而可以用来回答5W2H中的Who(谁)、What(什么)、Where(哪里)、When(什么时候)的问题。以2018年10月23日通车的港珠澳大桥为例,它是建立在中国境内,连接香港、珠海和澳门的大桥,桥隧全长为55千米,其中主桥为29.6千米、香港口岸至珠澳口岸为41.6千米,这便是由数据表述的有关港珠澳大桥的信息。

知识是通过数据和信息处理以后,被验证过的,而且是绝对正确的。可见,知识是数据和信息之上的,更加高级和抽象的概念,是基于信息之间的联系,总结出来的规律和方法论。知识具有系统性、规律性和可预测性,主要用于回答Why(为什么)和How(怎么做)的问题,而得到的知识能够使我们更加清晰地了解世界和生活,还能够不断改变我们周围的世界。这一切所有的基础就是数据。例如,北京夏季高温多雨,8月温度为20~36℃,平均降水天数为12天,这是根据多年资料总结出来的北京气候的规律,这个知识有三个作用:①回答问题。这个知识解释了今年8月北京为什么下了那么多雨。②预测。明年8月,北京很可能温度还为20~36℃,平均降水天数还为12天。③总结经验。在8月来北京旅游穿短袖衣服即可,体弱者要带长袖衣服,最好带伞。

图1-7解释了数据、信息和知识的层次关系和重要性,我们做任何决策的知识都是要建立在信息的基础上的,仅仅凭直觉和意识做的一些决策,如果没有数据支撑,那么是没有办法经过积累沉淀下来形成知识的,有些企业只是收集数据,却不知道怎么用、应该用在哪里。数据如果静静地放在那里是没有任何价值的,有效的数据驱动可以将企业里的数据充分地转化成信息,并且形成结构化的知识体系,高效地指导企业各个业务快速发展。

图1-7 数据、信息和知识的层次关系和重要性

另外,当对要解决的问题不能寻找到一个简单、准确的解决方法时,我们可以通过历史数据,寻找合适的算法,构建出模拟真实数据的模型,从而预测真实场景下的数据,寻求进一步的解决方案,这就是数据驱动方法的意义所在。虽然这些模型都会有一定的误差,但是在合理误差范围内的结果都可以进一步指导企业做出决策和对业务进行指导。随着大数据时代的发展和硬件计算资源的进步,我们通过数据生成知识的速度会越来越快、效率会越来越高,在这个高速发展的时代,数据驱动会越来越高效地帮助企业发展,达到用数据汇集信息、通过信息挖掘知识、用数据驱动业务的目的。

1.3.3 用户思维

用户思维是指站在用户的角度考虑问题,从用户的问题出发。这里的用户,可以是使用产品的用户、公司的客户,也可以是合作部门提需求的同事,还可以是自己的老板。马化腾说过,产品经理最重要的能力是把自己变傻瓜。周鸿祎也提出,一个好的产品经理必须是白痴和傻瓜状态。

产品经理要能够随时切换自己的思维方式,能够随时从“专业模式”切换到“傻瓜模式”,这就是用户思维的体现。产品经理要能够忘掉自己的行业背景和知识积累,以及产品逻辑和实现原理,变成对这个产品一无所知的“小白”。

用户思维一般只关注用户的需求和想要的结果,以用户需求为导向,不会太关注执行和实施的过程。例如,我想给某人打电话,那么我拿出手机,便可以联系到这个人进行直接对话,至于手机信号怎么样、基站是怎么建设的、如何精准地和这个人对话而不会错误地联系到其他人,我都是不考虑的,因为一旦考虑这些细节,我就会深陷这些泥潭里而不能自拔。

以大数据分析平台为例,用户的思维如下。

昨天上线了一个活动,我打开大数据分析平台,就想看活动的数据情况。

在这个思维模型里,用户的预期是直接获取上线后活动数据的情况,让他快速了解活动的效果,尽快做出决策。所以在这个过程中,我们所做的任何工作都是从用户的这个核心需求出发的,并且实现这个核心需求的目的路径越短越好,用户的整个思维体现可以用图1-8表示。

图1-8 大数据分析平台的用户思维体现

如何掌握并熟练应用用户思维呢?首先,要在心里时刻想着用户,牢记用户的需求,以“小白”心态理解用户的需求,并在整个产品设计、推广过程中,复盘自己是否体现了用户思维,有没有以用户为导向。然后,融入用户真正的使用场景中,只有这样,你才会作为一个真正的用户体验产品和服务,当遇到一些痛点时,才会意识到产品需要改进的地方,才能真正体会用户思维。最后,要多和用户打交道,定期进行用户需求调研访谈,这样才能准确地把握用户思维,真正做到以用户思维为导向。

1.3.4 产品思维

用户思维只关注产品功能,会把需求简单化,而工程师的工程思维会关注工程实现,就会想到具体的实现细节问题,所以如果让用户思维的人和工程思维的人直接沟通,经常会看到吵得不可开交的场面,最后争得面红耳赤,仍然不能解决问题。这种情况导致的最终结果要么是无休止的无效沟通,项目很难实施,要么是交付的产品很难用,不能满足用户的需求。这时候就需要具有产品思维的人,也就是产品经理,在需求上进行把控,在表现层尽量向用户思维靠拢,又要尽可能地考虑工程实现,把需求具体化成严谨的逻辑表达出来。这样,就弥补了用户思维和工程思维之间的鸿沟,在用户思维和工程思维之间构建了一个桥梁,保证了产品的顺利实现。

业务方用户作为产品的需求方和最后的使用者,不会参与到产品的具体实现过程中,而负责产品实现的,是程序研发工程师、UI设计师、交互设计师、测试工程师和产品经理等。产品经理在整个过程中,作为需求方的代言人,代表的是用户的利益,所以要具有一定的产品思维,能够把用户思维转化为产品原型或者项目方案,让具有工程思维的研发工程师更容易理解和接受。只有真正具有产品思维,做出来的产品才能更方便用户使用,才会在产品设计中以用户思维为导向。例如,在大数据分析平台中,用户对数据的需求基本上就是能够很快地找到自己关心的业务报表,直观地获取数据信息,并根据数据指导业务决策,产品思维在设计报表功能中的体现如图1-9所示。

图1-9 产品思维在设计报表功能中的体现

需要注意的是,这里的用户不仅是业务用户,还要考虑老板的意见、运营的想法、数据分析师的需求和自己对产品的规划。产品要经过交互设计师、UI设计师在交互和页面上优化,并通过工程师的程序实现,最后交付用户使用,并根据用户反馈继续迭代。

用户思维代表的是用户的心理模型,产品思维代表的是假设的用户模型,工程思维代表的是真实的实现模型,这三种思维方式对产品经理都很重要,而且产品经理要善于转换思维。在我们擅长的领域,我们的思维往往是产品思维和工程思维,当转换到不懂的领域时,看待这个领域事情的思维就变成了用户思维,要时刻保持一个空杯心态。

1.3.5 工程思维

工程思维主要关注的是项目实现的过程,包括项目的方案、项目排期、项目进度跟进、项目执行等,是一种更加关注细节逻辑、更加严谨的思维方式。比如,要开发一个大数据分析平台,如果单纯用用户思维看,那么很可能只关注表面的功能,其实这只是项目中很小的一部分,还要关注系统架构选型、后端功能实现、系统的适配性、服务的稳定性、查询速度等一系列问题,它还原了产品具体实现的本质。

以大数据分析平台报表展现功能为例,如果数据产品经理只有用户思维,那么只会关心报表展现哪些单图内容、都有哪些筛选条件。可是,如果数据产品经理用工程思维看,就要考虑这个功能具体是如何实现的,要能够知道大概的步骤和方式,就会考虑如下步骤实现:

(1)根据页面ID获取Dashboard配置;

(2)根据Dashboard页面配置渲染页面;

(3)根据图表ID获取图表配置项;

(4)创建报表中的自定义图表,并进行渲染展现。

用流程图展现如图1-10所示,数据产品经理如果有很好的工程思维,那么会更容易与研发工程师沟通,并确保项目在合理、可控的基础上顺利进行。

图1-10 大数据分析平台报表展现的工程思维体现

1.3.6 其他一些思维方式和方法论

当然,还有一些思维方式和方法论也是每一个产品经理在工作中经常用到的。例如,产品经理要经常写PRD,那么PRD要以怎样的思路来写,这里就要用到5W2H分析法。

在实际应用过程中,5W2H分析法非常简单、方便,易于理解、使用,并且富有启发意义,对于决策和执行性的活动措施也非常有帮助,也有助于弥补考虑问题的疏漏。

5W是Who、When、Where、What、Why,2H是How、How Much,如果大家觉得这么多英文比较难记,下面的例子可能更便于理解:因为之前的手机摔坏了(Why),小王(Who)于2018年11月11日(When)在天猫商城(Where)通过秒杀活动(How)花费了9000元(How Much)购买了一台iPhone XS(What)。我每次在写需求文档之前都会在心中默念一遍5W2H,等想清楚了再开始写。有了5W2H分析方法的帮助,我们在写PRD和思考问题的时候,就不用怕遗漏而被程序员追问了,因为他们问到的我们都提前想到了。

接下来,介绍产品经理的目标管理工具——SMART(S=Specific、M=Measurable、A=Attainable、R=Relevant、T=Time-bound)原则。它是使产品经理的工作由被动变为主动的一个很好的管理手段。具体的含义如下:指标必须是具体的(Specific);指标必须是可以衡量的(Measurable);指标必须是可以达到的(Attainable);指标是实实在在的,可以证明和观察的,并和其他指标有一定的相关性(Relevant);指标必须具有明确的截止期限(Time-bound)。

有了SMART原则,我们在复盘总结的时候,就有一个可参考、可量化的方法,让我们的总结与评判更理性和更贴近真实。

产品经理与程序员沟通(项目管理)的必备方法——任务拆解法。任务拆解法是一种处理方法,指的是目标→任务→工作→活动。产品经理要学会拆解任务,只有将任务拆解得足够细,才能做到心中有数,才能有条不紊地工作,才能统筹安排时间表。你是不是在工作中遇到过如下场景:“这个需求一周能做出来吗?”“不行,需要两周,这个功能太复杂了。”“十个工作日怎么样?”当与程序员讨价还价时,你感觉既心累又无力。如果你学会了使用任务拆解法,那么对话很可能就是下面这样的:“这个需求一周能做出来吗?”“不行,需要两周,这个功能太复杂了。”这个时候你慢慢地拖来一把椅子,坐在他旁边。“来,我们把这个项目一步步拆解一下,你看这个小功能是不是一小时就搞定了……”最后,拆解下来统计一下累计时间,发现3天就能搞定了,而且每个功能的小细节都是程序员自己肯定的时间,是不是很有成就感?!这个方法也是你提高项目推动能力的有效方式。

产品经理需求评审会收尾利器——Todo事项列表。一场会议下来,总要讨论出一些结果或者得到一些结论,要不会议就是无效会议。在会议后,接下来应该做什么呢?这就是所谓的行动项,我们要做什么、谁来主要负责、时间点是什么,都要通过邮件发出来,周知所有参会人员以及相关人等,对于达成共识的事情,大家就要按照这个TodoList完成。

产品经理经常会用到的一个词——优先级。做事情要有轻重缓急之分,产品经理的PRD要实现的功能有很多,到底应该先做哪些,如何实施呢?这时候,就需要在里面找出那20%最重要、最需要先做的事情,然后投入80%的时间做这些事情。很多文章都介绍过如何定义优先级以及如何排序,足见其重要性,这里就不多做重复了。如果需求优先级不明确或者有问题,那么可能会导致项目错失市场,甚至无疾而终,最终导致失败。

对于上面讲的这些内容,可能很多人觉得有点形而上。其实,这些都是需要结合我们在工作中的项目和经历不断体会、不断总结、不断完善的。这些方法不仅可以应用于产品工作中,还可以应用到学习和生活中,也会得到意想不到的收获。做产品越久,越发现产品源于生活,产品与生活的这些方法论和思想很多都是相通的。希望大家在数据产品的道路上越走越远,早日形成自己的一套产品理论体系和方法。