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

一、简述

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

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

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