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,这么显而易见的问题都不能搞定?

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

iSpiik快记:红衣大叔周鸿祎还在用三级火箭

前段时间360老总周鸿祎,一直在跟哪吒拿流量,还拉负责人张勇讨论哪吒汽车要不要改名。其实细想一想,还是红衣大叔自己走的几步棋,跟他当年360发家时候使用的三级火箭战略还是几乎一模一样。

第一步其实是周鸿祎用自己日常话题和视频曝光,但是流量可能没有那么大,并不能引爆,所以就用了拍买迈巴赫这个事件,拥抱新能源这个话题,一举打开了流量突破口。这样子就可以顺理成章的往哪吒新能源这方面去引导话题和流量。

30万的迈巴赫硬是被二手车商天安储会长给拍到990万,参与竞拍的二手车商肯定是基于周能带来的流量和赋能 以及打破的关系圈,对于周来说,肯定是希望给此事点燃自己的个人IP,从拍卖迈巴赫,到360大楼下面排满了新能源送来的展车,堪称小型汽车展览。再到车展上面的出格的老周男车模。种种举动都表明,周希望在此时此刻,打出自己的个人IP,也有可能是受雷军的影响,毕竟雷军在抖音破了2000万粉丝,并且小米su7今年借助短视频平台进行了巨大的流量收割。

而周自己本人,不管是自己相关产品,还是他投资的哪吒汽车来说,能够从互联网短视频平台进行流量的收割,都是一件值得去做的事情,并且面对汽车最近几年新势力汽车品牌不断崛起,更加激烈竞争的一个现状,不得不强势的快速在消费者心目中树立起来自己的名号。

第2点就是流量来了之后 自己要能接得住,也就是当年周三级火箭战略中第二级——平台,就是承接用户的地方,能够让用户在这里活跃生存下来。那我想对哪吒汽车来讲,就是必须要有拿的出手的产品,有产品力的产品,让用户真真正正感受到哪吒用心做产品,为用户着想。而对于短视频平台的单位来讲,就是要有优质的内容以及话题、活动产出,能够持续让流量的注意力集中在这里。用用户模型里面来讲,就是让羊在这里有草吃,能够活下来。

第三步,其实就是要盈利了,羊毛迟早是要割的。这个羊要不然直接剪羊毛,要不然就是要把这群羊给其他觊觎者来收费。

无论怎么讲,在如今大家注意力、国民注意力时间越来越分散的今天,所有人都想要抢占有限的国民时间。优势的品牌、有竞争力的产品,更应该去做这件事情。因为我们明明知道流量会因为算法的操控而被拦截、稀释掉,也许有竞争力的产品、好的内容也不一定能够接触到真正有需要的用户,酒香也怕巷子深。这个时候选择勇敢的站出来拿流量,也可算是明智之举。

其实玩流量这件事情,10多年前360杀毒已经玩的明明白白了。当年3Q大战,360杀毒软件和腾讯之间,想必有经历的同学一定知道,我们的Windows电脑右下角不断的弹框,要不然让你卸载QQ,要不然就必须卸载360,双方就不断给你弹窗,总之就是二选一,整个宿舍、楼道里里大家都觉得有俩愣头一样的二逼在网上撕逼打架。后来360用免费杀毒,还是一举打开了突破口,成功占住了互联网市场一席之地,并最终走到敲钟上市的那一刻。如今也成为国家安全相关的支持单位。免费杀毒就是360的第一级火箭。

企业放大来看,放到一个产业内,那么所有企业也是有等级的,它想要在这个产业等级内往上爬升,可能有时候需要一些看起来与大家共识的道德规范不太相符的,不道德的行为,来去达成自己攀升的目标。但攀升顶端之后,这些企业也极有可能又回想起来,去愿意做大众规范道德里所倾向的事情。这个现象在官僚体制内其实非常常见,今天突然想到,就是放在产业不同企业等级里面,似乎也有这种隐隐约约的现象。

2024再仰望,未来旅游!

惊蛰至,万物生

2024年3月,惊蛰,万物生。前团队一号位D哥突然电话联系,怎么就这么巧!?

想再次合作搞旅游,把他目前团队做的事情在信息化、产品化的支撑上更进一步。我说自己也计划将要进入新的阶段。

他说,要不,咱们“在一起”试试?

我说,要不,咱们找个时间,聊一聊?

