分类： iSpiik产品说

作为产品经理，在日常工作中难免需要处理各种复杂问题，提升工作效率和质量。在这一过程中，MECE原则绝对是一个不可或缺的得力助手。MECE原则，即Mutually Exclusive Collectively Exhaustive，意为“相互独立，完全穷尽”，可以帮助产品经理在产品设计、产品迭代和产品问题分析等多个环节中保持清晰的思路和高效的行动。

一、MECE原则简介及其应用场景

MECE原则由麦肯锡咨询顾问巴巴拉·明托提出，是一种用于对问题进行结构化分析和解决的思维方式。这一原则要求我们在分析问题时，将问题分解为若干个相互独立且完全穷尽的子问题，从而实现对问题的全面把握和深入解决。

在产品设计、产品迭代和产品问题分析等场景中，MECE原则的应用能够帮助我们更加系统地思考问题，避免遗漏和重复，提高工作效率。

二、产品实战案例一则

2023年在某次库存管理链路优化的迭代中，在ERP对商品入库节点增加了A信息校验，并且支持在特定情况下自动创建B数据信息，以确保库存数据的正常入库，使得业务不会因为库存数据入库失败导致的后续系统操作阻断。

基于团队集体共识，也就是大家的知识图谱最大边界，识别判断出来调用范围如下：a、b、c外部系统，系统内部1、2、3点，随即coding，test，preproduct，上线发布。结果第二天下午，突然接到服务台的反馈，全国零散出现书店门店库存查询故障，导致零售系统无法下单、盘点系统也无法正常使用。

上述是对零售现场的影响，最为直接。关联的还有周边多系统受到关联影响，比如订单中心。一时间无人能定位到原因，只能119式救急救火，结果反反复复，下午频现流量高峰。据说开发者当天晚上搞到10点多终于找到根因解决。

次日早上开发leader跑到工位和我摆根因，回忆说昨天是因为另外同事无意提到新门店开业的业务场景可能会有大量数据操作，随即展开了排查，果真是那个场景导致。而关联的就是前面上线的功能，原来在根因的业务场景中也使用到了新功能的数据逻辑判断，而那里的查询逻辑导致巨量数据查询，直接造成流量高峰，数据拥堵，几近拉跨库存中心数据库。

这一问题的出现，让团队也意识到在产品设计过程中，对问题的分析还不够深入，未能充分考虑到所有可能的场景，也让我们更加深刻地认识到MECE原则在产品设计中的重要性。

三、消防事件后，从个人角度总结几点：

如何有效规避由于信息不对称导致的质量问题？

1. 【文档沉淀、知识管理很重要】
   根因业务场景存在对于**信息的查询调用，这个是在目之所及的文档上没有任何痕迹的，团队知识图谱里面、以我当时在团队2年多的时长，竟然无人提及过的。知识丢失，导致前期范围识别的缺失；
2. 【摸底排查必须有】
   产品设计过程、coding过程中，测试用例设计过程中，也许就是个不能再普通的ctrl+f，但它的意义和战略地位却是非常有必要的。大胆的使用计算机的能力进行逻辑点自查，辅助产品、开发者、测试者信息的获取和识别；
3. 【feature生命周期管理】
   总有一些feature具有自己历史约束条件下的使命，完成使命之后，就毫无意义。产品经理也好、开发者也好，对自己的产品规划、代码规划，都需要做好必要的生命周期管理，描述清楚产生的环境约束是什么？当下承担的使命是什么？演进和消亡的条件又是什么？过渡承接取而代之的又是什么？
4. 【把MECE带到思考的方式里】
   完全独立，互不相关，多么美妙的划分啊！这座灯塔的指引下，构建自己的信息框架、思维框架，支撑具象的产品和feature以及日常的功能优化。虽然很难，但这也是指导的原则，将意识贯穿到团队成员的思维和日常工作才是可以落地的抓手，最终为改善和保障质量服务。

回头发现，上述几点竟然都不约而同的符合MECE原则（见本文第一部分内容释义），对于一个产品经理来说，应用得当，也将会大大支撑其以下能力属性值的提升：问题分析与解决、需求分析与挖掘、团队协作与沟通。

四、总结与展望

通过这次实战案例的反思与总结，深刻体会到MECE原则在产品设计、产品迭代和产品问题分析等环节中的重要作用。作为一名产品经理（其实是任何职场同胞们），希望将MECE原则融入日常工作中，不断提升自己的思考能力和解决问题的能力，努力让世界变得更加美好！

流程设计可以代替产品设计吗？当然不可以！

