产品散点透视—超市vs医院

part1 base重庆 【超市自助称重】

2020年9月
①沃尔玛购物称重时候,发现几乎没有人工称重台了,几个自助称重机➕一个指导员
②永辉超市购物,依然人工称重台,但是结账时候 白天基本就是2个人工收银,其他自助收银台

继续阅读产品散点透视—超市vs医院

iSpiik快记136:超市里价签的烦恼

上周四驱车去沃尔玛购物,计划采购一些粗粮品类,买了红豆、莲子、黄豆、黑豆等,ok check!go!

①沃尔玛的人工收银相比Q3进一步减少,只留了2个人工通道,其余全部是自助结算,1个指导员+1个出口check的两人小组配置。自助称重环节仍然未改进,1人+4台自助称重,以至于自己称完之后总不放心价格还要跑去货架比对一下。
问题点是无意或恶意错选品类价格,导致直接经济损失、库存管理成本上涨,好处也很明显就是人工成本的下降。

问题的底层逻辑是:品类信息从货架到称重台之间的丧失,原来的价格信息是货架对顾客,称重员的核心其实是品类的正确分类选中。所以,品类信息丢失才是本质,你不能对要求自己员工一样要求顾客。

②自助结账时,有几个条码扫不出来,原来沃尔玛价签条码是横向的,我打价签贴包时候根本没想到条码的展开显示问题,尴尬的就是一个平面条码粘贴塑料袋变成了圆柱形之后,圆的直径<条码长度,就无法识别了,然后费劲又小心翼翼的撕开贴口才识别了出来。vs谊品生鲜价签观察了下是纵向的,就相对完美的避开了对粘贴的刻意要求。

所以是沃尔玛创始人山姆沃尔顿输出的经典概念【retail is detail】#沃尔玛# 的价值观之一,有问题吗?
我不确定是不是横向价签,适应的是人工称重+人工结算时候扫码速度更快。如果是,那这个点又成了新环境中的新问题了。

iSpiik快记092:需求管理的数字化价值

做需求管理,一方面是信息汇聚加工分发,另外我们总还想从需求管理中找点数字化的东西,让我们对这个混沌的世界可以有抽象的表达。

看板应付一般的需求管理还是足够了,搭建了小组、需求类别、完善需求属性之后,后续的需求燃尽走势图、需求小组分布图、需求周期甘特图,简直不要得到的太爽快。

①需求数量*提出人——人员的需求强度
②需求数量*时间——看产品的发展阶段、迭代速度、生产力
③需求数量*模块——找出来highlight模块

iSpiik快记091:少就是多,你怎么理解?

“完美不是无一分可加,而是无一分可减”

少意味着用相同的资源实现更高要求的质量,也符合长板理论而不再是木桶理论,打动用户的一定是你的优势而不是均衡,从峰终定律上看用户对你的感觉大概率来源于你的峰值体验 ​​​​

iSpiik快记090:迭代周期内的工作粒度怎么安排?

需求包的颗粒度要合适控制,一要具有关联性确保是流程线上的有关需求点,不至于一个批次的需求南辕北辙;

二是具有相互依存性质的特例需求,可能需求间互相依赖、需求和队友互相依赖,同样的这个问题在需求评估中也要考虑(类似于之前说的杠杆套,为了更重要的功能提前放出来的功能杠杆),每个批次需求包也好迭代周期也好,都有瓶颈所在,识别瓶颈才能迁就瓶颈;

三是粒度的划分要合适,这个问题我比作拿一个巨无霸面包吃和拿一个个一口可以吃完的面包的感觉,合适的粒度可以作为资源灵活调用,符合小步快跑的敏捷理念;#ispiik小站#

iSpiik快记089:价值需求、价值工程

每个人都面临过这种情况,A美食想吃、B美食也想吃、C美食也想吃,但是又不可能一次吃完,只能拍出来顺序,在一段时间内陆续吃完。

吃饭我们是怎么做选择的呢?
也许你会考虑,ABC三种的价格,到达ABC三个点的时间花费,以及三者目前的是否有活动又会、目前自己意愿里最想吃的是哪个,然后排除顺序。

在做产品的过程中会出现同样的问题,面临一堆产品需求,但是不可能在一个迭代内全部搞定,那在一个迭代周期内如何选择要做的内容也是个不得不面临的问题。通常上,可能是由boss直接基于经验判断拍脑袋,或者大家讨论都觉得应该做什么,不过总觉得虚了些。之前读到苏杰老师人人系列中设想过用群体打分获得商业价值(但是实操起来比现实),然后性价比=商业价值/实现难度决定需求list的优先级。

如果同类别需求,具有可比性,还可以尝试F/C的方式得到价值高的需求,F代表功能系数(比如有10个需求,每个对应功能值然后求和,F为当个需求功能值占比),C代表成本(简化为瓶颈资源,多数为开发资源,然后同样的求占比)。
———————————-
上面的过程也正应了:不能因为简单就先做,不能因为价值大就先做

得到价值需求或者性价比需求之后,还需要考虑:
杠杆套——连环杠杆的情况,比如#微信#  上线打飞机的那个版本,后来听说是个连环套功能,因为升级版本才能玩打飞机,然后客户端升级版本是微信支付场景的一个前置条件

iSpiik快记088:卡诺KANO模型

卡诺KANO模型做产品的人都不陌生,将产品属性分为:魅力、期望、无差异、必备、反向几种类型。

比如电脑带键盘,这就是必备属性,键盘带背光则是期望属性;你说把键帽上的字母象牙色调成珍珠白,就是无差异属性;价格预期内,usb全做成3.0算是期望属性;发热控制下还能做到极其静音或者干脆砍掉风扇就是魅力属性……

大二时候用上了第一部诺基亚手机6300,对当时的双边蓝色呼吸灯非常好感,当时觉得那个功能对我来说就是魅力属性,但是随着时间推移,这个魅力属性基本变成了手机的标配,降级为期望、必备。

发展的眼光同样适用在产品上,今天的魅力功能未来可能就是必配功能,意味着用户/市场/产品迭代、策略调整;更同样适用于组织管理中,意味深长;扩展出去,找对象也可以用这个模型,你还想到哪些呢?

iSpiik快记086:敏捷-在线看板

Leangoo的看板比较适合敏捷协作,不过在甲方原因内部协作人群有限,一直用个人版。
对于需求看板来说,除了时间线推进的泳道划分,还可以标签区分不同板块的需求。比如:业务、财务、数据等

引出来对于产品大需求包,那包含则是产品维度的:市场、开发、测试、支持、产品等板块内容。比较轻量的管理,一个看板搞定,对了还能到处list存档。另外跨看板的引用功能也不错

iSpiik快记085:需求到功能:支点、杠杆、瓶颈

从创作者角度,由用户需求到产品需求list再到feature list,都在找杠杆、放支点,让价值效率最高,不过必须要加入瓶颈理论的内容。

如果产生瓶颈制约点,肯定是发现瓶颈——迁就瓶颈——解决瓶颈的过程,其实对应到产品里面也类似于kano模型的几种划分

iSpiik快记084:用户想要的—>需要的

用户会为想要的而不是需要的东西轻易买单

想要的是用户内心产生的,这是源自人的层次需求;需要的是用户根据真实世界在自己认知的投射,产生的自我解决方案 想要的——>需要的,整个过程极短且较难察觉,常规上人们不会去刻意解构整个过程,但不代表它不存在 比如:得到有时卖的不是知识而是焦虑消除