产品经理思维要素包括「产品经理人思维」

互联网 2023-03-16 13:47:18

今天给大家普及一下产品经理思维要素包括「产品经理人思维」相关知识,最近很多在问产品经理思维要素包括「产品经理人思维」,希望能帮助到您。

编辑导语:产品思维对于产品经理来说十分重要,能够有效提升工作效率和工作质量。本文作者分享了有关产品经理思维要素的相关内容,从思维误区、思维方式建议、理性思维探讨展开分析,一起来学习一下吧,希望对你有帮助。

一、概述1. 背景

先简单说说为什么写这篇文章。

作为很久(其实也就两三个月)没有在产品前线工作的产品人,前几天参加了几场内部的产品内审会,发现少部分新入行或者入行时间3年以内的产品身上,有着不少的思维误区。

需要说明的是,本文基于2B餐饮茶饮行业进行撰写,不一定适用于其他行业及其他类型产品。

2. 思维误区

对于产品经理必备的那些基础技能,包括理解能力、逻辑分析能力、抽象思维、宏观思维、自驱力、同理心、洞察力、沟通能力、创新能力、执行力、抗压能力、学习能力等,这些网上写烂了的,就不去花太多的文字进行详细的描述了。

就从以上列出来的几点,大部分靠的其实还是天赋及阅历。

天赋这种事没办法解释,有天赋的3天入门三年大成,没天赋的,3个月入门,13年都不一定能大成。

再说阅历,其实就是不断的实践、学习、提升,见得多了,做的多了,看的广了,研究的深了,自然就从入门到初级到中级到高级到大牛了。

初级产品还算好一点,知道自己能力浅,说话小心翼翼,但是有些产品经理到了中级阶段,就开始飘了,开口闭口就是我认为XXXX,我觉得XXXX,你们不要XXXX。

甚至有些产品做到高级层次,依然会有这种很奇怪的“我认为”思维。

我记得有句话说,不要用你以为的去揣测真实用户的需求,那样你只会距离他们越来越远。

他们为什么会有这种想法呢?我很想说,这叫半瓶子晃荡。

大部分人都会经历这样一个自我膨胀的阶段,我也不例外,只是我能够迅速调整心态。

为什么会这样呢?做了几年产品了,做的多了,见的多了,自以为能力已经非常强了,同理心已经融会贯通,洞察力已经深嵌思维了,拿着以往的经历及片面的知识去肆意下结论了。

可怕的是,很多产品经理长期如此还不自知。

3. 心态变化

现在呢,很多公司,不论大小,都开始提拔年轻人担任管理或者带领小团队,或许这些人在小团队里确实是优秀的,但对于整个产品市场来说,其实还是偏嫩一点。

提拔你,不是因为你特别强,而是你目前的能力可能比其他产品高那么一点,也是认可你的潜力,培养你多方面的能力,你要做的是谦虚谨慎前行,但是有些人开始膨胀了,自认为能够承担这样的角色是因为自己实力特别强。

是个产品总想把高级挂在头衔上,回头拿那些分析工具用在自己身上试试,是高级不?

一般来说,心态的变化会产生两条很大的分裂方向,第一个是很快受到打击,发现自己只是矮子里拔高的那一个,往远处看,高个子一大堆,然后尽快调整自己提升自己(也可能自暴自弃了),第二个则是越发膨胀,除了自己,其他人都是渣渣,然后认为薪酬和实力不匹配,开始有了乱七八糟的心思,后续就不用细说了,明白的都明白。

我自己呢,也一样经历过这个阶段,幸好打脸来的快,醒悟的早。

我又想起了一句话这么说的:越学越觉得自己浅薄,越学越觉得自己啥都不会。

我现在就是这种状态,说夸张一点就是如履薄冰了。

4. 业务逻辑主线

我以前做电商、现在做餐饮,但不论做什么,很多业务逻辑是相通,就是所谓的殊途同归,同样的,随着国内各种行业开始数字化、物联网化,业务逻辑线也越来越长。

你敢保证你整条业务链都懂吗?我以餐饮举例,简单列一下吧:

1)基础交易闭环

门店管理、商品管理、橱窗管理、菜单管理(货架)、定位判断、业务类型(自提、堂食、外卖)、订单管理(正逆向)、POS对接、支付/退款方式(微信、支付宝等)、硬件对接(自助点餐、自提柜、小票机等)等;

2)会员管理

注册来源、注册方式、基础信息、社会属性、会员标签、会员画像,与订单、消费信息(客单、频率等)关联,会员资产(积分、储值、其他资产)、会员类型(普通、付费)、会员等级、会员权益等;

