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，哪里是产品需求啊。

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

再说一遍：

一个人 ≠ 用户

流程设计 ≠ 产品设计原则

业务建构–>流程建设–>产品建构–>数字化实现（技术建构、IT建构），业务飞轮转起来之后，业务动作产生数据，业务的现状和约束也决定产品形态，激进的产品策略无疑是对用户和市场的 YY，削足适履之举更是令人贻笑大方。

用户的自我成长，你们省省心吧！

用户首先不是人，而是不同场景下的效用组合，我在下雨天不想开车、不想乘坐公共交通时候，这时网约车产品大概率是我的最优选择。我在想吃辣的，但又不想吃火锅那么大阵仗的时候，我可能是火锅串串店的的用户。

用户是不能被教育的，用户是自己随着约束和环境自我成长的，而不是被产品和技术教育的，产品、技术、市场、营销、政策等都可能成为是用户的外界约束和条件。这些共同决定了用户的行为演进和选择的变化，也就是我们口中的“教育用户”、“用户成长”。

过往产品实战中，偶然接触到团队大数据部门的一次奇葩想法，为了某个数据产品呈现在屏幕上的结果更加规整、更加具备所谓的“可用性”（希望数据刻意的去符合常识，比如一个时间周期指标通常结果是在“天”维度，如果突然出现一个超过月的特征数据，就被认为数据不太可用、不符合常规），而反向希望业务去刻意规避某种业务行为。这是不是太滑稽了！拿着业务的果，去动业务的因。如果没有因，根本也就看不到所谓的果，又何来去对因的要求。

且不说上面这个低级的逻辑谬误。

再来说，对于数据我们到底想要什么？

答案绝对不是让数据隐藏、剔除、过滤掉不应该舍弃的信息，这部分信息当然要区分，不排除有些是噪音数据，但是另外还有很大一部分正是真正重要的数据——也就是风险数据、离散数据，这让积累的数据具备“业务系统”的遍历性。就像50年、100年一遇的大雨、大雪、大风，你一定不会认为这部分数据应该剔除掉。

上面这些数据是对真实业务的反应，我们绝不应该规避这些数据。这些业务行为过去既然会发生，哪怕概率很小、很偶然，也不等于未来不发生。抛弃这些，未来谈数据支撑无疑是盲人摸象。

你们又会说，数据可以驱动业务优化啊！

数据是以特定视角，呈现业务结果。结果相关的复杂的关联因素集合，再加上数据分析部门本位上不能替代业务视角看待问题，非业务部门也很难和业务部门做到风险共担，不是一条绳上的蚂蚱，难免意识和想法、行为的分道扬镳。

那些一句“我为业务好”的人，不过是一句口嗨。如果有一个团队对业务、数据、策略都负责，比如：全能运营战士，情况也许会好上许多。数据呈现结果，组织发现问题/改善点，业务部门最终自己驱动业务优化。

为了数据治理而治理业务？豆腐脑儿吧！

数据洁癖催生数据优化，数据优化反向治理业务。这是最大的笑话！所谓的数据治理、技术治理，自然是聚焦在为服务业务发展的前提下，而非为了数据治理而治理业务。没有业务发展，当然用不上数据、技术，除非数据、技术本身就是经营上的“业务产品”，比如当下很多的大模型产品。如果不是，那业务发展需要到技术，技术支撑业务发展，此时业务就像“大脑”，全身的骨骼、肌肉都是可以被调配、组合的硬件/技术资源。大脑自然会因其指令不能得到实现，而催生意识的变化和调整，继而产生匹配的行为。

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

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

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

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

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

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

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

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

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

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

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

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

⭐️西西弗三方仓储服务商集成项目
👨产品经理
🗓2024年2月-2024年4月
【项目介绍】:西西弗轻餐饮业务线由于原材料的特殊性，需要强依赖冷链运输、储存能力，同时经营需求较高的配送频率。因此欲集成外部成熟的服务商能力，满足当前阶段业务快速发展的诉求。
【项目业绩】:深度参与前期业务调研、外部服务商集成沟通，负责系统间集成方案设计，研发跟进、验收、交付培训。上线后有效提升了轻餐饮业务配送秩序。

