iSpiik快记118:又遇到炮灰了?

R1:马上要给你的leder或者boss准备方案汇报了,聪明的你肯定做过炮灰方案,同时对你的标的方案先抑后扬;
R2:卖手机时候,经常见到一个傻子都很少买的配置版本的存在
R3:超市购物,总忍不住买了更大份更划算的那个
……
是的,这种情况恭喜你遇到炮灰版了。卖家总想把你限定在可选方案的对比中,去寻找局部最优、相对划算的那个。这点其实在互联网产品又何尝不是,你的产品、服务、解决方案都可以考虑这种思路#策略##ispiik小站#

iSpiik快记117:旅游批发商的推和拉

因为【随手扒一扒2020之前的传统旅游业OKris_3zzz】所说的库存多级模式,出现个有意思的现象,除了景区、酒店、旅游局会宣传某个地方,批发商也会介入在客源地对目的地进行宣传,这可以看作是“空军”作战部队 将信息触达C端,这是“拉客”;

然后批发商/同业操作中心都是2 B的,销售再去轰炸分销终端(那些门店或顾问),这是“陆军”地面部队覆盖,这是“推”;

相应的还有其他渠道:电话、微信群发、qq群发,甚至于挖墙脚等各种启动的方法。

这样看来,传统行业和互联网产品都一样需要类似的推拉、空军陆军等市场化手段,完成自己产品的启动。(2014年刚进入旅游行业就给团队提案了图片这个思路,咯咯咯,在后来的实践中所在团队在马尔达夫和长滩岛产品启动中就采用了类似方案,通过分众传媒、微博大V进行目的地的种草,然后销售去攻B端)#ispiik小站##营销#

iSpiik快记116:今天说说你手里的试用装

“试用装”这个词大家是否感觉都听烂了?也用过了数不完的试用装?
雅诗兰黛、兰蔻、碧欧泉之类的美妆试用品,是不是还躺在你的化妆台里
香奈儿、迪奥的小样还在散发着余香…
甚至汽车现在都可以先租来试用,好利来面包试吃也很棒

产品设计中又何尝不是,给用户几天免费的会员、让用户free使用30天、1个账号限定功能的免费版,这些都算是产品拉新阶段的手段。

2个思维路径:
①如果基于已有物种,去类比可以得到灵感,但总觉得招式没那么顺畅
②试用装本质是对用户需求进行粒度划分,对应过来对产品进行粒度划分,瞬间豁然开朗
#ispiik小站##产品#

试用装的诞生不是凭空想象,是对可以交付产品的粒度的拆解

iSpiik快记114:产品价值≠市场价值

市场需要流通才有价值,产品实现之后只是一堆功能和模块,如果没有用户这就是一堆废弃的数字垃圾。

用户因问题去找解决方案(产品),多彩的世界让用户和产品都已经陷入了困难的境地,用户不能天眼一下看到所有的产品,产品也不可能天眼一下触达所有的用户。

那么,如果让信息单元动起来,就是把“功能转换为卖点”的过程,这个阶段我们相信自己的产品价值,也会坚信给用户用上产品也是一种价值

iSpiik快记105:解构/建构vs需求/设计评审

产品实现中有2个节点很有意思,“需求评审”是你完成了现实的解构,要摆出来拿着放大镜🔍给别人看,你找到了真实的世界的真相,想到了到达那里的路径,进行了建构描绘。

“设计评审”更像是数字建构,用数字去勾勒将要组成的虚拟世界。

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快记077:微信朋友圈为啥不分组?

最近微信#朋友圈#屏蔽了不下100人,1400+的好友真不知道自己以前怎么加的。朋友圈简直是乱的一团糟,尽管好友标签分了组,最多也就是方便了定向投放朋友圈内容,但是我无法选择性接收内容。

微信朋友圈为什么不做分组?
熟人社交产品,如果有了分组再加上现在圈里的鱼龙混杂,那得是个死不死活不活的样子,像微博吧没有微博的开放和实效以及放大效应,像好友圈吧内容杂乱的跟食堂门口的海报栏一样。
你要么不熟就不加好友,加了好友说明关系、内容需求存在
你要么可以朋友圈单独设置不看某人,直接屏蔽掉省心省事儿
要么某些好友良心一些发圈时候,选择性的投放给可能感兴趣的好友可见

所以关系还是微信看中的,强关系就进入到好友list。但是毕竟现在用户规模把弱关系对象也可能裹挟了,不想看就单独设置呗

iSpiik快记074:谁没有经历过不那么完美的用户大会?

用户大会的频次想必都不高,筹备、人员、耗费都比较大,控制要求较高,能经历的都是财富。

2019年1月春节临近,那时候正在和美匣科技联合做旅游ERP 4.0版本,腊月二十三搞了个用户大会,乙方是给出了boss+产品leader+交付的4人阵容。我们则是本着恨不得把未来五年规划的用户需求都拉出来,阵容则是boss+操作部门总监+销售部门总监+销售经理代表+操作经理3人+项目PM的共计12人阵容。

16人用户大会一触即发,可想而知:
开局上次需求会系统演示之后,马上进入到拉锯战,无休止的发散讨论,大到产业链布局小到一个游客名单录入的细节,从沟通、讨论、拉锯一直到争论甚至尴尬,最终结果就是整整一下午一顿操作猛如虎,结果啥子都求没得。就得到一点,双方年后全力开火!

从产品角度复盘当时的用户大会的话:
for what?大会是否有清晰的标的,当时是模糊的。甲方是类似于项目外包的姿态,可毕竟没给项目外包的钱,乙方是核心用户的态度,但是产品上行业渗透欠佳以致路径规划未必最优,另外没拿到相应的回报也决定了不可能以项目的态度持续对待

when?where?how?时间地点人物设备材料,材料上是欠佳的。大会做不了决策,所以更多作用应该是通达信息、或者展示信息,事后分析提炼。而材料上,应该在有决策者参与的会议场合提前给决策者通气,协调共同的决议方向、流程。因为大会跑偏,多数时间是大boss无法代入。对会议组织者有了新的要求,把控到信息流达到呈现的层次 最多是准确理解的层面。

who?典型用户,那次大会算是双边会议,甲方边的典型用户销售、操作、财务、boss,乙方边的典型用户产品、开发。甲方要呈现自己的需求场景,乙方要描叙自己的产品路径规划

what.会议结论,资料整理,re给参会者

继续阅读iSpiik快记074:谁没有经历过不那么完美的用户大会?