3)基础营销

卡券能力(优惠券、储值卡、礼品卡、会员卡、体验卡等),会员生命周期个阶段营销方式,基于券的营销,基于活动的营销,精准营销(基于用户标签及画像分析)等;

4)基础财务

订单/账单对账、门店分账对账、积分对账、储值卡对账、优惠券对账、分类账、明细账、依据对账结果输出的会计分录,电子发票管理;这里还存在两个很有意思的场景,一个是多个品牌积分互通的财务转换处理,一个是财务侧视同销售的活动营销;

5)供应链管理

供应商管理、分公司管理、门店管理(直营和加盟的区分)、采购管理(成品、半成品、物料BOM、门店及分公司计划采购)、仓储库存管理(门店/分公司上报、入库、出库、盘库)、物流管理(供应商对总部、供应商对分公司/门店、总部对分公司/门店、分公司对门店)、销售管理(总部对分公司、总部对门店、分公司对门店等、门店对用户)、成本管理(商品成本、人工成本、水电房租成本、物流成本等)、财务管理(营收占比、利润率、坪效分析、采购计划金额、阶段预算等)等;

6)对接管理

各种三方平台对接(美团、饿了么等),各种配送及物流对接(达达、顺丰、美团、饿了么、快递100等),各种支付对接(微信、支付宝、银联、聚合支付、银行数字货币),地图对接(高德、百度、腾讯等)等;

7)数据管理

需要区分数据统一及基础数据分析,数据统一包括数据的获取(包括自有系统及三方平台)、源数据存储(方便溯源)、数据清洗、数据标准化、数据存储,数据归类;基础数据分析包括会员分析、订单分析、商品分析、储值分析、营销分析、ROI分析、门店分析、各类业务环比同比分析、C端用户体验分析、B端使用分析、服务器算力分析、客单价分析等。

8)总结

先列这么多吧,已经很多了。

一般来说,想搞一个行业TOP的SaaS系统,以上的产品能力至少要具备80%吧。

而且相互之间的关联性极多,各种业务功能有着串联、并联以及交叉的复杂关系,当系统复杂度达到一定程度的时候,牵一发而动全身。

所以,活到老学到老是必须的。

再看上面一开始提出的产品经理基础能力,如果想做好上面简单的SaaS系统,你要具备什么能力?好像都要有吧,而且还要扎实。

除了以上所列举的内容之外,其他行业产品怎么做?如何做到一法通万法通?产品经理又区分很多类型,我所列的还是基础行业,再往深了说,还有数据产品、AI产品、策略产品、物联网产品、工业产品等等,你还玩得转吗?

所以,面对行业内卷越来越严重,基于产品经理基础能力,我整理了几条思维相关的建议。

二、思维方式建议1. 归类归属及分层

1)归类及分层

归类,顾名思义,把同类型的东西规整到一起。再深一点,还有必要的归属关系。

业务带来需求,那么业务如何归类?

业务是一个比较宽泛的词,在产品侧,业务几乎就是全部前端能力或体验的代名词了,比如外卖业务、自提业务等。

于是,很多甲方公司会设定一个业务部门,拆分很多业务组,比如采购业务组、营销业务组、销售业务组、外卖业务组、堂食业务组、会员业务组、支付业务组、卡券业务组等等。

同时呢,小一点的但关联度高的业务也可能会合并到一个组里,比如把卡券和营销做合并,甚至把会员、卡券、营销做合并,把外卖、堂食做合并等等。

所以,业务分类其实也很明朗了,尽可能的不做交叉归类,基于业务类型进行归类,比如:

点餐业务、支付业务、会员营销业务、储值业务(也有把储值归类到会员里的)、数据业务、财务等。

当各业务归类,且互相关联形成闭环的时候,其需求归类也就好做了。

基于业务归类对需求进行归类整理。

我遇到过很多需求清单写的很乱的产品经理,第一条是会员的,第二条是点餐的,第三条是卡券的,第四条又是会员的,这样来回交叉,经常会出现需求重复、需求相似的情况。

基于业务类型进行需求归类时,能够有效的杜绝需求重复或类同的情况,也能够协助判断需求的合理性、紧急程度等,有助于去伪存真,预设优先级,并可以基于归类,对需求进行有效合并。

比如甲方业务侧提了两个需求,分别是会员积分获取支持多方式多来源、积分增加手动发放功能(举例内容,忽略是否为伪需求),那么这两个需求是否可以合并,相信任何一个产品经理都可以进行判断了。

