标签： 产品设计

作为产品经理，在日常工作中难免需要处理各种复杂问题，提升工作效率和质量。在这一过程中，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，这么显而易见的问题都不能搞定？

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

2023年还在上一个团队，当时有一个产品设计，大胆抄袭了企业微信，把它的日程待办搬了过来。

业务背景如下：

为了给采购人员提供工具支撑采购业务跟进，第一采购订单创建之后的审核、报出、确认，方便采购人员跟进自己负责订单的审核情况、报出情况、供应商回复确认情况，确保订单的有效及时报出。也清晰看到已经完成订单的占比情况；

第二是发货的跟进，关注迟迟待发货的订单、等待门店收货的发货单，可以及时催供应商发货、跟进门店收货，监控门店异常收货。

功能层面终于上了心心念念的日历看板，采购业务产品本身也有较强的时效性诉求，特别是如今零售流通行业对于供应链效率要求越来越高的时代。

曾经一度也在纠结满足这个业务诉求到底用一种什么呈现才好，那种带有巨强时间属性的产品（比如：机票、酒店这种严格分布在时间线上产品）放在日历的维度是天然成立的，因为用户有心理预期就是对于基于时间的需求（我要哪天住酒店，我要哪天飞，我要哪天出去旅游）。

而这次对于采购链路的跟单过程也采用日历看板模式，则是将原来的一维信息升维处理，需要用户大脑对于一维信息的处理过程，在经过简单的组装之后二维呈现在看板上，让用户获取信息时大脑减少思考过程，达到的结果就是让用户觉得自然的发生。用户的业务数据采集过程，完成了对于业务闭环的数据沉淀，然后自然的享受数据带来的价值，提升驾驭感，这个时候用户不再只是数据的投喂工角色、同时也是数据的驾驭者。

这次产品引用的主要是：日历看板+待办，日历看板由用户投喂的订单、发货数据编织而成，待办由系统自动策略+用户添加组成，提醒落位到不同的日历天，用户需要做的就是在平铺的时间线上进行常规的数据投喂，然后让一切自然发生，处理当天待办、识别分析异常、采取业务动作。

产品设计过程中思路、交互、甚至视觉方案借鉴参考有什么大碍呢？

当然，我们构建产品的过程并不能从它处作为起点，最多只是参考信息而已。自己产品的构建过程一定是从自己的业务、用户、商业目标中生长构建出来的，我们要满足的是自己用户的目标、业务目标、商业目标。

上述的方案其实只完成了第一步，即底层跟办的数据、逻辑模型搭建，最多算是到达了框架层而已，表现层的空间还有很大，产品也在持续的优化演进之中。

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

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

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

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

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

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

最近切换成全键盘输入法，据说可以锻炼双手防止老年痴呆，赶紧来试试。

猛的一下是真的不习惯，从 2006 年接触第一款手机就是九宫格啊。当年如日中天诺基亚值班机的按键是真的经典，记得第一天到大学宿舍，有个老乡那九宫格的手速简直起飞，还给我们演示在裤兜里面盲打，牛皮大王。

但是体验下来发现全键盘的容错性和精准性是真的调教的好，我用的是微信键盘，感觉已经做到了区域识别，你就在键盘上大概的字母位置点上去之后就可以出来精准的短词或者长句，联想修正能力优秀。

想起来也是挺逗的，当初 qwerty 键盘就是因为技术之初打字太快容易机械故障，所以调整的布局可以降低按键之间点击时间。后来这种按键方式逐渐成为用户共识得以保留。现在我们又要效率和准确，不变的布局在不同的时代焕发新生。

这不就是典型的老瓶装新酒嘛！产品设计里面的很多经典设计早已打穿用户心智，我们在需要做的创新，不一定是改变他们，而是更新他们的内核。

这里有2个维度可以解释这个现象，首先从用户体验设计的层次来看，我们保留经典的已经形成用户心智的表现层、框架层，而去更新迭代突破更往下的资源、能力、战略层的内容，由此可以让用户在熟悉的认知里面感受到强大的生机。

另外从用户体验价值来单看表现层、框架层，如果新价值-旧价值-用户切换成本，还不如旧价值也就确实没有必要，往往仅凭体验的表层实现用户迁移概率也是极低的。

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

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

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

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

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

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

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

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

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

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

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

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