⭐️西西弗电商平台集成项目
👨产品经理
🗓2023年9月-2023年10月
【项目介绍】:西西弗电商业务除了自研APP之外，还有丰富的三方电商平台，比如:抖音、小红书、天猫等，外部电商平台一直游离在团队的系统框架之外，无法进行有效的订单、平台库存管理、仓内发货管理，此次集成通过三方电商ERP完成订单的中中心化管理和对仓库下发，实现平台订单、发货的自动化。
【项目业绩】:负责自研ERP 、三方电商ERP、WMS外部电商平台集成方案设计，跟进研发、验收、交付培训。顺利支持了外部电商平台线上业务的自动化运转。

⭐️西西弗RFID集成项目
👨产品经理
🗓2023年8月-2023年9月
【项目介绍】:RFID项目是团队2023核心战略级项目，期望将市面上已经非常成熟的RFID技术应用到实际业务中，核心目的是想解决类别图书盘点的效率和准确率的问题，同时提升物流间调剂和配送门店到货清点效率问题。
【项目业绩】:全程深度参与业务前期的沟通、外部技术服务商的产品研究、内部多系统的对接讨论。负责核心ERP部分的对接方案落地设计、DWS规格采集系统的对接方案设计，以及后续的产品验收、交付培训。有效支撑了门店盘点效率的提升，提高了门店库存的准确率，为后续门店参与线上发货提供了基础。

⭐️西西弗外部供应商首次系统集成
👨产品经理
🗓2023年3月-2023年4月
【项目介绍】:西西弗虽然具备了完整的供应链系统,但是与上游供应商的数据对接仍然存在断点，订单的报出、确认、发货数据还在延续专统的邮件、IM形式,一旦遇到采购高峰，就会形成严重制约于报订效率。另外，采购在途的监控始终存在空白,此次集成项目是首次与外部供应商进行系统打通尝试，为未来开放外部供应商对接奠定基础。
【项目业绩】:全程负责与三方团队进行业务沟通、对接方案设计、研发测试跟进，集成验收，业务交付培训。顺利支持首家轻餐饮供应商的自动采购报订、订单确认回传、发货回传、退货数据下发。

⭐️西西弗供应商管理系统研发
👨产品经理
🗓2022年10月-2023年1月
【项目介绍】:西西弗二十多年发展历史，供应商和采购规模增长迅速，但供应商管理、采购管理，两 重点业务一直是线下较为粗放的人工管理。作为供应链管理中重要的起点，制约着整个业务链条的供应效率，无法将价值数据进行沉淀利用。本项目研发独立的供应商管理系统，通过组织、标准、流程、系统等各个维度的构建和优化，来提升公司整个供应链的效率，以达到降本增效创收的目的，未来甚至会考虑将供应链能力输出给整个行业，让整个行业更加有序、良性地发展。
【项目业绩】:联合流程团队深度参与前期业务调研、流程设计。主导产品全程方案设计、研发跟进，负责产品全线验收工作、业务培训，联合项目团队完成实施跟进。业务上打通了采购的全链路数据，从采购需求到申请、订单、发货、收货、退货，支撑业务的有序开展及供应链数据的分析。另外对于供应商档案、价格管理均实现数字化，并和采购订单有效互动。

⭐️西西弗轻餐饮效期管理
👨产品经理
🗓2022年8月-2022年10月
【项目介绍】:西西弗餐饮业务在系统数据层面一直缺乏效期管理，导致数据实物错位严重，影响业务管理和生产安全。此次改造涉及仓配入库、库内管理、仓间/店间留流转、仓内/店内盘点、零售出库等，旨在进行全链生产日期 有效期的监督管理。
【项目业绩】:完成仓储管理系统WMS的三方沟通、改造方案设计对接、功能验收;完成wms与ERP对接方案设计，研发跟进、验收，业务交付;有了效期的链路数据，给大数据团队的管理数据分析提供有力支撑。

⭐️西西弗电商仓发货系统升级
👨产品经理
🗓2022年6月-2022年7月
【项目介绍】:西西弗电商仓上线初期业务量较小，仅完成订单层面的数据通路，仓内作业模式保留原B端的业务逻辑，当时主要目的为验证线上业务流程。经半年运行后，业务增长，仓内作业效率收到制约，主要受制于配货、波次、打单、拣货/二次分拣、出库复核等环节。该项目全线梳理以上业务痛点，进行系统改造升级，打造纯C端仓储模式。
【项目业绩】:完成C端逻辑下的供应链相关系统(ERP、WMS、OMS)产品对接及升级方案设计，实现收货人信息、快递信息有效下发仓库，支持仓内进行波次拣货、分拣、快递面单打印、复核等业务环节。同时支持了多仓发货的业务模型。