随后便是功能归类,以会员为例,会员是一个大模块,其子模块包含了基础信息、标签信息、画像、会员资产等,每一个子模块下又会有下级模块,比如会员资产下有积分、集点、卡、券等资产数据。

其归类在会员属性下,同时又有了分层关系,从主模块会员到子模块到具体功能,其实已经分了三层,从以上文字所述,各层直接泾渭分明,已经很清爽了,但是当你仔细思考时,你会发现一件很有意思的事,也是很多产品经理在做而不自知的事:

有归类,但不准确。

举个例子吧。

从管理后台,查看会员基本信息,在详情页,一般会这么设计:

一看没啥问题吧,简要明确了会员的主要信息。

再往深了看,你给开发的时候,表也这么写的,如果会员信息多了呢?

会员基础信息、会员资产信息、会员类型、会员权益。

看文字,有归类,看字段,归类去哪里了?

可以想一想,后续做数据分析使用你数据的时候,你没有归类,是否会造成数据处理复杂度增加呢。

同时,我们也知道,前端展示的数据是服务端提供的。

那么在产品设计时,你直接对信息进行归类的话:

细节问题,有助于你结构化业务类型及需求,有助于开发能够迅速理解需求及各层次关联关系,有助于标签匹配,有助于后续的数据分析。

换一个角度,仍以会员为例,某一个会员从注册时间、注册方式开始,到类型、等级、资产、权益、会员旅程等,经常在变化,如果能够提前做好约束,拆分主表及子表,那么数据更新时,动作小,对服务端资源的消耗是否会降低呢?

也有产品认为,太细了,这些归类开发人员会做的,但是你保证你遇到的都是优秀的开发吗?

出了问题,往前翻,是你的问题,不是他的问题。

有些产品又会说了,我只提功能,提规范,太细的话精力不够,时间不够。

来吧,是个产品经理都应该为你设计的功能业务逻辑负责,你的逻辑不够细,导致资源浪费,降低产品效率,增加了服务成本,影响用户体验算不算你的?

这还只是需求归类及分层,再往下又是功能归类了。

还以会员举例。

查询一个会员信息,需要几步?

第一步登录后台;

第二步进入会员模块,一般默认进入的是列表页;

第三步搜索会员ID或手机号或昵称等均可,查出会员;

现在会员找到了,用了四步,标准流程嘛。再细一点,查询会员某一次储值赠送的券数据。

这个时候,你就要看会员详情页能不能看到详细的储值信息了。

第五步,会员详情页,点击储值记录,进入储值记录页面;

第六步,储值记录页面,查找需要的储值信息。

一般来说,很多产品经理做到这里就结束了,想查赠送的券,需要对比时间,再去会员资产券包中查询。

换一个思维呢,在这一条记录加一个按钮,查看详情,展示本次充值的金额、充值方式、赠金、积分、送券等信息。

好了,看到了信息了,那么记录里有就真的有了吗?在券后面要不要加个按钮跳转到券包啊?积分后面要不要加个按钮跳转的积分记录啊?赠金后面要不要加个按钮跳转到赠金记录啊?金额后面要不要加个按钮跳转到金额变化记录啊?是不是还要查一下储值赠礼的活动信息和记录是否一致啊?

回到正题,功能归类这样做可以吗?各个子功能交叉,资产又跟储值交叉,储值又跟营销交叉。

来,再换个思维,这些是展示在Web端的数据,数据从数据库拉取的,数据库是表结构。

表结构你是做好归类和分层的。

再想一想,这些功能交叉了吗?没有,只是增加了跳转而已。

这里涉及到场景化问题了,具体怎么做,要看这个功能是使用普遍性高不高,谁在用这个功能,业务人员还是运营?

这个例子不好举,但从业务到需求到功能导数据的归类及分层,其实在产品设计阶段就做好了,在设计阶段就需要搞清楚,功能如何做归类,都适用于哪些人,多角色之间的功能兼容度做到什么程度更合适,当产品功能越做越多,你一眼看过去感觉有些乱,但是透过现象看本质,底层的逻辑是顺畅的,产品就是优秀的。

而页面的设计取决用使用者的诉求。

你设计的产品页面结构需求基于使用该产品的人员结构进行规划,兜兜转转又回到了最初,业务人员提的需求,你进行了归类及设计,最终开发完了,业务好用、运营好用、开发一目了然、数据归类清晰层次分明,主表子表结构,又能够有效的减少一张无限长的大表所带来的冗杂繁复。

后续做优化、删减、扩展,是不是更好做了?

2)归属

再说开头的归属关系。

沿用前面的例子,需求是会员积分获取多方式多来源、积分增加手动发放功能,作为产品经理,很轻松就能列出很多获取积分的方式,我们单拿手动增加积分的功能来说吧。

