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

一、简述

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,都应该是体验与逻辑性共存。

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

举个例子:

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

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

第一个方案:

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