【产品经理】产品经理思维要素

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

在这里插入图片描述

一、简述

1. 背景

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

工作多年,发现部分新入行或者入行时间3年以内的产品身上,存在着不少的思维误区,想通过文章去引导真正热爱产品的同学,有效的提升自我。

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

这里的2B指的是我们的用户是2B的企业、品牌,但其实实际用户是消费者(2C用户)。

2. 个人基本见解

很多人是从其他岗位转岗来做产品经理,也有很多人是通过外部的一些培训机构学习后开始做产品经理。不论是前辈还是培训机构,都会告诉新产品一些必备的能力,包括软技能、硬技能等。

产品经理必备的那些基础软技能,包括理解能力、逻辑分析能力、抽象思维、宏观思维、自驱力、同理心、洞察力、沟通能力、创新能力、执行力、抗压能力、学习能力等。

而硬技能,其实就是工具的使用了。

这两种大方向上的能力要求,就不去花太多的文字进行详细的描述了。

想做好产品经理,是需要天赋+努力的。

从业多年,个人感觉,天赋是要占大半比例的。

我遇到过很多产品经理,起跑线一致、学习努力程度一致,天赋高的半年时间就将天赋低的远远抛在身后了。

天赋这种事没办法解释,但结果确实大相庭径。

当然,天赋并不等于一定会成功,在前期学习阶段,不能够找对方向,很可能就泯然众人了。

天赋之外还有阅历,阅历是通过不断的实践、学习、提升所沉淀的,见得多了,做的多了,看的广了,研究的深了,自然就会加深阅历。

阅历与天赋,在产品职业路线上,相辅相成。

人人都是产品经理的时代,其实已经过去了。

【注:并不是说天赋不高或者没有天赋就不能做产品,但天赋确实会影响职业发展上限的;如果你真正喜欢产品,需要做好自我剖析,选择合适的方向自我提升;其他“误入”产品岗的,建议自省。】

3. 达克效应

1999年,大卫·邓宁(David Dunning)和贾斯廷·克鲁格(Justin Kruger)做了一个著名的心理学实验,并发布论文《论无法正确认识能力不足如何导致过高自我评价》,论文表明:逻辑推理能力最差的受试者对自己的能力排名估计过高,甚至超过了平均水平;而那些逻辑推理能力最好的受试者则低估了自己的能力排名。

这就是达克效应(邓宁-克鲁格效应),指的是能力欠缺的人在自己欠考虑的决定的基础上得出错误结论,但是无法正确认识到自身的不足,辨别错误行为,是一种认知偏差现象。这些能力欠缺者们沉浸在自我营造的虚幻的优势之中,常常高估自己的能力水平,却无法客观评价他人的能力。

如下图,根据达克效应的拆解,有效的人生一般划分了四个大的阶段。

在这里插入图片描述
第一阶段:巨婴-愚昧山峰,不知道自己不知道,自以为是,该阶段一般在刚刚从学校毕业或者在某岗位工作过一两年,觉得自己都学的差不多了,且也有了经验。

第二阶段:自知-绝望之谷,经历过某些特殊的事情后,如雪山崩顶,所有的自信被打击,发现自己其实只是懂了点皮毛,深层次的知识什么都不知道。

第三阶段:智慧-开悟之坡,意识到自己从不足之后,不断的提升学习,这是一个长期阶段,也是一个能够迅速汲入营养的阶段。

第四阶段:大师-平稳高原,这个阶段是一个很特殊的阶段,人生广阔,所学有深有广,学富五车,如果不是特殊场景,可能不一定会发现,自己其实已经懂了很多,说出去的话对别人来说已经充满哲理,对第二第三阶段的人甚至可以达到醍醐灌顶的效果。

拿达克效应来开这一段题,是因为,很多初入产品职场的产品人,甚至部分已经深入产品职场的产品人,其实都卡在第一阶段。

或许刚开始入行还算好一点,知道自己能力浅,说话小心翼翼,但是到了初/中级阶段,就开始飘了,开口就是我认为,我觉得,你不要。

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

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

而行业里,很多产品人在拿到一个新的项目或需求时,已经不做需求调研了,全凭“经验”做事了。

他们为什么会有这种想法呢?

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

可怕的是,很多产品经理长期如此还不自知,站在了那“愚昧之巅”,而这一阶段,很多人一辈子都过不去,比如年纪大以后的倚老卖老等。

大部分人都会经历这样一个自我膨胀的阶段,我也没有例外,只是我能够迅速调整过来,目前处在了第二第三阶段之间。