且不论现在团队业务搞成什么样子,就单讲2020年一别,转眼三年又半载,老友联系相当兴奋。当时团队还是留下了浓墨重彩的一笔,不论是在自己的履历中、还是当时的工作中。在重庆这个座城市,D哥一定要认。

整装再出发,剑指未来

3.7,恰逢女神节,给前同事们提前点了奶茶,随后开车半小时杀到前团队楼下,跑上去纷纷收到大家的热情欢迎,一切都还是那么熟悉,哦…原谅我说的只是“声音”。终究多数人还是没有跑赢岁月,不是体积变化了,就是颜色变化了,或者状态变化了。少有的一两个同事保持着良好的状态和身材。

意料之中,前团队业务在基本盘之上,开始拓展线上流量,大交通毕竟是有限资源,吃票子的稳健根基,也有线下存在的庞大传统旅游门店网络支撑。线上需要打破地域限制,拓展无限流量资源,成本规模可控的前提下,不断提高边际收益,做信息分发节点,目标打在更广阔无垠的目的地资源上。抛开交通、酒店的数量边界之外,攻略服务、跟玩儿这都是无限市场啊。

2020年离开前团队,当时我就改口“旅游服务商”,信息分发的模型昭然可见啊兄弟们!(参考我首发在人人都是产品经理网站的文章《2020年后的未来旅游服务商,路在何方?》,点击阅读查看)

信息时代的旅游平台运营商

新的阶段前团队正经百八的开始线上了,运营、抖音主播、线上产品、客服,直播间搭建,都搞起来了。这里浅聊一下自己对线上旅游的认知看法:

1、传统OTA平台:携程、途牛、同程、飞猪,他们是有细分的

·【携程】:基于优势机票酒店基本盘,已经对于目的地的资源的深耕。机票酒店对于商旅属性客群、以及20年来沉淀客户群的口碑传播,自然不会差到哪里(相对成熟、理性、职场、商务是画像特点)。这些人群还有个共性就是,规律性或者叫做程式化特征、相对低敏。站在资源的出发港口里,携程绝对吃的饱饱的,要不James哪来那么多精力天天研究人口学,还全面推行弹性工作制呢。攻略,一直是携程的弱势,度假产品算是携程的二环产品而已,碎片化的资源支撑携程可以组装出来不错的轻松及格的产品,但它们本质我认为还是标品的操作逻辑。

代理模式,是旅游度假的丰富度补充,这要说到携程还有线下的布局,携程门店、去哪儿门店、旅游百事通门店牢牢的把握了很大比重的线下市场,旅游需求的多样性、差异性,反向促使供应商端的丰富性发展。机酒等标品形成了飞轮效应(成熟操盘模式),边际收益极高,当时旅游度假产品的成交天然的长决策周期,需要高密度的投入。机酒为代表的是成本边界有限,收益规模大;度假代表的就是收益想高、投入就需要跟着很高,这件事情自己做很累,那不如拉行业共建,分享自己的流量和品牌优势,大家在携程的土壤上共同生长。

·【途牛】:单资源上还是弱一些,主打的就是对于度假产品的切入。一家大型线上旅行社+线下服务中心,拉着传统旅游供应商一起玩。自己也不断直接弯腰下水一线旅游业务,过了当年上市之后的强势爆发阶段之后,疫情这几年是连连萎缩,不少城市站点、连锁门店都在收缩,跟着一起收缩的还有它的股价。

2014年5月纳斯达克上市,当时前团队做旅游电商算是吃了一波途牛的资本红利,没少在途牛平台成交订单。典型的印象就是当时途牛的城市站点团队强大、门店也多、广告打的猛、营销费用也肯出,和供应商一起补贴打市场。可是后来就不说了,你看这捉急的股价,一路降到1美元,徘徊在退市的边缘。国内游利润空间不断被挤压、出境游市场疫情之后就没有稳定过,对于一家上市跟团游为主要基因的公司来说,确实挺难的。没有了线下的高覆盖,线上流量成本越来越高(在2015年左右就听说线上获客成本已经在100+人民币了),如今的途牛如果再不来一些强针剂,未来令人担忧。

·【同程】:背后毕竟有腾讯,20%股份的股东不能只是拿分红啊,流量必须给。到位。国民应用微信在我的-服务中,直接开了2个入口给到同程(虽然是三级入口),“火车票机票”、“酒店”,稳定的的流量,助力其市场下沉拓展,据说新增注册和付费用户非一线城市贡献颇丰。