为什么有了流程设计，就能直入产品实现主题了？大逆不道啊！

作为内部定义的高P、高PM，根据流程设计草案，就直接给业务部门讲数据表，给业务部门直接讲按钮交互…讲数据变动的系统逻辑…😯如果你是业务人员，是不是也要醉了…

业务听的、看的懵逼一头，心里os大概率是：能不能说人话？！

不事先锚定业务的核心诉求和目标，结果上来一通实现描绘：数据实现、功能实现、系统逻辑，谁不懵逼啊，换做自己是用户代表，就不信你的心不慌。就想问，“这一堆东西怎么和我的实际工作产生了联系，任督二脉何在？如何就打通了呢？”

以上这种场景，引发我们思考，有流程小组的团队协作中，产品方案沟通、设计到底应该如何开展？

【产品方案沟通的路径是需要规划的】：

a·用户想要，当然也需要先明确表达自己，发出自己的声音，并且希望被听到、关注到

b·用户想要确认自己的表达被理解，渴望对齐信息背景

c·P们需要抽象提炼核心诉求和场景进行确认

流程设计是基于业务价值流的考量，进行的主要业务价值链构建。产品设计当然不能直接基于流程设计，产品建构需要从业务中/市场中找到业务模型或者叫做交易模型，同时也需要从“用户”群体中挖掘出来用户模型。这时候你发现，流程设计在哪里？其实是交易模型中的一部分。

这件事回到正轨，用户是先有了期望后产生于需求，表现为用户的诉求/实现YY。哪里是上来有了流程设计，就单相思的认为我们非常清楚。用户的诉求和实现yy，哪里是产品需求啊。

用户可以表达，但别参与设计，因为通常的用户都是一个个的个体，个体根本不是我们的用户，如果要做用户角色，那一定不是某一个人。除非我们绝对为一个人做产品实现。

再说一遍：

一个人 ≠ 用户

流程设计 ≠ 产品设计原则

产品经理在实战中想必遇到过类似情景：
a、面临某个问题，想到了彻底的解决方案，于是上路启程，但是途中可能由于碰到原来并未识别到的外界约束或者边界，而无法继续前进。诸如：目前的技术实力不足以支持、外部新出台政策限制、配套强关联的支持部门/系统存在致命短板无法匹配；

b、清晰的识别到了当下的约束条件和背景，知道前进路径的踩点在哪里，也看到了未来的应有的路径是什么（可能是推翻原有的踩点重建，也可能是基于原来的踩点进行大保健）
总之上面情形下，都不得不面临“仰望星空，关注脚下”的现实，说到底就是我们生存的世界无时无刻不面临着当时环境和时间下的约束与边界。

可通常工作中产品面临快速的迭代演进，当初的踩点、路径，为什么如此建立？当初的约束条件和背景信息，却很难得到有效的保留，更别说指望团队的成员都可以记住这个事情。

随着市场、业务、产品、技术、时间的推进，外界约束条件不断发生变化，或是国家政策、市场风向、业务模式、新技术、新要素等。

没有一蹴而就的产品，更没有一蹴而就的用户价值满足。妥协的方案一定意味着用户价值的打折，即便用户的直观体验并未影响，但也可能由于曲折的将就方案导致其他维护成本、研发成本的增加，间接来说也是在伤害用户体验，因为你丧失或者说延误了本可以创造更多用户价值的机会成本或者时间窗口。

研发资源在大部分团队通常都是有限的，奢求无限资源无限开火权无疑痴人说梦。如何使用的更加高效、更加具备长期价值，如果指望甩给PMO单靠项目经理根本不可能完成，更多的也需要产品经理、研发负责人、技术负责人共同进行思考规划。

保持关注，时刻审视每个点在当下约束条件和边界中，是否已经不合时宜？是否可以更上一层楼？这要求产品经理对于产品时刻要保有初心和小白的审视，而不是懒惰的认为，曾经的路就是不变的基石，特别是在互联网软件产品行业中。快速的迭代，难免会让团队成员忽略回头看，甚至记忆中模糊掉了来时的路。

成长都是血泪的教训，失败给我们不断反思和成长（想一想优秀是不是需要真金白银的支撑，给你磨刀练级）。记得2022年初为了解决当时业务上供应商退货批次准确性的问题而提出的设计方案，在研发途中识别出来在概念、方案设计、测试用例评审基本都没有发现出来的问题。

索性没有上线，好在当时也不是研发资源吃紧的阶段，等可行的步骤全部进行完之后及时止损，也算是为以后重启这项工作做了技术性的探索和铺垫。