4. 心态误区

现在,各种行业的管理者都在年轻化,很多公司开始提拔年轻人担任管理或者带领小团队,对于整个产品市场来说,可能还是偏嫩一点,但在特定的小团队里确实是属于优秀的。

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

然后他把自己放在了达克效应的第一阶段:愚昧之巅。

同时,“愚昧之巅”加上虚荣心作祟,让很多初中级产品总把“高级”挂在头衔上,个人建议,每一个产品经理,都应该用SWOT分析工具做一个自我分析。

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

我自己呢,也同样经历过这个阶段,幸好打脸来的快,醒悟的早,醒悟的那一瞬间,真的是大夏天的手脚冰凉、大汗淋漓!

学习的过程中,越学习越觉得自己啥都不会,越学习越觉得自己浅薄。

我现在的状态,毫不夸张的说,就是战战兢兢、如履薄冰。

二、“中台”业务简述

“中台”的定义感觉已经被玩坏了。

我曾经以为中台诞生的目的,是为了解决那些大型企业、大型平台业务强复用需求的,即实现一套基础服务能力,多产品复用。

然而,现在很多软件企业或者是传统转互联网的企业,将中台以位置来理解了,即前台-中台-后台。

阿里在弱化中台,但很多互联网公司还在给各个品牌、企业、甲方鼓吹中台论,用阿里腾讯这些大厂中台做“背书”,来实现自我市场拓展的目标。

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

针对“中台”业务线,我以餐饮行业举例,将2C方向的能力简单列一下:

1)基础交易闭环

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

2)会员管理

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

3)基础营销

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

4)基础财务

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

5)供应链管理

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

6)对接管理

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

7)数据管理

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

8)综述

一般来说,想做好一个2C方向的行业TOP的SaaS或“中台”系统,以上的产品业务能力至少要具备80%以上。

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

所以,作为一名产品人,活到老学到老必须是座右铭。

再看上面一开始提出的产品经理基础能力,如果想做好举例所列的SaaS系统,产品经理要具备什么能力?从我个人整个经历来看,那些软实力、硬实力全部都要运用到。

除了以上所列举的内容之外,其他行业产品怎么做?如何做到一法通万法通?产品经理又区分很多类型,我所列的还是基础行业,再往深了说,还有数据产品、人工智能产品、策略产品、物联网产品、工业产品等等,产品经理是一个很宽宏的方向,我们面前的是波澜壮阔的星辰大海。

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

三、思维方式建议

1. 归类归属及分层

归类,顾名思义,把同类型的东西归集到一起。

再深入一点,还有需求、功能以及数据等,都存在必要的归属关系。

1)业务归类

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

一般来说,甲方(品牌)公司会规划一个或多个业务部门,再将部门拆分很多业务组,比如采购业务组、营销业务组、销售业务组、外卖业务组、堂食业务组、会员业务组、支付业务组、卡券业务组等等。

同时,如果某些组别人数较少、事务较少,但关联度较高,那么这些业务也可能会合并到一个组里,比如把卡券和营销做合并,比如把会员、卡券、营销做合并,比如把外卖、堂食做合并等等。

所以,业务分类其实是基于企业在经营过程中,主要的几条流程逻辑进行规划,且尽可能的不进行交叉归类。因此,从产品侧基于业务类型进行归类,可以考虑以下几种大类:

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

品牌/甲方业务人员带来需求,那么产品侧如何基于业务进行归类?

当对各业务诉求进行有效归类,且互相关联形成闭环的时候,其相对详细的需求归类基于业务归类逻辑细化即可完成了。

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

2)需求归类

当然,并不是说能做好业务归类就一定能做好需求归类。

我遇到过很多需求清单写的很乱的产品经理,第一条是会员需求,第二条是点餐需求,第三条是卡券需求,第四条又是会员需求,这样来回交叉,经常会出现需求重复、需求相似的情况,甚至在这种梳理不清楚的情况,对于伪需求能不能有效判断都是未知数。

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

比如甲方业务侧提了两个需求(举例内容,忽略是否为伪需求):

  • 需求1:会员积分获取支持多方式多来源;
  • 需求2:积分增加手动发放功能。

那么这两个需求是否可以合并,相信任何一个产品经理都可以进行判断及处理。

3)功能归类及分层

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

这些信息已经归类在会员大模块下,同时,各功能之间由根据结构关系,拆分成多个层次。

从会员主模块到功能子模块到具体功能细节,至少可以划分三个层次。

