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原则融入日常工作中,不断提升自己的思考能力和解决问题的能力,努力让世界变得更加美好!

我的项目经验-2024版

⭐️西西弗三方仓储服务商集成项目
👨产品经理
🗓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是专攻旅游批发商环节的信息化经营办公系统。该项目主要完成了系统和团队业务模型的匹配、上线部署、个性化优化、集团内部执行标准落地。
【项目业绩】:负责整个项目的前期系统调研、公司需求匹配对接、落地实施、需求管理和持续对接优化;建立了标准操作规范,且在成都/武汉/长沙/北京多公司协助落地执行及规范推行。最终实现向无纸化自动化的跃迁,提升经营效率的同时大大降低了业务损耗。

外部协作项目的极限拉扯到底怎么样?

“上周肝考试,这周肝项目”——2023.9

一周肝了 3 个外部协同项目,A项目 涉及到 3 方三角拉扯,B、C 项目分别涉及一个外部相关方拉扯。先说结果:A项目顺利进入测试、B 项目达到上线准备、C 项目捞底明确了问题清单进入外部协作方处理阶段。

A 项目涉及 3 方最为复杂,任意2 方都有协同对接任务,作为业务方 除了主导自己成员和外部 1 、外部 2 的对接,关键还得全程操心外部 1、外部 2 他们之间的协调沟通。明确核心逻辑,甄别关键任务,这当然是作为“串串”角色必须具备和秉持的。焦躁的表象下无非是各个相关方的不确定。这个过程惊奇的发现,基本的关键信息串联、看前后文,原来也是稀缺的基本功🤫更别提目标驱动了。舍我其谁?每每遇到这种情况,就有“让我来”的冲动行为。

B 项目、C 项目作为单一外部协作方,自然简单不过,简单的做法就是完全确保给他们正确的指令执行就好,心情好一些的时候科普一下场景,时间闲的无聊也可以给他们指导建议。

回顾学生时代、职场的一些经历,经历外部协作绝不算少,或许是这些经历、或许是不愿牵强,遇到极限拉扯总想拨茧抽丝一探究竟,找到真相、穿越迷雾。

清楚记得当年初入职场第一个工作任务,嗯…对,就是“任务”,boss让我和一个办公室老师一起接待工程勘察队员(工程人估计要会心一笑),个个肚子跟怀孕似的,带着他们大夏天白天一起钻玉米地,晚上一起去洗浴中心 happy。作为业主方角色,后续经典的工程5方关系拉扯不断上演。

后端有一段短暂的经历是当年酒店线上大战时,携程、艺龙、去哪儿、美团,都在搞酒店,去哪儿势头资本市场势头正猛,城市BD的角色就是要独立完成客户拓展/拜访/签约/拍摄/产品包装上线/销售跟进/产品优化,那会儿已经是996,今天啥时候来、晚上啥时候走就欧啦。这当中最拉扯的当然是酒店旅馆小老板儿,房价要拉扯、房型要拉扯、能不能多给签几种销售方式也要拉扯,最高兴的是第一次陌拜就签了一家满贯合作的酒店。

第二段时间较长职场经历中,用一张脑图协调过全公司近100人参与筹备举办产品发布会(参会规模在近千人);一个人3个月跑4个城市驱动集团5家分子公司对标ERP实施规范;为了做细颗粒数据支撑管理和业务升维,联合筹备外部研发系统,内部和财务销售产品各部门拉扯,外部和乙方公司的产品研发测试甚至boss拉扯;这都还不算当时负责范围的各种外部厂商拉扯的(硬件的、软件的、服务的)…

大学也协调过全班几十个人,从学校骑车一路狂飙几十里到黄河边野外烧烤,炭——校门口烧烤摊让人老板帮订的、锅——一东北大姐火锅店借的、碗筷——都自己家伙事儿、肉/菜/馍/饮/油/料/刷——拉几个同伙逛附近菜超买的、串串——分给男女生宿舍晚上自己洗菜切菜穿芊的、自行车——自己的/借的/一拖一的/租的、灶台——黄河边石头摆的。狂奔几十公里,导航也没有,逢人就问路,可就是开心啊!四月春风草长、红花绿柳,一群傻二青年欢快的摆灶、生火、烤制、碰杯、爬树,比拼烤技、互相换吃,悬河边跑着打闹…

很多时候,我们经历了到了更远的地方,便也不会再纠结脚下的路。

对于极限拉扯无非几个关键点:

1、搞清楚自己的目标、大家的目标是什么,是不是一致的

2、搞清楚每个参与方的驱动来自于什么

3、识别关键路径、把握核心信息链路、用好关键人

4、进程中甄别关键任务、挖掘关键信息

5、带领/影响成员,穿越风险迷雾区,实现目标

聊聊产品迭代范围的管理

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

 

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

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

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


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


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

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

iSpiik快记131:数字驱动下,不可或缺的内心驱动

数字化的进程提供了各式各样的产品,2b 2c 2g… 为组织数字化提供了有力支撑,这也促进了组织内部SMART原则下的目标拆解落地:具体的、可衡量、可实现、现实的、有时限。很少再见到:工作态度良好5分、优秀10分这种了,一个人一个岗位被抽象为一串串可以代表的数字

“你再怎么可观地设计绩效体系,这个体系都无法真正地与你追求的目标画上等号,在这种情况下绩效体系越量化,越容易将团队成员带入追求绩效的数字游戏上,而忽视了真正的目标”

字节据说采用的OKR,所有人都可以看到leader的下个月下个季度的重点是什么,然后每个人都可以为此对标行为是不是可以帮助实现团队目标,你甚至可以看到张一鸣接下来的主要任务,大家想办法去靠近。另外,飞书在内部作用可见一斑。

这样看来,每个组织都是有一个叫做“团队/公司”的产品,做出来产品,给社会输出价值,也获取交换的价值。

iSpiik快记130:组织知识管理

接着之前的会议OKris_3zzz再挖挖,很多人都痛恨传统的、低效的、不靠谱的会议,我叫它为“断点会议”,事前事中事后不连贯。

一个靠谱的会议,事前应有所准备:物料、方案、人员、时间、地点、初步check等;事中有内容的输出和协作沉淀;事后有任务和知识转化;

从数字化角度看(参考图片)以#钉钉#  之类协同OA为例,依托组织在线可以把会议的事前触达(即时通讯及日程)、事中内容协作/沉淀(智能文档)、事后知识转化(云课堂)、任务协同(群任务看板或三方协同看板)全部在线完成;

同时转化的知识可以形成组织智慧,沉淀到#云课堂#  ,流转进入到培训模块,参与到学习路径地图中。【再结合之前关于学习路径的分享OKris_3zzz快哉】

iSpiik快记129:路标的过程管理

接着这条路标及分解说OKris_3zzz

产品路标规划,跟咱里程碑说的本质差不多。

这个应用有很多变种,比如在薪酬体系中:路标设置有年度目标、季度目标、月度目标,年度目标是一个核算周期,这个周期内拆解为季度、月度目标,为了结果达成设置过程把控节点,过程的节点落地到基层KPI,过程锚点设置激励机制,过程中可能有起有落,但是核算周期没有结束之前都保持有搬回全局的可能性,这样就让team可以保持冲刺的姿态尽可能触达周期标的,不至于中途放弃,同时提供了中途回顾及修正的检查点。

产品实现/运营过程,其实一样可以参考上面思路,按照路径把握合适的划分粒度之后,形成延续的脉冲式前进。#ispiik小站#

iSpiik快记124:做一个feature前的思考

纯银V微博分享过关于做一个feature前的思考:
“比如说,我们做一个 feature 之前,先搞清楚三件事:
1、目的到底是什么?抠细一点,再细一点
2、有那些统计数据可以证明这个目的?
3、发版之后,你的数据预期是什么?
把这三点搞明白之后,这个 feature 的优先级,值得投入的研发成本,经常自然而然就浮出水面了。如果预判过于乐观,最后达不到数据预期怎么办?你需要公开复盘,总结经验,修正下一次的数据预期。”

此3条可以是对我们在哪儿、我们去哪儿的清晰的定位,然后feature就是我们怎么去?当然涵盖了想清楚、做不做、做多少、怎么做。

标的建立精准坐标、为什么要去那里、如何衡量完成度,原则其实就是具体的、可实现、相关、可衡量、有时间周期的SMART原则,至少得是个逻辑自洽的闭环。

iSpiik快记123:图片这套做产品怎么样?

(外部因素+内部因素)*使命愿景,确定出来标的(产品概念图);

接着是产品路径规划(产品路径地图),组队,目标分解,过程把控(这里可能是N个小螺旋);

创造用户价值(群众是产品的用户、员工是组织的用户)、产品价值、商业价值。 ​​​​