后来随着业务发展，产品架构不断演进，到达2023年末该问题直接所属系统的周边系统产品不断迭代，功能一步一步往前走。再回头看当时无解的问题，已经变得可解了。这就是我们所说的随着时间变化，外界约束和边界的变化。

很容易想到，站在未来的某一天，重新了解到曾经这个无解问题的人，大概率会狂傲的一句：sb，这么显而易见的问题都不能搞定？

我们都曾这样看待世界，看待我们不了解的事情，站在无知的愚昧山峰，审视众生而以为自己看透了人间。

常见的迭代结束后甚至于迭代内容处于验收末期时，开发资源就会被快速的被项目撤走。从项目的角度来说，加快资源日历的流转，看起来是可以提高“研发效率”的。简单的理解思路就是，快马加鞭，削短空闲时间。以为只要自己奔跑，就能超过时间。

部分研发人员，也会迫不及待的想进入下一个迭代的冲刺。对于这样的研发表示情感不得不鼓励，但并不赞赏。他们迫切的coding结束，提测，等待测试来发现未尽的细节。

如果是以上的情况，那么事实的通常会是，资源被快速抽离进入下一个迭代的进程之后，逐渐暴露出来：提测质量不佳、实现点缺失、关联系统影响改动遗漏、验收时间被拖延。表面看起来开发端在赶紧时间交付代码，但是如果质量不佳，不好的影响非常大：

1、新的迭代起了头，不得不被搁置。需要一气呵成的代码逻辑，被不断打断之后难免出现纰漏
2、开发自身的情绪和信心波动，由于没有完整的自测和深入的代码完毕后的复盘，面对排山倒海的缺陷甚至都怀疑人生了
3、测试、产品、开发沟通成本剧增，由于编码前的一些必要信息对齐缺失，暴露在测试阶段将会大幅度提升沟通成本，关于功能、实现逻辑等
4、产品正常的节奏、测试的节奏收到不可控的影响，引发各个环节的时间被强制挤压，整体质量下降
5、验收交付之后，由于资源早已投入下一个迭代，对于线上的质量问题，还要协调开发资源而不得不打算正在进行的开发工作
以上这些如果在项目资源规划层面没有正确的识别和评估，导致的结果必然是：研发节奏紊乱、团队信心波动，甚至于团队内部冲突。并且出现迭代总是不能如期保质保量交付，用户体验受挫。

通常能够做到对迭代正确的评估、认识、管理推进，已经是非常不错的了，这中间需要项目、产品、研发、技术的高度一致和碰撞，信息的不断对齐。同时充分相信团队成员，给予团队负责范围内的自主权利。一群人，最可怕的就是一条心搞一件事了。能做到以上，我认为就是一个好的项目管理者了，现实中能达到御己御人地步的可能也寥寥无几。更别提发布后的快速响应阶段，快速响应阶段应该成为一种常态，纳入到项目管理的资源规划范畴。

——————————
实例一则：
紧张的时间规划，版本上线后，产品、开发迅速抽离进入下一阶段的紧张验收和问题处理阶段后。上线项目，导致资源匮乏，缺乏跟进，最优势的资源被撤离后，暴露出来的是连贯性上的迅速脱节。毫无抗风险能力、容错空间，承担的后果就是不得不陷入低效冗杂的沟通、调整、修复过程，最终让整体的效果大打折扣，业务因此也会受到影响。

常见的搜索引擎的交互窗口时一个输入框，可以搜索文本、视频、图片、网站、音乐等等。
通常也会有一个分类导航：图片、地图、音乐、视频etc
足够简单的背后代表着足够复杂的逻辑。

不让用户走回头路，及时的发现错误并提示，同时也尽可能减少错误发生的可能。有些意识是用户的潜意识认知，也就是常识范围，我们认为的常识通常不一定会表达出来。
比如：我对一个同事说等你空了我找你核对一个需求；背后大概率对应的是工作时间范围内、工作场合内。不可能是晚上、咖啡馆。这是一种角色框架层的共识信息。

如果产品没有及时识别到共识信息，或者没有再正确的逻辑节点去识别，会造成最终用户体验的逻辑混乱。比如一个交互流程，最开始就应该定义正确的信息，放在最后提交做判断提示。就会让用户非常的不爽，甚至于愤怒，特别是这个共识信息如果是过程的依赖的话，相当于用户要推到重建自己的交易行为。那么这次交易就是失败的，如果是一个开放的场景，我们就失去了这个用户。就算是一个封闭的使用环境，我们也失去了用户对于产品的好感。

为自己的用户考虑，为每一个交易价值的实现和顺畅考虑，可见很重要。