看一下你的微信里面这两个入口,其实都是同程旅行,更狗的事情是,其实两个入口联接的居然是同一个小程序的首页,只是默认了不同的选中导航而已(这你受得了吗?可是对于大多用户来说,这就是巨大的成本啊,你让用户点进去首页自己切换到酒店,就这一个动作就要产生n多思考和流失)。放到微信这里,就是要切开2个独立入口,这都是妥妥的精准流量,加上微信长期的背书,很多用户都默认微信里面提供的服务都是经过严格筛选,是可信的。能让用户放下防备去使用,这个本身也是微信长期克制的结果,不随意给用户垃圾功能的堆砌,而是根据用户的反应、需求,一点点的克制的释放能量。

吴志祥老师当年做导游、后来做旅游,从和携程艺龙的一元门票杀到现在,创始人基因对一家企业影响是真的大。还记得在2010年之后旅游公司都纷纷拿资本、纷纷IPO的阶段,同程在2015年的供应商大会上吴老板还说同程不着急上市,虽然拿了资本投资,但是同程还是有绝对的掌舵权,而彼时腾讯就已经往同程不断押注了,意图当然是布局旅游市场。直到2018年同程旅行才港股上市,股价走势算稳中有升。

2024年5月21日,同程旅行(0780.HK)发布2024年第一季度业绩报告。财报显示,2024年第一季度,公司实现收入38.66亿元,同比增长49.5%;经调整净利润5.58亿元,同比增长10.9%。截至2024年第一季度末,同程旅行年服务人次达18.27亿,同比增长57.4%;年付费用户达2.29亿,同比增长14.3%。用户规模和用户价值均实现大幅提升。  

财报数据显示,2024年第一季度,同程旅行的国际机票票量同比增长超过260%,国际酒店间夜量同比增长超150%。

2024年第一季度,同程旅行在强化核心OTA业务的同时,持续拓展酒店管理、旅游度假等业务领域。同程旅行表示,日趋多元的业务布局,为公司打开了新的可持续增长通道。其中,受益于广告和酒店管理等业务的规模化增长,同程旅行的其他收入板块(含广告、会员、酒店管理业务等)同比增长36%至5.02亿元。

2024年一季度的财报,更是印证了当下同程的高速增长的业务:机票、酒店,这里当然很多得益于腾讯巨大的流量灌入。如今时代可怕的不是你的东西还不够好,而是没有人看到、没有人经常来。刚需的产品+流量曝光,会带来用户黏性,黏性自然又会泛化场景,那么未来同程扩展拉动其他产品线也是水到渠成之事。另外不得不提,微信生态本身面对短视频赛道的冲击,视频内容方面也在发猛劲儿,这本身也是对同程旅行的利好。

2、抖音、微信视频号、快手、小红书,信息贩卖商的形形色色

·【抖音、快手】:作为短视频平台,用户接受着高密度信息的快节奏强刺激,这是用户的习惯,旅游类的短视频生存空间在于猎奇、实用攻略、个性记录,以此形成帐号的人设、红人效应,圈粉关注。

平台就像是一个闹市市集,每个人都可以摆出来自己的东西吆喝几嗓子,有能耐的就聚起来在这里闲逛的人,对!这个形态说的就是直播分支。细分到旅游场景,可以用经典用户画像区分,大明用户有清晰的需求,来这里精准的搜索攻略内容、查找商品/直播间获取价格比对;笨笨用户,需要科普/推荐型/内容帮助其找到正确的目的地和路径,内容承担松散的导购、直播间承担主要的导购角色,帮助笨笨用户——这一点也决定了【旅游直播间】重在导购啊,就是一个模拟线下体验的线上旅游顾问,进到一个直播间我们就像进到一个旅游顾问的对话中一样。小闲用户呢,主要是用来看能不能给他们种草了。

直播间可以成交、头部品牌背书帐号的橱窗可以成交。

商品形态的分裂变化:

扁平化、标品化趋势,科技时代的信息进程,都是朝着符合效率原则的方向开进。旅游的现实产品标品化(线上)仍然是主要趋势,而体验升级着重在于外化过程,在经历了种草、问题、搜集信息、咨询、预定之后,进入到体验环节是产品真正释放能量的节点,依赖到导游/向导/沉浸场景/信息渗透等产品的体验设计。