但是当你仔细思考时,你会发现一件很有意思的事,也是很多产品经理在做而不自知的事:

有归类,但不够准确。

举个例子。

从管理后台,查看会员基本信息,在详情页,一般会这么设计:
在这里插入图片描述
一看似乎没有什么问题,简要明确了会员的主要信息。

再往深了看,当该内容给到开发时,数据表结构也这么写吗?如果会员信息多了呢?

应基于会员基础信息、会员资产信息、会员类型、会员权益进行归类。

同时,我们也知道,前端展示的数据是由服务端从数据库获取并提供的。

那么,在产品设计时,直接对信息进行归类的话,可以参考下表:
在这里插入图片描述
深入考虑细节问题,有助于产品经理能够结构化业务类型及需求,有助于开发能够迅速理解需求及各层次关联关系,有助于数据标签匹配,有助于后续的数据分析等。

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

也有产品认为,表结构、表关系这些设计归类工作应该全部由开发人员去做,但是你保证你遇到的都是优秀的开发吗?

出了问题,往前溯源,你同样要承担很大一部分责任。

还有部分产品会觉得,自己只需要提出功能要求,提出体验规范,太细致的,涉及到开发相关的逻辑,精力不够,时间不够,能力也不够。

产品经理懂点技术是必要的!

产品经理应该为自己设计的功能业务逻辑负责,如果业务逻辑不够细致,导致资源浪费,降低产品效率,增加了服务成本,影响用户体验,最终还是产品担责。

再以会员举例。

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

第一步:登录后台。

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

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

第四步:点击会员名称,进入会员详情页。

寻找会员一共用了四步,基本属于市场上设计的标准流程。

可以把诉求再细化一点:查询某会员某一次储值时赠送的券数据。

针对该目的,需要确认会员详情页能不能查询到用户详细的储值信息。

第五步:查看会员详情页,点击储值记录,进入储值记录页面。

第六步:进入储值记录详情页,查找需要的储值信息。

一般来说,很多产品设计做到这里就结束了,想查询赠送的券,需要基于储值时间、储值记录等,再去会员资产子模块中,找到券包进行更深的查询。

假如我们换一个思维:在这一条储值记录加一个弹窗能力,提供弹窗展示的超链或按钮,点击查看详情,以弹窗形式展示本次储值的充值方式、储值金额、赠送金额、赠送积分、赠送优惠券等信息。

留一个扩展思考:在优惠券后面要不要加个按钮跳转到券包?积分后面要不要加个按钮跳转的积分记录?赠金后面要不要加个按钮跳转到赠金记录?金额后面要不要加个按钮跳转到金额变化记录?是否需要支持查询储值赠礼的活动信息和活动记录的一致性?

同时可以思考,功能归类是否可以这样做:各子功能实现交叉,资产跟储值实现交叉,储值跟营销实现交叉?

作为产品人,我们其实都很清楚,展示在Web前端的信息,是通过接口从服务端获取,而服务端又是从数据库拉取的,数据库则是以各种表组成。

而数据库表结构,产品侧是提供了相对基础的归类和分层建议的。

再深入思考,这些表存在交叉吗?

(建议了解一下关系型数据库与非关系型数据库)

在产品场景化问题上,还需要在调研阶段确认该能力是使用普遍性高不高,谁在使用这个功能,业务人员还是运营?或者是其他人员。

从业务到需求到功能到数据的归类及分层,在产品设计阶段就应该做好规划,需要明确,功能做归类,适用于哪些用户类型,多角色之间的功能兼容度做到什么程度更合适。

当产品功能越做越多,你一眼看过去感觉有些乱,但拉出任何一条线,都可以形成闭环,且底层的逻辑是顺畅的,产品就是优秀的。

但在设计时需要遵循一个原则,“乱和复杂”是产品和开发层面的,对于实际使用者,不论是B端用户还是C端消费者,理应是简约流畅的。

对于2C或2B的页面的体验设计,取决用使用者的诉求,如果相应的调研样本偏少,就比较考验产品经理的同理心了。

设计产品页面结构,需基于使用该产品的用户类型进行规划,如业务人员提的需求,产品进行归类、设计,评审完成后由最终开发codeing,最终发版上线,业务好用、运营好用,数据归类清晰层次分明、主表子表结构清爽,有效的减少一张无限长的大表所带来的冗杂繁复。

在后续的优化、删减、扩展等版本迭代上,不论是产品还是开发,其效率将变的更高。

4)归属关系