交互即交易！！！#潜意识##ispiik小站#

范围即标的，是一个迭代冲刺的目标。围绕冲刺目标，通常会有匹配的：时间窗口、前后端开发资源、测试资源、运维资源、业务资源，同时会有匹配的协同系统协同处理方案、应急处理方案。当然，背后依赖的还有整个产品roadmap，再往底层其实是商业和战略规划。

 

范围的控制不论从风险、时间、团队信心哪个角度来说都是很有必要的事情（这里不谈绝对，比如突发的bug，不修复就要挂了，那没的说绝对是重要且紧急且马上就得做）。

1、风险控制：一个想要插队的需求，如果要做，不仅是开发、测试资源日历的问题。同时需要评估和既有范围的耦合度，其本身的相关方系统、业务有哪些，明确出来需求的地图边界在哪里。前面是进行风险的识别、评估，同时必须准备风险的应对措施，如果因为插队需求问题导致的诸如需要紧急

修复、回滚等，对原迭代范围的应急方案是什么？最坏的结果，如果发生了之后，还需要去做的就是持续的关注监控，避免次生的业务和系统问题发生，比如：系统和业务不一致导致的无效数据。关于风险，因为团队内分工的不同，会存在不同岗位角色的信息差，这里最好要有开发、测试、产品、项目、业务协同进行上述风险的预判过程；

2、时间：世上不如意之事十之八九，项目管理、产品迭代又何尝不是如此。人员请假、线上问题、bug暴露、老板需求都会挤压既定的时间规划。尽管我们在做迭代评审后，项目成员都会自己评估绝对的工作量，标记自己的deadline。尽管每个人都或多或少预留了一些buff，但是通常结果是，开发的交付、测试交付基本都会达到整个范围的deadline。不能说是团队成员效率问题，或许是deadline的标的成为了大家心理的一种暗示。所以范围蔓延通常意味着时间的不可控概率大幅度上涨。

3、团队信心：一次冲刺对于每个成员来说都是整装待发重新出发的一段旅程。大家有清晰的里程碑、有清晰的目标，过程中不断的持续交付并按照节点推进，最终达成一次交付。这感觉一定程度是可以刺激人的慢性多巴胺的，让成员充满信心、并拥有成就感和责任感；无控制的范围蔓延，会打乱成员的节奏，引起团队信心的打击，团队信心就像nba2k里球员的自信值，对于投篮命中率具有牛皮的加成效果。

每个产品经理成长过程中一定遇到过，加法的过程，我们想把一些小不点搭顺风车。不乏遇到由于评估偏差导致连累正常的范围。搭顺风车其实是件小事，但是需要背后评估分析的却是一套严谨的方法体系。

2023年准备在暑假酷暑来临之前，赶着末班车出去旅行一趟。

当时翻了途牛网、携程网、美团、抖音，问了旅游百事通、携程门店、小红书。
路线从北京、山西、华东、西北、湖南、广西、川西，最后落到了彩云之南。
原本五一计划的路线，当时改道去了贵州。这次决定重回云南路线。

中间发生几件有意思的事情：
1、有限资源下人对损失的厌恶：
有限的资源，多种选择备选，正常人自然想去选择最优的额。不断的对比，我们期待着最优解，可是最优解找寻的过程，也在增加我们的资源投入，以及精神内耗。

2、找了旅游门店咨询跟团，发现什么是差距
以前做旅游总接触也听说的可能都是优秀的头部门店，门店从业门槛太低了点，但是旅游从业的存活门槛可是一点都不低。你可以轻松投入一两万开一家旅游门市，拿到资质、具备经营许可、接入行业资源体系，但是对接客户这一端才是真正的核心点。两家小区的门店，基本都是流水账似的浅浅的问了目的地、时间，然后就是各种广告行程甩过来。丝毫体现不出来咨询的价值，以后的旅游门店终端其实是咨询服务终端。这点跟做产品好像啊，你的顾客或者用户给出来的只有他的问题和期望，但是真实的需求和方案是需要进行挖掘分析、路径规划和设计的。

所以我们咨询了川西、新疆、北京，而最终选择了自由行去了大理。我们自己选择的过程，其实也是在找自己的解决方案的过程，因为存在信息差，所以方案才娓娓道来。

3、表观感受原来真的很骗眼球
对于不是很熟悉的游客来说，真的会关心比对到2张旅游宣传图片上面景点的数量多少，有没有、谁多谁少，可这不也正是信息差导致的嘛。没有判断的基准，人就回归到了数量的维度，将不同深度、体验、性质的point拉到一个维度本就毫无意义。这种信息差在你体验之后也是必然会消除的，落差也就注定。