·【小红书】:美妆起家、穿搭起家,女性群体作为前期主要用户,场景不断泛化到生活、职场、旅游、养生、健身、摄影等等等等。用户群体,现在男性也不见得少啊,各种社会角色感觉都在加入。我职场的同事、城市的朋友、老家县城的堂弟,都在小红书。

跟抖音快手这种短视频强密度快节奏内容的平台来说,小红书相比在中老年用户群上稍微弱一些。

小红书的内容分布,绝逼是超小颗粒度的全领域内容,首页的双列图文信息流,各种领域内容的信息流算法组合。超大ugc的基础,造就了海量的小颗粒度内容碎片。

在我看来小红书的用户场景有:寻求经验、看看世界、分享记录。终究小红书是种草、拔草前的主要阵地(平台的用户心理假设,就是想看到有效的干货的亲身经历,对于广告味十足的 pugc、pgc,我自己反正是排斥的)。成交?大概率还是围绕红薯的人设转移到成交平台。用户是围绕红薯主这样鲜活而实际的个人而聚集的,而品牌在这里似乎显得有点格格不入。(果不其然,2024年3月中看到消息小红薯-微信的流量链路正在尝试,小红书到小程序,微信天然具备的订单、支付、客服能力。小红书在陌生人之间种草,进阶需求在熟人社交完成,内容的分享仍然可以在小红书进行)

·【微信视频号】:微信全生态植入啊!发现页面、朋友圈、好友分享、甚至微信键盘、微信搜索(微信页的主搜索入口、发现页搜一搜、对话框的长按文本搜一搜),总之视频号完全融入到微信的社交体系之内,如今官方舍得给流量,而它的传播模式初步看是可以朋友之间多度传播的。感兴趣的、热点、喜欢的,会围绕每个人为中心进行辐射传播,就像水面上扔下去一个个小石头泛起了涟漪,而你我的每一个喜欢就是扔下去的石头。这个算法模型2021年我就从抖音的视频推荐中有推测到在使用,这种传播模式更容易造成信息涡轮。想一想每次你关注的内容,结果周边的人都互相没有交集,这不就很无聊嘛。

随着对于ugc、pugc的不断加强,很多头部已经还是多平台发布内容了,你在抖音能看到你粉的内容,视频号后面大概率也能看到。况且抖音杀的这么痛,腰部帐号大概率是要拓展视频号的,而头部 你懂的,看见肉还有不吃的吗?互联网玩儿的就是无界限,边际收益啊!视频号的内容生态一定也是越来越强大,聊天、刷视频都在一个app想一下也是不错的。为什么还要再装一个其他app呢?

【微信生态对于旅游场景,我想到几个可能的用户心理路径】

1️⃣先种草(好友、朋友圈、图文/视频内容),内容种草,朋友圈可能存在好友拔草。这两种场景碰撞之后,转化路径很清晰,微信闭环内部就能完成种草后的关注、留言、咨询;

2️⃣关注、咨询:微信内建的通话机制 和 官方背书,用户是完全不用担心自己的信息问题,可以无心理障碍的在微信内部发起咨询、留言;

3️⃣微信商店?看微信到底还搞不搞啊。

图文内容、视频内容、种草/沟通咨询、订单、支付、核销、拔草体验分享,微信生态是具备完全闭环的能力的。

仰望

飞猪和美团都暂未描述,放到同维度略像牵强,当然不是否定二者自己领域的成功,其实阿里的飞猪旅行和美团都有自身的强大流量、场景优势。淘宝/天猫、美团都是已经国民产品了,大可感知到各自的优势和主要用户群、场景。

市场的魅力总是如此之大,大的市场里面有小的赛道,赛道里面还有不同的领域,领域里面又有不同的企业和参与者。看似导游/向导、司机、甚至于餐馆、旅馆、酒店、旅游公司是脆弱的,时刻面临不确定的,可正是他们的脆弱让这个市场能够及时的感知到信号,即便我们会放下“正确”的错误,而这都将是我们变得更加强大,也成就了生生不息的旅游行业。

iSpiik快记:产品问题剖析及文档缺失的思考与应对

从产品感知层见底层资源构建;

从产品设计方案见一代产品经理心路历程;

就差告诉程序员怎么写代码了!!!

一个没有人敢动手的线上问题