⭐️西西弗中心退货仓系统集成
👨产品经理
🗓2021年12月-2022年4月
【项目介绍】:西西弗全国十大物流仓较为分散，分别承担退货周期长、成本高，对于供应商的结算影响较大。根据核心供应商的地域分布，选择其中一个仓集中承担退货功能，并上线自动化分拣线加快分拣退货效率。项目涉及到外部仓储管理wmIs系统、分拣设备Wcs系统、自研ERP系统的三方对接，以及硬件的生产调试及实施。
【项目业绩】:负责三方系统对接方案的梳理设计，通过和三方团队的密切沟通调研，主导产研团队建立完整的系统对接知识图谱，快速对齐项目、开发、测试的信息认知水平。如期在2022年4月完成系统集成，为硬件调试落地做好准备。

⭐️西西弗APP对接库存中心
👨产品经理
🗓2021年10月-2022年1月
【项目介绍】:西西弗APP原独立运行，并未打通内部订单系统、库存管理系统、ERP,以“订单”为核心对象，处于游离状态。无法高效串联企业的订单、库存管理、订单同步、仓储发等环节。此次目标在于全链条打通线上订单的下单库存锁定、订单确认库存扣减、库存处理同步、仓库发货、售后退货等核心场景。
【项目业绩】:负责B端相关产品方案的全案设计,WMS仓储管理系统、ERP系统、库存中心中台系统共3个系统的对接方案设计，其中仓储WMS作为三方外采系统，全程负责三方方案对齐/实现。在2022年1月初全部落地上线，并负责对业务的交付。顺利实现APP业务仓库系统直连发货。

⭐️西西弗书店ERP2.0
👨产品经理
🗓2021年8月-2021年10月
【项目介绍】:西西弗原ERP11.0版本只具备库存单据、任务流转等基础的能力，书店和咖啡馆的业务是完全割裂的两套系统在分开管理，很难支撑未来公司业务融合的大趋势，也无法支撑线上线下业务融合的公司级战略目标。因此对ERP本身能力的改造提升和扩展性的考虑
就成为本次项目的核心目标。
【项目业绩】:2个半月内负责完成产品方案设计、方案评审，协同进行技术评审，跟进开发、功能验收和业务交付培训。

⭐️懒龟生活优选
👨信息产品经理
🗓2020年3月-2020年5月
【项目介绍】：2020年疫情后于3月份团队启动生活电商项目，定位是本地生鲜电商平台。通过原有旅游行业同业渠道资源，加上有赞的零售分销平台，对于疫情初期人们基本生活物资难以顺畅购买的现状，从而快速切入日常生鲜消费的市场。
【项目业绩】:深度参与项目前期筹划，负责项目对应的信息系统选型(微商城/电商WMS)、产品细节摸底/采购/功能测试/流程梳理/系统配置/上线培训/需求优化对接，保证了项目的时间窗口需求(14天从立项到商城开张），为项目提供了可靠的数字化支撑;

⭐️钢铁匣
👨信息产品经理
🗓2018年10月-2020年10月
【项目介绍】:“美匣云”是一套集B2B同行分销平台B2C微商城系统、旅行社内部管理系统于一体的旅游Saas系统平台，全方位解决旅行社产品货源、直客销售、同业分销、内部管理等难题。
【项目业绩】:完成前期业务逻辑梳理、用户需求整理分析、部分原型设计、项目落地；联合乙方完成产品2.0到5.0的迭代，为乙方对旅游业建模提供了有力支撑；同时组织团队顺利完成旧系统向新系统的迁移工作(数据迁移、培训落地、需求实现等)。最终实现团队业务数据的沉淀以及颗粒度的降低，为未来的决策做支撑

⭐️小强ERP实施项目
👨项目负责人
🗓2016年6月-2017年10月
【项目介绍】:旅游团队传统办公模式，没有信息系统辅助，内部信息单元流通效率低，存在大量纸质文档，业务管理、协作效率面临巨大挑战，同时线下流程导致的损耗不断增加。小强ERP是专攻旅游批发商环节的信息化经营办公系统。该项目主要完成了系统和团队业务模型的匹配、上线部署、个性化优化、集团内部执行标准落地。
【项目业绩】:负责整个项目的前期系统调研、公司需求匹配对接、落地实施、需求管理和持续对接优化;建立了标准操作规范，且在成都/武汉/长沙/北京多公司协助落地执行及规范推行。最终实现向无纸化自动化的跃迁，提升经营效率的同时大大降低了业务损耗。