沿用前面的例子。

  • 需求一:会员积分获取多方式多来源;
  • 需求二:积分增加手动发放功能。

针对第一个需求,作为产品经理,可以很轻松就能列出很多获取积分的方式,我们本节需求二来举例。

这个例子是一个真实的案例,是我几年前参与某一个项目时,某前任产品留下的其中一个坑。

因为特殊原因,需要给某一位或者某几位会员单独增加积分,当时负责的产品直接以下方方式增加。

在会员详情页积分数额后面,放了一个加号的icon,点击弹窗:
在这里插入图片描述
从单一场景来说,似乎这么做没有问题。

但产品经理不应该只考虑单一场景,而是应该延伸去考虑,比如积分清算、积分溯源、积分成本扣减时,这些没有归属的积分所产生的金钱成本谁来承担?

在做积分消耗时,我们会把积分产生的成本归属到对应的门店、分公司或总部或特殊组织,那么上面这种做法,应该如何分辨积分归属,成本谁来承担?

或者从操作员身份来判断?需要绕几个圈圈?如果操作员对应的角色和权限的归类和分层没做好,导致无法区分或区分的难度更大呢?

这里,缺少归属。

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

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

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

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

2. 追根究底

不论产品面对的是C端用户还是B端用户,需求的来源都是多样性的,作为产品经理,在正式设计规划前,至少需要做好3件事:

  1. 需求归类;
  2. 需求判断;
  3. 确认优先级。

需求归类在上一段已经做了描述,这里就不再赘述。

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

本节重点分享第二点,需求判断。

这一点,目前很多初中级产品可能会存在思考不足的情况。

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

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

该如何去找到跟需求?

产品经理应进行结构化思考,了解需求转化成功能后,其作用是什么?有无当前可替代的能力?有无类同的需求?

同时,进行功能推演,将自己代入到实际使用者,梳理全部业务流程,包括正逆向,包括与周边功能的关联性,是否能够有效提升体验,是否会影响其他业务能力。

我们仍以会员手动增加积分的需求来举例。

当拿到这个需求后,产品经理第一步进行归类,将其归到会员主业务、积分子模块中。

第二步思考这个功能的作用,同步考虑为用户增加积分的特殊场景,如某活动发放积分失败补偿、投诉及其他类型补偿等,目的是为了增强用户体验,提升服务质量;同时,还需要考虑业务能力的使用者,如客服、运营、营销、业务人员等。

还需要考虑其他有可能产生该需求的场景。

第三步,找到功能定位,列出关联项。积分增加手动新增能力的需求,其涉及到了积分获取方式,涉及到了积分发放归属,涉及到了积分成本分配,涉及到了积分获取记录,涉及到了积分来源溯源,涉及到了积分金额核算等。

所以,对需求应该尽可能的做到寻根究底。

3. 简约而不简单

在进行产品设计时,应做到页面、功能、业务逻辑简约自然,不繁复。

我刚入行的时候,我的引路人说过这样一句话:要让用户傻瓜式操作。

简约≠简单。

做产品体验设计,也需要有深层次思考,考虑使用过程、考虑使用习惯、考虑使用的简便性、考虑页面流转、考虑与周边能力的关联性、后续可持续的拓展性等。

再以会员举例。

做B端会员详情页时,很多的产品经理恨不得一股脑把所有信息都放进去,比如:
在这里插入图片描述
在这里插入图片描述
类似这些信息,在会员详情页一次性全部展示,且内容繁多。一眼看去除了数据多一点,似乎没什么问题。

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

业务、运营、营销还是客服?

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

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

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

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

对功能和字段归类,对内容基于重要程度进行分层。

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

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

这种做法,同时可以进行有效的数据权限限制。

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

4. 逻辑体验

我们刚入行时,一定被前辈叮嘱过:2C产品重体验,2B产品重逻辑。

时代在进步,行业在发展,这句话也要更新迭代:不论是2C还是2B,都应该是体验与逻辑性共存。

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

举个例子:

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

但是,这两台云打印机属于不同的品牌,一个支持扫码绑定,一个不支持。那么,在做绑定功能时,应该怎么做?先看看这两种设计:
在这里插入图片描述

第一个方案

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

第二个方案

  1. 绑定打印机-进入页面2选择打印机品牌-进入页面3扫码识别-确认信息并提交-绑定成功
  2. 绑定打印机-进入页面2选择打印机品牌-填写打印机信息并提交-绑定成功

(支持扫码绑定的品牌,在打印机绑定页展示扫码跳转icon,不支持的不展示扫码icon)

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

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

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

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

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

