MECE:产品经理的高效思维利器

作为产品经理,在日常工作中难免需要处理各种复杂问题,提升工作效率和质量。在这一过程中,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原则融入日常工作中,不断提升自己的思考能力和解决问题的能力,努力让世界变得更加美好!

取乱之道!数据要好看,所以业务要改变?

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

用户的自我成长,你们省省心吧!

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

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

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

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

再来说,对于数据我们到底想要什么?

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

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

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

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

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

为了数据治理而治理业务?豆腐脑儿吧!

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

iSpiik产品说:外界约束与边界变化驱动的产品设计

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


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

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

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

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

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

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

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

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


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

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

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