一个好的旅游咨询服务，我想需要获得的信息：
1、用户出行的时间、出行动机/目的、出行的人员组成关系、预算的弹性
2、用户当前的生活工作状态
3、用户的过往旅行经历、偏好、禁忌

需要分析挖掘、引导、推进的是：
1、用户出行的核心诉求：亲密关系升级、家庭关系融合、友情维护、心灵治愈等
2、引导用户确认内心的真实诉求
3、搞清楚用户的期望只是用户基于自己信息认知范围得到的对于自己问题的解法
4、对于用户的真实诉求设计解决方案（和通常的产品找需求简直是完全相反的路径，即便最终你有现成的产品正中客户真实需求，如果路径搞反了也不一定匹配的上）
5、辅助销售的技巧、利用买家通常的从众心理、损失厌恶等心理，完成成交

我们通常听说的故事是人的诚实与善良，诚实不一定表示善良。

诚实是客观存在的，我们看到是这样，其他人看到也是这样，是无差别的。善良不等于不诚实，也不等于诚实，善良是主观的，我们体现出对客体需求、客体感受的理解和共情。基于客体的诉求和情感，进行了相应的信息传递。

产品中竟然也存在类似的体验，我们希望用户不要犯错，却没有提供不去犯错的良好的支撑，而是用僵硬的变形的判断校验进行阻断，就会给人这个诚实的傻子的感觉。

举一例：用户填写一个表单，第一步是一些基础信息，用来定义填写对象和时间；第二步的详情信息中会有依赖第一步填写对象信息值的查询。所以就对第一步填写对象值的强依赖，这个对象值有两种做法，一是让用户自己选择（可选范围是用户有权限的该类型list，很有限，几乎不超过2个）；另一种做法是从用户的登录信息中默认带过来，但是用户登录信息中包含的这类对象值是有不同类型的，这就存在带过来类型不对的问题。

最初的设计会希望用户单独选择，因为这个功能的使用是低频的、同时给出默认值也起不到决定性的效率改善。反而可能带错类型、以及让用户无法感知到，选择的填写对象会和详细信息有关联关系。

曾经我们接收使用方的瞎掰去做了默认带出，这真的是草包行径。

你想让我们诚实，但是我们更想去做善良的事情！
（这样的思考不止是一个简单的设计，更是对人性的探索，多打磨多实践）

在重庆待的这几年大大小小在外也吃过不少餐厅，有坡坡上的、路边的、商场的、写字楼里的。
用过的筷子也形形色色，黑色、白色、棕色、褐色、红色的，木制、竹制、不锈钢、塑料、骨瓷的，短的、长的、超长的，还有各种刻字的、镶嵌金属制品的、也许还有镶金镶玉的。

但唯有一家餐厅的筷子印象最深——南坪万达广场桃太郎寿司的筷子。特有的几个核心优点：
1、长度适中：比一次性筷子略长，又比家中常用的筷子略短，适中的长度在手里的感觉一点也不突兀。没有有些短筷子在手中看起来那种矮胖错的感觉，也没有那种长筷子在手中像撑杆跳一样的突兀；有点像一把小小的折扇在手中的惬意；
2、重量分配：是粗细渐变的造型，重心刚好保持在 捏筷子的几根手指附近，操作起来不至于很重也不会轻飘；
3、筷尖（此为最优）：桃太郎家的菜品又寿司、拉面、小吃、土豆泥、藻类、料理、生鱼片等，这个操作下来简直通用，很小的、很滑的、需要挑的、需要拨的、戳的、夹的、 捏的，都可以轻松操作。筷子头部较细，还有特殊处理的防滑纹理，并且筷子头部并没有因为粗细渐变的结构导致筷头分开太大，就连拉面里面的鹌鹑蛋都可以轻松驾驭 夹起来 戳起来都很好用。这个在有些餐厅饱受凄苦啊，筷子头分开的缝隙死活让你夹不到那些偏滑溜、偏小、偏细的食物。

还用过一些筷子，比重严重失调，每一次夹动都让我感觉像是在撬动巨大的杠杆，虽然你是杠杆但不要表现的这么明显吧。更别提有些轻飘飘的、或者重的都不像提起的筷子。能够理解桃太郎的筷子放在五星级酒店的饭桌倒也不太合适。不是一种风格、也不是同类的菜系。

总之就餐厅角度来言，这是我目前印象最深的筷子。甚至后来会因为这个体验，再去吃（当然前提是菜品也过得去）。