5. 反向思维

每一个产品经理都应该做到避免蒙眼造需求。

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

同时要考虑,辅助功能引起事故的责任定位问题。

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

因担心门店人员不会绑定云打印机,产品经理打算在管理后台增加远程绑定功能,通过运营协助门店绑定打印机(运营操作)。

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

  1. 是否考虑过给运营人员增加了多少工作量?
  2. 如果运营人员绑错了门店怎么办?
  3. 第二个问题的延续,绑错之后造成了业务失误谁来承担?
  4. 如果是门店提供的信息错误导致运营绑定错误该谁来承担?
  5. 如果所有门店人员知道能够由运营远程绑定,都上报工单说自己不会,申请远程绑定怎么办?
  6. 如果门店操作硬件设备失误,导致远程绑定一直不成功或错误,影响了运营的其他工作内容,又影响了自己门店甚至其他门店的营业,该如何处理?

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

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

四、探讨

1)以小处着手、大处着眼,做到透过现象看本质,了解需求背后的意图,找到需求的根。

2)摸人性,从社会心理学角度去剖析用户心理,提升同理心,有效基于人性优化产品力。

3)明社会,闭门造车不可取,要了解社会现状,紧跟实事,紧跟政策,紧跟(超前)行业,别被大势淘汰。

4)鉴行业,紧盯竞品甚至周边关联需求,行业从来不是以一刀切的方式区分的,很多行业之间存在互通关联甚至竞争关系(修车摊不是被同行干掉的,干掉它的是共享单车),学会借鉴竞品、借鉴类同行业做法再创新。

5)把控细节、结构化思考、宏观战略组合拳模式打出去,定义产品核心战略发展方向。

6)抽象思维能力=无数次具象后的推演能力,多学习、多实践、多思考、多复盘、举一反三,形成自己的知识体系,才能够在面对业务需求时,瞬间抽象出实现方法,做到脑中有画面,表达有条理。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mfbz.cn/a/390.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

【C++】模板(上)

