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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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