我曾经遇到过一种情况,因为特殊原因,需要给某一位或者某几位会员增加积分的,当时负责的产品直接以下方结构增加。

第一种:

第二种:

在会员详情页积分数额后面,放了一个加号的icon,点击弹窗:

从单一场景来说,似乎这么做没有问题。

换一个场景看看,积分清算、积分溯源、积分成本扣减时,这些没有归属的积分产生的金钱成本谁来承担?

在做积分消耗时,我们会把积分产生的成本归属到对应的门店、分公司或总部,那么上面这个做法,应该谁来承担?或者从操作员身份来判断?需要绕几个圈圈?如果操作员的归类和分层没做好无法区分或区分的难度大呢?

这里,缺了一个归属。

我提了个建议:加一个归属门店字段,预设枚举包括现有的全部门店、总部、分公司,如果总部和分公司字段在其他功能体系中都没有,且只支持门店归属,还可以开一个虚拟门店或多个虚拟门店,将积分归属到对应的虚拟门店。设定该业务能力权限,门店人员只能选择自己权限匹配的门店或者预设的虚拟门店。

这样一来,做积分清算时,可以直接把这部分积分归类到对应的门店,由相应的门店来承担。

但是还有个问题,如果这部分积分需要多方同时承担呢?如总部、分公司、门店各自承担一部分?大家应该都知道该怎么设计了,无非是指定数额或按比例。

举这个例子,也是为了表明,在产品功能设计阶段,归属关系的重要性。

所以,产品经理,是个细致活。

2. 追根究底

这个点需要与实际场景做关联。

不论你做的产品面对的是C端用户还是B端用户,你的需求都会有很多来源,作为产品经理,需要做好3件事:

需求归类在上一段已经做了描述,就不细说了。

优先级判定应该基于目前产品的阶段及需求内容进行判断,比如大家常说的紧急重要、紧急不重要、重要不紧急、不重要不紧急等等。

重点说一下需求判断,这一点,目前很多初中级产品可能会思考不足。

需求判断最根本的目的是去剖析了解需求的核心目的,即透过需求看本质,找到最核心的根需求。判断时,需代入相应的角色,如市场角色、使用者角色等。

找到需求的根本,可以实现2件事,第一去伪,第二定位。去伪自然是筛掉伪需求,定位是为了确定该需求的使用场景。

具体怎么做呢?

结构化思考,该需求转化成功能后,其作用是什么?有无当前可替代的能力?有无类同的需求?

功能推演,将自己代入到实际使用者,梳理全部业务流程,包括正逆向,包括与周边功能的关联。

我们还以会员手动增加积分来举例。

当提出这个需求后,第一步归类到会员主业务、积分子业务模块中。

第二步思考这个功能的作用,特殊场景下,为用户增加积分,如某活动发放积分失败补偿、投诉及其他补偿等,目的是为了保护用户体验,提升服务质量,同时,还需要考虑,这个功能一般谁来使用,可以是客服、运营、营销、业务人员等。还需要考虑其他有可能产生该需求的场景。

第三步,找定位,寻根本,列关联。积分补充能力,其涉及到了积分获取方式,涉及到了积分发放归属,涉及到了积分获取记录,涉及到了积分来源溯源,涉及到了积分成本核算等。

如此,需求的追根究底算入门了。

3. 简约而不简单

设计时,页面、功能、业务逻辑做的简约,一目了然,不繁复。

简约≠简单,需要有深层次思考,考虑与周边能力的关联性、后续可持续的拓展性等。

再以会员举例。

会员详情页很多的产品恨不得一股脑把所有信息都放进去,比如:

类似这些信息,在会员详情页一次性展示全了,且内容繁多。

一眼看去除了数据多一点,似乎没什么问题。

但,请静下心想一想,谁,哪个角色需要看会员详情信息,还要看到这么多的数据?

业务、运营、营销、客服?这些信息展示的目的是什么?是为了让需要的角色来查询相关的信息的,那么什么角色会查呢?他必须一次性看到全部信息吗?他是否能够迅速从这么多信息里找出他所关心的信息呢?

那有没有另一种可能,每个角色需要的信息也不一样?

再考虑一个权限功能,之前的例子里提到了手动增加积分可以在会员详情进行配置,那么这个权限限制了哪些角色?

反反复复又回到了上面的建议,归类和分层。

对功能和字段归类,对内容进行分层。

基于分层做权限,基于归类区分主表及子表,默认展示主要信息,其他的不重要的,放到更细的下一层详情里。