文章目录1、泛型编程2、函数模板函数模板的实例化模板参数的匹配原则3、 类模板类模板的实例化1、泛型编程 void Swap(int& left, int& right) {int temp left;left right;right temp; } void Swap(double& left, double& right) {double temp left;left …

智慧水务监控系统-智慧水务信息化平台建设

平台概述柳林智慧水务监控系统(智慧水务信息化平台)是以物联感知技术、大数据、智能控制、云计算、人工智能、数字孪生、AI算法、虚拟现实技术为核心,以监测仪表、通讯网络、数据库系统、数据中台、模型软件、前台展示、智慧运维等产品体系为…

全网独家首发|极致版YOLOv7改进大提升(推荐)网络配置文件仅24层!更清晰更方便更快的改进YOLOv7网络模型

有不少小伙伴和我交流YOLO改进的时候,都说YOLOv7的网络配置文件长达104层,改起来很费力,数层数都要数很久,还很容易出错,而且基于YOLOv5代码架构,Debug起来也确实比较费时,所以博主对YOLOv7网络…

CSDN新星计划新玩法、年度勋章挑战赛开启

文章目录🌟 写在前面🌟 逐步亮相的活动🌟 勋章挑战赛🌟 新星计划🌟 有付费课程才可参与?🌟 成就铭牌🌟 博客跟社区的关系🌟 写在最后🌟 写在前面 哈喽&#…

【java】 java开发中 常遇到的各种难点 思路方案

文章目录逻辑删除如何建立唯一索引唯一索引失效问题加密字段模糊查询问题maven依赖冲突问题(jar包版本冲突问题)sql in条件查询时 将结果按照传入顺序排序数据库主从复制 主从不同步问题数据库读写分离 读写不一致java服务如何作为websocket客户端spring…

2023年度数学建模竞赛汇总

本人7年数学建模竞赛经验,历史获奖率百分之百。团队成员都是拿过全国一等奖的硕博,有需要数模竞赛帮助的可以私信我。 下面主要列几年一些比较有含金量的数学建模竞赛(按比赛时间顺序) 1. 美国大学生数学建模竞赛 报名时间&…

想要成为高级网络工程师,只需要具备这几点

首先,成为高级网络工程师的目的,就是为了搞钱。高级网络工程师肯定是不缺钱的,但成为高级网络工程师你一定要具备以下几点:第一 心态作为一个高级网工,首先你必须情绪要稳定,在碰到重大故障的时候不慌&…

一个9个月测试经验的人,居然在面试时跟我要18K,我都被他吓到了····

2月初我入职了深圳某家创业公司,刚入职还是很兴奋的,到公司一看我傻了,公司除了我一个测试,公司的开发人员就只有3个前端2个后端还有2个UI,在粗略了解公司的业务后才发现是一个从零开始的项目,目前啥都没有…

R语言编程基础

文章目录安装运算符判断函数递归安装 根据自己的操作系统,下载R语言环境后,安装,并将安装路径加入到环境变量,即可从命令行进入R环境 >rR version 4.2.2 (2022-10-31 ucrt) -- "Innocent and Trusting" Copyright …

Spring Cloud学习笔记【服务注册与发现-Eureka】

文章目录什么是服务治理什么是服务注册与发现Eureka两组件Eureka搭建搭建单机Eureka ServerEureka客户端注册user服务user服务单点测试搭建集群Eureka Server集群启动测试子服务集群搭建服务调用和负载均衡测试效果什么是服务治理 服务治理是一种管理和控制分布式系统中各个服…

基于51单片机的智能计算器Protues仿真设计

目录 一、设计背景 二、实现功能 三、硬件设计 3.1 总体硬件设计 ​3.2 键盘电路的设计 3.3 显示电路的设计 四、仿真演示 五、源程序 一、设计背景 随着社会的发展,科学的进步,人们的生活水平在逐步的提高,尤其是微电子技术的发展&am…

【数据结构】基础知识总结

系列综述: 💞目的:本系列是个人整理为了数据结构复习用的,由于牛客刷题发现数据结构方面和王道数据结构的题目非常像,甚至很多都是王道中的,所以将基础知识进行了整理,后续会将牛客刷题的错题一…

大数据技术之Sqoop——SQL to Hadoop

一、简介sqoop (sql to hadoop)是一款开源的工具,主要用于在 Hadoop(Hive)与传统的数据库(mysql、postgresql...)间进行数据的传递,可以将一个关系型数据库(例如 : MSQL,Oracle,Post…

Unity脚本练习

在C# 中 class 是创建类的标志,要创建类的话得现有class上面这个的逻辑是 类的访问权限, 关键字,类名以及类继承的父类在Unity中创建一个脚本或者添加一个组件,就相当于在Unity命名空间中创建了一个可以访问的类。这些类能够直接在…

2023秋招前端面试必会的面试题

浏览器存储 我们经常需要对业务中的一些数据进行存储,通常可以分为 短暂性存储 和 持久性储存。 短暂性的时候,我们只需要将数据存在内存中,只在运行时可用持久性存储,可以分为 浏览器端 与 服务器端 浏览器: cookie: 通常用于存储…

springboot健身房管理系统

springboot健身房管理系统 ✌全网粉丝20W,csdn特邀作者、博客专家、CSDN新星计划导师、java领域优质创作者,博客之星、掘金/华为云/阿里云/InfoQ等平台优质作者、专注于Java技术领域和毕业项目实战✌ 🍅文末获取项目下载方式🍅 一、项目背景介绍&#xf…

Vue 3.0 单文件组件 【Vue3 从零开始】

#介绍 在很多 Vue 项目中,我们使用 app.component 来定义全局组件,紧接着用 app.mount(#app) 在每个页面内指定一个容器元素。 这种方式在很多中小规模的项目中运作的很好,在这些项目里 JavaScript 只被用来加强特定的视图。但当在更复杂的…

HTTP 3.0来了,UDP取代TCP成为基础协议,TCP究竟输在哪里?

TCP 是 Internet 上使用和部署最广泛的协议之一,多年来一直被视为网络基石,随着HTTP/3正式被标准化,QUIC协议成功“上位”,UDP“取代”TCP成为基础协议,TCP究竟“输”在哪里? HTTP/3 采用了谷歌多年探索的基…

< CSS小技巧:那些不常用,却很惊艳的CSS属性 >

文章目录👉 前言👉 一. background-clip: text - 限制背景显示(裁剪)👉 二. user-select - 控制用户能否选中文本👉 三. :focus-within 伪类👉 四. gap - 网格 / 弹性布局间隔设置👉…

【C++笔试强训】第三十一天

🎇C笔试强训 博客主页:一起去看日落吗分享博主的C刷题日常,大家一起学习博主的能力有限,出现错误希望大家不吝赐教分享给大家一句我很喜欢的话:夜色难免微凉,前方必有曙光 🌞。 选择题 &#x…
最新文章