2023年8月的一个工作日 ,被一个产品(支撑供应链采购业务的算法系统)线上问题闹得哭笑不得。

五手开发说自己没有改过,还说看过这里的代码逻辑复杂,说程序逻辑存在现状本就会导致问题。可是,就是不知道问题出在哪里?(搁谁身上不来气就算你赢)

消失的产品设计/技术文档

怀念一手开发、一手测试,可惜走的走、散的散,就连产品团队自己也不清楚了。另外一个现状就是,作为算法产品,其实有很多逻辑构建+数据构建的模型存在,这两部分从领域划分上其实要算到开发、技术团队,但是开发/技术团队向来不喜欢做文档沉淀的,而这个过程产品团队没有同步参与对齐,自然在产品相关的过程文档中也看不到丝毫的踪迹。最重要的结果就是,现在已经没有人能够说得清楚当时的逻辑到底是什么,也没有文档可以翻出来查看。

看清产品:由表及里,从里至外

无奈作为这个产品的四手产品经理(1.0版本已经是四五年前的事情了,负责的产品经理换了好几个),只好从产品的感知层开始(看交互界面的信息结构设计、往下再看结构层的业务逻辑)一层一层往下推测勾勒数据结构,然后和数据库进行假设验证(拿到数据库的查询权限,在测试环境验证上层的逻辑和数据的过程对应),确保推演逻辑没问题。费老大力气,终于勾勒出来产品核心对象的大致数据结构和关联,几个关键对象怎么构建、更新,自然也就标定出来了问题点对象。

但是面对五手开发,程序员自己对代码逻辑毕竟不熟悉,结果依然是:不敢动!

好在又翻到历史一次上线记录出来,以前不是动过这里一次嘛!(上一次改动这个地方是这个程序员改的)轻车熟路,再来一次。这下开发有了信心,搞定✌️

为什么重要的东西却不见了?

往往面对上述这种历史问题,处理过程中是非常依赖到过去的文档的,但正如上文所说,文档往往也稀释掉了很多冰山下内容:比如核心对象的核心数据如何构建?比如关联对象间的数据关联和更新逻辑?等等。虽然偏技术范畴,但个人认为和产品设计文档能够结合在一起的话,对于一个敏捷团队来说绝对是功在千秋、利在当代。

至于为什么会出现产品技术文档、设计文档的内容缺失,个人认为有两个方面可以去尝试思考:

第一点是个人习惯问题,不排除负责某个产品的产品经理和开发者,包括测试大家对所有细节都了然于胸,但是却没有人愿意去把这些内容用文字、用流程图,甚至用一个简单的图形的方式沉淀记录下来;

第二点就是作为产品文档的维护者、设计者可能根本没有意识到、没有参与到、或者说没有思考到当然也不会介入到产品底层的数据和关键对象的构建逻辑。这就一定会为未来产品也在维护过程中埋下隐患,造成业务团队、产品团队和开发团队之间的脱节。这种脱节往往会可能直接影响到业务,打破敏捷的这种开发节奏,增加大家的沟通、协作成本,影响到其他项目项目的一些正常进度,更为可怕的是,打击产品相关人员的信心,导致没有人愿意或者敢去介入动这个产品,包括未来的升级,那么所有人都会倾向于找到时机,重新投入资源去重构这个产品,可我们明明知道 这无疑就是资源的浪费。

如何正确对待产品文档管理?

关于文档的管理可以参考之前两部分的分享:

1、明白文档的用户有哪些:产品设计实例,谁说产品经理只为用户负责?

2、文档的日常管理技巧:产品经理文档操刀技巧:让文档内容活起来

—————-(手动分割线)—————-

题外话,往往我们透过文档,看一份文档的写作风格、逻辑表述、与关键技术实现互为支撑的要求与预留,其实也窥探一二文档创作者当时的心路历程,妙不可言。

iSpiik快记:产品设计借鉴实例,对标企业微信

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

业务背景如下:

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

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

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

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

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

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

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

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

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

灿烂的花园:张颂文是一个顶级产品经理!

2024年4月底有一档综艺《灿烂的花园》开播,芒果台做的策划,当然编导只是找中了张颂文这个IP,至于综艺的内容主线… 跟编导似乎并没有多大关系。

