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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　1）基础交易闭环

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

　　2）会员管理

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

　　3）基础营销

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

　　4）基础财务

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

　　5）供应链管理

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

　　6）对接管理

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

　　7）数据管理

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

　　8）总结

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

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

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

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

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

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

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

　　1）归类及分层

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

　　业务带来需求，那么业务如何归类？

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

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

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

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

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

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

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

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

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

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

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

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

　　有归类，但不准确。

　　举个例子吧。

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

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

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

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

　　看文字，有归类，看字段，归类去哪里了？

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

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

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

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

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

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

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

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

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

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

　　还以会员举例。

　　查询一个会员信息，需要几步？

　　第一步登录后台；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　后续做优化、删减、扩展，是不是更好做了？

　　2）归属

　　再说开头的归属关系。

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

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

　　第一种：

　　第二种：

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

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

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

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

　　这里，缺了一个归属。

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

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

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

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

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

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

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

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

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

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

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

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

　　具体怎么做呢？

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

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

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

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

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

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

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

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

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

　　再以会员举例。

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

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

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

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

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

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

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

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

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

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

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

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

　　故，简约而不简单。

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

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

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

　　再举个例子：

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

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

　　第一个方案：

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

　　绑定打印机-进入页面2选择打印机品牌-进入页面3扫码识别-确认信息并提交-绑定成功；绑定打印机-进入页面2选择打印机品牌-填写打印机信息并提交-绑定成功（支持扫码的，在打印机ID行展示扫码icon，不支持的不展示扫码icon）。从体验和逻辑上来看，哪个方案更合理呢？

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

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

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

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

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

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

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

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

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

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

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

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

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