那么,当指定角色进入到该页面时,看到是只是十来个主要字段信息,再细的或者扩散的信息,点击对应的字段名称或数据前往下一层查看即可。

如此,在设计上符合归类、分层、归属的思维,体验上又简约大方,核心信息一目了然。

故,简约而不简单。

4. 逻辑体验

我们回想一下刚入行时被前辈一直叮嘱的话:2C产品重体验,2B产品重逻辑。

随着时代的进步,行业的发展,这句话要改一下了。不论是2C还是2B,都是体验与逻辑性共存。

所以,我们产品需要从多维度思考业务逻辑及用户体验,多维度指的是用户维度,用户包含涉及产品的全部用户(使用者、管理者),包括2C2B2G等。同时,在做产品设计时,同步考虑功能在服务端的执行效率,尽可能减少甚至杜绝浪费资源的做法。

再举个例子:

某品牌需要给门店安装两台云打印机,分别是标签打印机和小票打印机,这两台打印机均需要通过后台绑定到系统门店上,才能有效的给茶饮咖啡订单打印杯贴标签及订单小票。

但是,这两台云打印机属于不同的品牌,一个支持扫码绑定,一个不支持。那么,你在做绑定功能时,是怎么做的呢?看看这两种设定吧:

第一个方案:

绑定打印机-选择扫码绑定-扫设备二维码识别-识别成功-确认信息提交-绑定成功;绑定打印机-选择扫码绑定-扫设备二维码识别-识别失败-返回页面2-手动绑定-进入页面3配置信息并提交-绑定成功;绑定打印机-页面2选择手动绑定-进入页面3配置信息并提交-绑定成功。

第二个方案:

绑定打印机-进入页面2选择打印机品牌-进入页面3扫码识别-确认信息并提交-绑定成功;绑定打印机-进入页面2选择打印机品牌-填写打印机信息并提交-绑定成功(支持扫码的,在打印机ID行展示扫码icon,不支持的不展示扫码icon)。

从体验和逻辑上来看,哪个方案更合理呢?

先说第一个方案,3层页面关系,50%的几率扫码识别失败,同时这失败的50%需要调用服务端能力;再说第二个方案,2层页面关系,基于预设打印机信息,判断是否需要支持扫码;

从体验上来说,第一个方案页面多,易扫码失败,用户体验差,第二个方案页面少,扫码失败几率低,用户体验好。

从逻辑上来说,第一个方案链路长度比第二个方案多一条,同时易错率大于第二个方案。

忽略其他关联性因素,纯以上面这个功能来对比,个人建议方案二,体验及逻辑的并存。

5. 关联性反对思维

要做到避免蒙眼造需求,你以为的不一定是你以为的,你以为的,或许会降低产品效率且增加多重复杂问题,当你为某一个角色提供你所认为的辅助功能时,应考虑是否会对其他用户甚至整个产品产生影响。

还可能会存在出了事故责任定位问题。

同样,举上面云打印机的例子。

某产品害怕门店人员不会绑定云打印机,打算在管理后台增加了远程绑定功能,通过运营协助门店绑定打印机。

在面对这个主动需求时,我们提出了以下问题:

如果运营绑错了门店怎么办?第一个问题的延续,绑错之后造成了业务失误谁来承担?如果是门店提供的信息错误导致运营绑定错误该谁来承担?如果所有门店知道能够远程绑定,都上报工单说自己不会,申请远程绑定怎么办?如果门店操作硬件设备失误,导致远程绑定一直不成功或错误,影响了运营的其他工作内容,又影响了自己门店甚至其他门店的营业,该怎么处理?

包含且不仅仅是以上问题。

所以,产品经理在“造”需求时,或者在分辨类似的需求时,多思考,多判断,多推演,学会质疑,学会反对。

三、理性思维探讨以小处着手、大处着眼,做到透过现象看本质,了解需求背后的意图,找到需求的根;摸人性,从社会心理学角度去剖析用户心理,提升同理心,有效基于人性优化产品力;明社会,闭门造车不可取,要了解社会现状,紧跟实事,紧跟政策,别被大势淘汰;鉴行业,紧盯竞品甚至周边产品,行业从来不是以一刀切的方式区分的,很多行业之间存在互通关联关系,学会借鉴竞品、借鉴类同行业做法再创新;把控细节、结构化思考、宏观战略组合拳模式打出去,定义产品核心战略发展方向;抽象思维能力=无数次具象后的推演能力,多学习、多实践、多思考、多复盘、举一反三,形成自己的知识体系,才能够在面对业务需求时,瞬间抽象出实现方法,即脑中有画面,表达有条理。

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

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