这个综艺看到拍摄记录大概是已经有了两三年的策划跨度了,起因是张颂文老师常年租房居住在北京郊外一个叫“苏庄”的地方,15年之久,村子里面都陆续平房盖了楼房,房东也一心想趁早能够把自己的平房给盖成楼房,免得未来回来养老时候再折腾。经过多番暗示,张颂文老师需要搬迁了,但是他又是一个植物爱好者,面对自己满心经营栽培的满院子的花草树木他一心想要保留下来。

于是有了芒果台节目合作的契机,植物作为主线,搬迁和爱好作为起因,来搭建另外一处集住宿目的和花草种植目的的花园,融入张颂文日常的常规生活、熟人社交生活、社会(非熟人)社交生活。演员职业的平行线、日常慢生活视角的基准。

张颂文在《狂飙》爆火之后,终于强势进入到大众视野,精湛的演技、沉淀、体验、细节、热爱在一个人身上集合了。

灿烂的花园给我的感觉叫做“真人秀”,以前其他的真人秀节目叫做“真人演”。它们的区别在于:

真人秀——将现实世界真实自然人的常规生活进行记录展示的节目。

真人演——由真实自然人而不是机器人,在刻意有组织的演绎某种非真实的活动状态。

灿烂的花园看到了点不一样的东西,发现张颂文绝逼是个顶级产品经理啊!

演员的体系里面有一种理论叫做“表演体验法”,演员一般使用这种方法来理解和塑造实际的人物。这一点在节目中被张颂文正式的提到过,对象就是给马嘉祺以及另外的小朋友。有一期他带小朋友在村子里面一个百年老宅的大娘家参观,大娘的儿子穿的较为商务,皮鞋、黑色西裤、黑色商务羽绒服、还戴着蓝牙耳机,一直温文尔雅。

回去后张颂文便考马嘉祺他们刚才奶奶儿子的穿着、行为细节,推测他的职业、讨论为什么耳机会在左耳(因为右边要听乘客的声音)。张提到自己在生活中去融入、观察不同人的生活,和他们对话、问他们问题,这不就是妥妥的用户模型建立的工作嘛。

产品工作里面,产品设计团队也会做用户研究,可能是用户访谈、用户观察、焦点小组、利益相关方访谈、可用性测试等。核心就是为了找到用户的动机、期望/目标、外界之间的关系、行为方式/行为变量、态度等,从而构建出用户模型。用户模型就是产品设计研发过程的“导航”,张颂文老师深谙其道,演员也需要人物演绎设计过程的“导航”。

灿烂的花园还有另外一个主力支线,张颂文老师作为表演知识传播者的角色,向辐射人群进行表演知识的总结提取、讨论、输出、实践。

编导在开机时候被张颂文要求,拍摄的思路请按照张颂文老师的来,一定是一个不一样的视角。这一档综艺我力荐!但是这里有个隐藏技能,当一个优秀的产品经理面对观众时候,他也当然知道怎么把观众当作用户进行研究,构建受众模型,而你我也正是模型中的被抽象的对象啊。

iSpiik产品说:产品发布后的快速响应阶段,有预留的必要吗?

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


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


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


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


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


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

iSpiik快记:马斯克更适合造火箭,不是做社交

2024年1月在报童看到一个X战队的年度数据(Twitter,埃隆马斯克接手后的X):
·「为你推荐」的服务和排序系统进行了彻底的重构,代码行数减少了惊人的90%,
从700,000行减到了70,000行,计算资源的使用减少了一半,处理相同请求的能力
提高了80%
·精简了API中间件层的架构,去掉了超过100,000行的无用代码和数千个废弃的内
部接口
·平均每天,我们阻止了超过100万次的机器人注册攻击,并将私信中的垃圾信息减少
了95%
·重新配置了5200个机架和148,000台服务器,每年为公司节省了超过1亿美元
·进行更多的本地运算,这样每月的云服务费用减少了60%


看起来真的牛逼,并且2023马斯克上任之后还进行了裁员,自己搬着行军床在公司周周泡,员工也被搞到了84小时每周。

上述的年度优化更多是技术工程,像是项目的管理和成就。如果是一辆汽车,我想是底盘、悬架、发动机。
但确不是方向盘!x毕竟是社交媒体。


上面的东西是用户的刚需吗?
不,是管理者成本和效率视角的刚需。
那是管理者的商业刚需吗?
不,开源节流,源在市场中更为重要,用户洞察和用户的desire/need才是刚需。
哦,所以想说:马斯克更适合造火箭,你们没意见吧。