傆型 – Pretotyping

精益创业中给出的A/B测试以及灰度发布已经是互联网公司里很常见的验证方式。但是这些方法很大的问题是需要实现功能才能获得验证,为了实现功能,必须要开发、测试,从而造成验证成本增长以及反馈周期过长。我们的同事Daniel Teng和Jackson Zhang一起参与了在一些项目中发展并实施了傆型,并把傆型宣言引入到了国内。

大量投入之前,先问问你的“事”这些问题:

  • 关于行为:人们会调整自己的行为来适应它吗?
  • 关于外观:做成这样人们会喜欢吗?
  • 关于环境:人们会在自己所处的环境用吗?
  • 关于定价:人们会接受怎样的价格?
  • 关于功能:如果不能实现X,人们还会用吗?
  • 关于渠道:他们会通过这个渠道购买吗?

这些问题最终归结到傆型宣言:

  • 创新者重于创新点【创新点不如创新者】
  • 傆型重于原型【原型不如傆型】
  • 客观数据重于主观评价【主观评价不如客观数据】
  • 实际动手重于 夸夸其谈【夸夸其谈不如实际动手】
  • 简单重于 复杂【复杂不如简单】
  • 当下重于 以后【以后不如当下】
  • 承诺重于 呈阅【呈阅不如承诺】

Daniel和Jackson在意启部落发布了傆型的系列文章,包括

Share

引导师工具箱 – 收敛的秘诀

前回讲到(”引导师工具箱 – 发散的秘诀”),说到团队过程以及创新的过程其实是一个不断发散和收敛的过程,而发散时需要注意一些要点。今天我们需要讨论一下引导师如何引导团队进行收敛。

diverge

发散型思考会产生大量想法,很容易让人吃不消。很多人的直觉反映是抓住其中一个想法,然后催促团体把讨论焦点放在那个上面,这种反射动作几乎一定会让团队陷入动荡,因为不同的人通常会想要把讨论焦点放在不同的项目上。因此引导师需要帮助团队找到共同关心的兴趣点。

第一步 – 信息分类

长清单会让绝大多数人吃不消,因此需要把清单缩短,减少到人脑可以处理的程度,很多人认为归类是组织资料的最简单方法。团队一起创造类别意味着一场哲学讨论,因为每个人对于选用的词汇在意义上有不同的看法,有的人细节导向,有的人擅长整体思考。要整合彼此的信念和定义会让大家感到不安、挫败,会抗拒。但这是形成团队决议的必要过程,这可以帮助团队增加对于彼此的了解。

grouping

分类会涉及两种不同的心理任务,创造类别和依类别将项目归类

创造类别有两种方式

  • 从头开始创造类别 – 类似于意启前一阶段发布的文章“静默分组法”,从信息中发现并提炼类别。
    • 每个人轮流移动便利贴,把彼此相关的想法集结成主题
    • 鼓励类别的合并以及其他变化
    • 列出所有类别后,开始讨论
  • 根据预先定义的条件创造类别 - 与团队事先讨论好类别。
    • 一起选择一个或者多个条件,比如急迫程度、可行性、成本等
    • 找几个人,将清单项目归类到选定类别中
    • 一项一项的把清单项目归类
    • 说明一个项目可以归类到超过一个类别
    • 归类完毕后,一起审视

第二步 – 聚焦
对信息完成归类之后,需要从里面找到需要关注的类别,可以有如下一些方法:

  • 测试性投票
    • 每个成员有三票,可以随自己意愿分配
    • 允许成员将所有票投给同一项目
    • 不必把票都投完,尽管不鼓励
    • 选择票数较高的几项
  • N/3
    • 每个人分得相当于总条目数/3的选票
    • 每个人可以按照自己的选择分配选票
    • 选择得票排名前三分之一的选项

dotvoting

 

  • 选出真心值得做和真的很便宜选项
    • 每人分别有一票投给从长期来说真心应该做的条目,性价比超高的条目
  • 收益矩阵
    • 根据效果大小和实现难易建立一个矩阵
    • 让大家把条目分别移到相应的象限
    • 选择性价比高的条目

payoff

 

  • 时间箱 – Timebox
    • 引导师要不停地提醒大家时间箱的剩余时间,其实是督促大家做决策
    • 同时提醒大家,决策之后的执行也是按照时间箱(比如两周)的,会在执行后再去做调整,所以不需要找到完美的方案

hourglass

收敛的常见错误

  • 中场休息后,再也没有回来讨论清单
  • 没有时间控制 (决策是否完美不重要,关键是要不停地根据执行的情况去调整,因此是一个持续决策的过程)
  • 延时考量清单
  • 一组人分类之后,由另外一组人投票
  • 试着通过合并方式缩短清单,之后为了讨论如何称呼合并后项目而长时间争论
Share

引导师工具箱 – 发散的秘诀

Ace想和Daniel约一次电话会议,但是Ace和Daniel不在一起,他并不确定Daniel什么时候有时间,他给Daniel发了一封邮件

Ace -> Daniel: Daniel下周一下午两点有空么,我想和你同一个电话,讨论关于意启部落下个星期的发布计划。
Daniel -> Ace: 我下周二下午两点正好跟客户有个会议,因此时间上不凑巧。
Ace -> Daniel: 我三点不行,要不然下午四点如何?
Daniel -> Ace: 四点也不行,我要接儿子放学
。。。。

聪明的Ace,第二次换了一种沟通方式。

Ace -> Daniel: Daniel, 想和你同一个电话,讨论关于意启部落下个星期的发布计划。周一下午2点到3点,4点到6点可以。
Daniel -> Ace: 5点到6点可以的。
Ace -> Daniel: Cool

上面的两种沟通方式的最大不同是,第一次Ace总是先做选择,再询问Daniel,但是Ace的选择不能满足Daniel的要求,然后Ace再给出下一个选择,再次询问Daniel,效率比较低。第二次是Ace先给出多个选择,然后双方根据各自的选择,更快地找到双方的共同方案。

另外一个例子是克莱斯勒公司与丰田公司在汽车研发工作方式上的不同,也导致了最后结果的差异。

setbased

克莱斯勒公司用工作方式总是先给出一个方案,让大家去分析,给出改进意见,然后在对于方案在进行修改,不是发散的作法。而丰田则不然,他会对于汽车的各个部分给出可能的选项,然后找到其中的子集,也就是最终的解决方案,先发散再收敛。

diverge

发散(列出选择)和收敛(选择)的过程贯穿于工作、生活中的方方面面。在产品研发过程中,好的做法通常是一个先对待解决问题有一个发散,然后收敛到亟待解决的重要问题,接下来再对于解决方案有一个发散然后收敛的过程。开会的过程也是一个类似的过程。但是绝大多数团队在协作过程中并不重视合理的发散,从而导致的问题包括:

* 忽视了其他(更好)选择,从而丧失了机会
* 浪费时间,在不断串行寻找问题以及解决问题过程中,沟通效率极低

因此充分发散对于团队协作十分关键,引导师在帮助团队做发散时可以注意一下几个原则。

brainstorm

1. 暂缓评论
好的点子需要调动群体智慧,是团体内部相互激发出来的,评论和判断会引起无谓的争执,从而打消大家的积极性,不利于充分发散。

2. 异想天开
很多好的点子、方法是最初是一个疯狂的点子,很多人认为根本不可能。而很多创新就是由疯狂的点子来的。就像Elon Musk会挑战,为什么火箭升空之后都要爆炸,如果火箭能够自己飞回发射台,然后加注燃料,几个小时之后又可以下一次发射,因此他的团队开发出了Grass Hopper火箭。

3. 借“题”发挥
好的想法是在很多想法碰撞以及借鉴的结果,应该鼓励成员在分享想法的同时,互相借鉴,偷想法,然后演化出更有趣的想法。

4. 不要离题
发散也不是无限制的发散。针对问题进行发散时,首先要对问题的目标形成共识。针对方案想法作发散时,通常是针对同一个问题。

5. 图文并茂
人的大脑分为左脑和右脑。通常左半脑是分析性的,它将·小片小段的数据拼合成线性的、理性的思想。左边的脑中枢负责书写和口头语言,与大部分数学运算。右半脑则是综合性的,通过想象,模式和空间方位来处理大的,定义不完整的信息块。右半脑有处理复杂性和模糊性的更高级的倾向,似乎还包括创造性的脑中枢。 右脑看到的是森林,左脑看到的树木。因此为了充分激发创意,需要充分调动左右脑,把它画出来。

6. 多多益善
在发散过程中,重要的是数量而不是质量。

7. 正确的人激发激情
健康的发散需要合适的参与者,应该剔除打酱油的同学。不参与的同学只会给整个发散带来负面的影响。

Share

回顾蛇年,展望马年

本来想利用春节休假对自己的2013年做一个总结,反思一下同时定一下下年度的目标。(终于)花了很多时间陪儿子,只好把总结变成农历年的总结了。

目标回顾

还是先回顾一下2012年初设定的年度目标

  • 提高自己培训的能力,验收条件是成为认证Scrum讲师(Certified Scrum Trainer, CST)。 :D

去年集中了很大部分精力提高教授能力。从去年十月份开始,利用7个月时间准备,于2013年5月在拉斯维加斯顺利通过了最终面试,成为一个CST。同时经历了多轮迭代,对于“认证ScrumMaster课程”以及”认证Scrum产品负责人课程”做了大规模的调整,做了很多课程练习以及设计的尝试,完全摒弃了ppt,引入了图像记录,效果相当喜人。

通过这些系统的训练,开始掌握两种影响人的工具 – 培训和辅导(Coaching)。同时成为CST也可以更大程度上扩大自己的影响,并给自己和团队提供更多的经济灵活性。

  • 国际性发表与分享。 :D

这其实是提高国际影响力的一个验收条件,同时也需要向敏捷大社区贡献一部分自己的体会。分别在Scrum Gathering巴黎和印度分享了我的”ISNIPER”,从Esther Derby、Arto Eskelinen、Dr. Jürgen Hoffmann, Daniel Gullo那里收到很多有意思的反馈。这里其实也要感谢Mike Li,从前年开始帮我不停地梳理这个话题。

  • 技术与开源项目。 :(

参加一个Github开源项目,并发布可用版本。启动了ApprovalTest.py,可是又搁置了。优先级和时间管理的问题。

  • 博客争取两周一篇。 :)

总共完成了22篇,接近数量目标,但是发布很不均衡,4月份到8月份间一篇都没有发布。

  • 把Meditation变成一种习惯。 :(

三天打鱼,两天晒网。还是自我管理的问题。

亮点

  • 教授技巧

成为CST之后,重新设计了CSM和CSPO课程。完全摒弃了传统的教授方式,扔掉了幻灯片,代之以学生工作簿(Workbook)、学习引导与设计技术以及图像记录。课程分别在上海、香港、珠海、北京发布,影响开始出现 – 一些学员成为敏捷社区志愿者,而且也赢得了一些长期客户)。

  • 影响力及变革管理

个人不是很相信所谓的Scaling Agile以及Scaling Agile框架,因为说白了这些框架都是工具和流程,希望通过工具把人改变。而导入敏捷真正要改变的是人的思维方式和工作方式,人才是改变的主体。Satir Virgia早就告诉我们“Change happens one person at a time”。但是如果一个公司有几千人该怎么办?而这件事情其实是可以加速的,有两个人给了我们启示,一个是Malcom Gladwell,另一个是Geoffery Moore。而从自己的经历、体会中也感觉变革应该是以人为主的。因此2013年花费相当多的精力,研究如何引发人的改变,然后如何让一个个个体的变革引发一场运动。

  • 产品探索

这并不在最初的年度目标中,从最早和Jackson Zhang一起做的小培训,延伸到了产品探索方法,包括Impact Mapping,Design Thinking,Lean Startup,Pretotyping等等,变得越来越体系化,而且算是推出了我们自己的品牌意启

  • 点评

去年把绝大部分Coaching的精力都投入到了大众点评的敏捷转型项目,内容涉及到了Scrum、用户故事、工程类实践、产品探索与验证、个人修养等等方方面面,从深度到广度都是前所未有。无论对点评里的不少同学们还是对于我自身都产生了不小的影响。

  • 团队

Odd-e加入了两个新伙伴 – Joseph和Jackson,我们开始有Odd-e上海团队了。

  • 意启

又是一个意外之喜,从最初跟Jackson的一个社区小培训,我们现在已经有了网站、微信(Innolauncher)、微博(Innolauncher)、News Letter、创新周末、系列小培训,注册商标,甚至我们的小培训都做到了吉隆坡、长沙,话题提交到了敏捷2014大会(Orlando)。更可喜的是越来越多的伙伴感兴趣,愿意掺和,网站访问量以及微信订阅数持续增长,未来是什么样子,还是未知,但是这种不确定性恰恰是有趣的地方。Be Ready To Be Surprised。

亟待提高

  • 目标的设定

回顾去年的几个目标,完成比较好的,是验收条件比较明确,同时目标的意图也十分确定的两个,而仅仅给出Action,没有明确意图的那些目标,在新的目标和兴趣点出现后被挤掉,降级。

  • 专注,Say No

很难做到,想做的事情以及被迫必须做的事情总是比能做的事情多。

  • 坚持度

读过的书

影响力以及变革管理

  • Influencer: How To Change Everything

这是一本关于提高影响力以及如何施加影响不可多得的好书,从个体、社会以及结构三个维度给出了巨多有价值的建议和做法。

  • Parent Effectiveness Training

这是一本父母如何影响孩子行为的书,但是基本上这本书所有的方法都可以用来辅导团队。想要改变别人,第一个要改变的是改变人的方法。

  • Fearless Change

尽管Linda Rising是我的偶像,这本书还是在我的书架上放了三年。随着今年对如何施加影响的的兴趣越来越大,终于读完了这本书。总体的感觉是虎头蛇尾。开始的几章给我的”ISNIPER”不谋而合,让我感到惊喜。书中给出了改变四十几个改变人的模式,但是主线不是很清晰,渐渐地归于平淡。

  • Change Artistry

这其实不是一本书,而是Jerry Weinberg, Esther Derby, Don Gray, Johanna Rothman四个人在AYE Conference(Amplify Your Effectiveness)大会的系列论文集。第一遍读,感觉挺一般,有些虚,幸运的是我读书总是读两遍,第二遍的时候就发现了很多有意思、发人深省的要点。

  • 紫牛

Seth Godin是我的偶像,他是营销学的大师。很多传统的营销方法、理论在新的时代都行不通了,因此Seth让我们去制造一个创意病毒Ideavirus,然后让喷嚏者Squeezer去帮我们传播。变革其实就是对于新想法、新思维的营销。

  • 部落

一本一直想看的Seth Godin的书。当下的组织形式不再受地域限制、阶层已经不适应自我意识越来越强的个体。要去Lead一个变革,通过打造一个部落去引发变革。

  • An Agile Adoption and Transformation Survival Guide 

看过之后没有什么印象了,好像给出了不少Pattern, Framework。优点是免费的。

产品探索

  • Impact Mapping

从2011年的Effect Map一直到现在的Impact Mapping,Gojko为我们提供了一个十分有效的产品管理工具,这本书提供了很多使用Impact Mapping时的技巧、方法等。十分值得一读。

  • The FLIP Manifesto

一切都是反逻辑,十分有意思,十分让人深思。Daniel Pink的经典

  • Pretotyping @ Work

提供了很多种低成本的方法去验证市场以及客户需求,可操作性很强。

团队

  • The Skilled Facilitator

对于高阶引导师的大师级作品。很厚、很抽象。

  • Collaborative Intelligence

针对越来越多的脑力工作以及团队协作,Richard Hackman把《Leading Teams》里面的卓越团队的六个Condition,应用到了IT领域。 重来 – 37Signal公司对于创新、公司、组织的一些尝试和思考,十分反传统,但是跟Agile, Lean Startup运动很契合。

个人修养

 

  • 当和尚遇到钻石

感谢越男的推荐。如何把佛教的思考方式用来工作中,事业里。

  • 生活的艺术 – 葛印卡老师

关于内观的一本小书,发现跟Inner Game of Tennis,当和尚遇到钻石讲到的内容十分契合

 

技术

  • The Coding Dojo Handbook

为如何训练程序员提供了相当多的弹药,不同的形式,不同的Kata等。

  • Explore It

作为最有名的测试人员之一,Elisabeth在书中分享了她关于探索性测试的经验,很接地气。

自成一类

  • Fooled by Randomness

《黑天鹅》作者的第二本书,对我们的传统思维定式提出了很多让人发省的挑战。

  • 餐巾纸的背面

感觉不如Visual Meeting

  • Telling Ain’t Training

对于讲师或者Influencer们来说,十分值得一读。可以十分系统的了解一下教育学。

  • Road Less Travelled

读了一半,放弃了。

新年目标

  • 系统化的总结影响力以及变革管理

期望的结束条件是完成一本书,可能叫”Awakening Change”。 第一步其实是定义出书的MVP,然后再LeanPub今早发布。我想还是从英文版开始。

  • 创业的尝试

通过辅导一家创业企业或者亲自参与创业来获得体验、学习。

Share

PO as Problem Owner

前一阶段接触了一个新的移动App团队,跟大多数移动App团队一样,工作压力特大。闲来无事,就看看他们的Backlog吧,结果我发现他们“”的原因了。

我在Backlog里面发现了很多类似于下面的“故事”:

  • XXX页面重构
  • XXX详情页
  • XXX app 首页品类分类 入口
  • XXX app 首页导购模块
  • XXX app 个人中心重构
  • XXX页面增加YY标签
  • XXX页面增加活动入口

我同时也看了一下引用文档,其实也就是团队PRD(产品需求文档),里面内容跟上述“故事”长得很像。比如:

XXXX模块

  • 需支持灵活配置
  • 城市拓展
  • 分类名称调整(可支持二级分类)
  • 排序调整
  • 预留标志位

当前排序

  • 第一类城市:分类1、分类2、分类3、分类4、分类5、分类6、全部分类
  • 其他城市:分类1、分类2、分类3、全部分类

其实这个Backlog里面的“故事”根本不是故事,原因就是我们这些“故事”全部是解决方案,而好的用户故事是关于问题的。从我们上面的那些故事里面,我们很难了解这些故事是为了解决哪些业务问题,目的是什么。甚至哪怕是亲手写这些“故事”的“PO”同学们,两个星期之后也不会记得这些用户故事是为了解决哪些业务问题了。

接下来跟测试同学坐在一起好好比较、分析了我们的App和竞争对手的App后,渐渐明白了这些故事的业务目的。原来所有这些故事全是在“抄”竞争对手的功能。再花一些时间比较一下两个App,发现竞争对手缺失能够比我们更好的解决客户问题。

  • 竞争对手App上,提供了各种主题的搜索入口,因此我只要很少几次Click,就可以迅速的定位商家。
  • 竞争对手定位比我们的App准,而且针对地域推荐的商家也更符合客户的需求。

接下来,我做了一个思维导图,不完全的列出了竞争对手的实现所解决的业务问题:

  • 如何更方便的找到商家
  • 如何发现未知的可能感兴趣的商家

impact mapping

这两个问题还是比较大,所以我把问题做了一下切分,然后很容易就可以写成用户故事的格式了。

  • 作为消费者,我希望通过主题搜索商家,从而可以让我可以快速找到想找的商家
  • 作为消费者,我希望看到的主题是根据我的消费习惯相关,从而可以让我可以快速找到商家。
  • 作为消费者,我希望在搜索结果比较少的时候,给我提示或者推荐,帮我去发现喜欢的商家。

我们的用户故事应该描述的是如何跟竞争对手一样或者更好地解决客户问题。如果只是简单地从界面去抄袭,很难比对手更好地解决问题,原因很简单,对手明白他做一些的原因,这样的设计考虑到它自己的一些因素,而我们无从得知,只能猜或者从表面上去抄,根本没有办法超越他们。只有了解了目的、要解决的业务问题,我们才能够提出更好的、更便宜、更符合点评实际情况的解决方案。PO也应该多从问题角度,去发现竞争对手已经解决的问题,甚至还没有解决的问题,鼓励团队去创造性地解决问题。

Share

产品待办事项列表臭味之愚蠢( un-SMART, No Acceptance Criteria)

每次到新的客户那里,总会发现在“做Scrum”的团队,它们不能在本Sprint完成所有的用户故事,因此在不少公司的Scrum团队中甚至衍生出了开发Sprint,测试Sprint。甚至在去年有一家自以为Scrum做的不错的公司,做了这方面的分享,自认为这是一个聪明的改进,把它称之为“具有其公司特色的Scrum”。

Handgunning-Front-Sight-Wrong2-300x229

症状

  • 开发Sprint、测试Sprint、T-6、Hardening Sprint、发布Sprint
  • Sprint结束的时候,大部分用户故事完不成
  • 测试人员要等到Sprint结尾的时候才开始测试Sprint计划会议承诺的故事
  • 很难给故事定义明确的验收条件
  • Sprint开始几天内,没有用户故事完成

诊断
在Backlog中,高优先级的那部分故事,应该是SMART的(Specific, Measurable, Attainable, Resource, Timely)。这跟设定目标一个道理,远期的目标可以是大的、方向性的;但是近期的目标一定要具体,可完成的。不SMART的高优先级故事,会导致如下问题:

  • 很难完成Sprint承诺,测试人员在测试上一个Sprint的故事时,发现的bug会冲击到本Sprint的计划,从而导致本Sprint的故事延期
  • 排优先级十分困难,需要pk已“完成”的故事中的bug与当前Sprint中故事的优先级
  • 很难获得准确的开发速率(Velocity),因此很难预测发布计划。由于每个Sprint中“完成”的故事,实际上并没有完成,造成了较高开发速率的假象,但是项目后期,还是需要很大投入去维护
  • 缺失团队统一的Sprint目标,开发和测试人员的目标不一致,而这些团队成员的目标又与组织的目标(把功能完成、上线、获得客户)不一致。很难形成团队合力。

症因

  • 开发测试人员之间角色过于分明,过于强调工作移交而不是协同
  • 开发团队不愿意帮助PO切分用户故事、定义验收条件
  • 团队不掌握需求切分的技能
  • 测试人员不情愿重复测试同一个功能
  • 缺乏自动化测试支持

处方

  • 引入周期性的产品待办事项梳理活动
  • 团队一起切高优先级的用户故事,确保故事粒度在单个Sprint可以完成4-10个范围内
  • 引入实例化需求(Specification By Example)实践、用例子描述验收条件,并将之变成自动化测试
  • 对于一个用户故事如果需要过多场景或者测试用例来验证,需要把它从用户角度切分
Share

产品待办事项列表臭味之接力棒 (又称扔到墙外)

经常会有人让我帮忙,“Daniel,能不能教教我如何把我现有的需求文档转换成用户故事?”。问出这样的问题,说明他根本不理解用户故事是怎样玩的。哪怕是把他的文档都翻译成了用户故事的样子,也不是用户故事。

症状

  • 产品负责人负责写故事
  • 产品负责人单独维护产品待办事项列表
  • 团队等待产品负责人写故事
  • BA负责把需求说明书翻译成用户故事

诊断
事实证明对于产品开发活动来说,递增跟迭代工作方式更加有效。因为产品开发活动的本质是一种探索,有很多不确定性,比如市场、技术、业务、人员变化等等。很难一开始把一切都想清楚。Liz Keogh说过,“一个常见的错误是大家认为只要分析的足够多,就能够做对”。

产品研发是一个协作式创造的活动。团队内各种角色人员的对于待解决问题以及解决方案的共识对于协作式创造十分关键。接力棒式的协作方式会导致知识的丧失与不准确。尽管使用了用户故事以及产品待办事项列表,其实还是受到传统开发方式思维的影响。这种思维方式的会导致如下问题:

  • 忽视真正要解决的问题。开发团队距离真正客户太远,信息传递到开发团队后已经变得不准确,开发团队很难了解真正要解决的问题
  • 复杂的解决方案。为了应付“可能”有的变化,开发团队往往开发出十分复杂的技术和业务方案,从而提高维护成本
  • 更晚发现的缺陷。业务、开发以及测试对于同一个需求的不同理解必须等到产品开始实现或者完成后才会暴露,不同的认识会导致更多的产品缺陷。
  • 更高的Bug Fixing成本,因为Bug已经隐藏很久,在那之上有累加了很多的代码。
  • 大大降低应付变化的能力

症因

  • 传统开发方式思维的影响,角色之间职责的清晰划分
  • 开发团队参与需求的讨论和梳理的意愿不强
  • PO不愿意放手让团队一起讨论并梳理需求

处方

  • PO与团队一起梳理产品待办事项列表,包括:写故事、建立Story Map、切分、估算
  • 让测试人员提前调研用户故事的验收条件,并与PO和开发一起评估
  • 周期性的产品待办事项列表梳理
  • 项目启动时,只用准备第一个Srint的产品待办事项列表。
Share

傆型实战之三 – 探索者 (Explorer)

看门人(Concierge)MVP版本,两个多星期上线后,真正使用的商家有XX个,成绩只能说是马马虎虎。因为原先在版本上线前是我们设定的目标是:

  • 功能上线1周以内,20%商户使用该功能
  • 功能上线2周以内,40%商户使用该功能
  • 功能上线1个月,60%商户使用该功能,40%商户超过2次(含两次)使用该功能

从我们收集到的数据来看,总成绩马马虎虎,但是很有意思的是使用该功能的商家忠诚度很高。

iStock_000016573405XSmall-resize-380x300
目标
通过功能上线后采取不同行为的客户分别去访谈去了解原因,发现该功能的价值并发现能够进一步提高商户满意度的真正的问题。

行动:

客户分类
MVP上线之后,我们认为比较积极的那一百多家商户的反应并不一致,现在我们可以对客户进行分类,然后分别去分析背后的行为以及问题了。与PO同学商量后,客户可以分成以下几类

  • 收到通知,但是没有操作
  • 登陆页面,但是没有操作
  • 操作过一次以上的商家

电话访谈
PO和我一起设计了问卷,PO分别与各类的商家做了电话沟通。

访谈之后发现:

反馈呈现两极分化趋势:
使用过该功能的客户
整体感觉满意。验证了我们的假设,该功能解决了商户这方面的核心问题。MVP版本已经满足这一核心需求。
通过电话访谈中,我们还收集到了三个需求以及与竞争对手之间的不同。

还没有使用该功能的客户
有使用该功能的商户PO有如下感受:
1、说明问卷调研和用户行为的差异。我选择的样本用户已经是在问卷调研阶段反馈积极的商户。但是真正有行动的一半还不到
2、对于这部分商户积极性不大的主要原因还是觉得对现有的现状比较满意

对该功能的总体判断是:
1、该功能是一个锦上添花的feature,可以解决一部分商户需求
2、该功能用户的忠诚度很高
3、通过该探索,我们发现了其他一些可以提高商户满意度的功能点

探索者并不是泛泛的打打电话:
一般的产品探索往往会包括客户访谈、问卷等等。我们把这类产品探索的方式统称为探索者(Explorer)。这次探索的不同之处,并不是开始泛泛而谈,而是通过客户具体的行为把客户分类,然后定向的去探索。

Share

傆型实战之二 – 看门人 (Concierge)

上期讲到我们上线了一个仿真门,十一假期回来之后PO同学发现收到来自商家很多电话号码,甚至已经有商家开始抱怨为什么说发布功能,还木有发布。。。

背景
商家账单功能的仿真门(Fake Door)上线后,收到了~1000个号码,希望开通该项功能。这远比我们原先想象的要多(原先觉得只会有几十个或者上百个)。甚至有不少商家重复留号码。

假设
商家们言行一致,因此他们说想要,其实就是他们真想用这个功能。

试验
很多时候客户言行并不一致,仓促上线的功能,变成了一个摆设。最经典的例子是上个世纪八十年代IBM的“Speech to Text”项目

所以下一步我们要验证的几个问题包括:

  • 是否有商家会真正使用这个功能? 
  • 有多少比例的商家会使用这个功能?
  • 商家会以什么样的频率使用这个功能?
  • 商家在欠款多少的时候会使用这个功能?
  • 商家会在什么时候使用这个功能?

因此我们希望商户登陆商务后台之后,会看到一个页面,这个页面会显示它的可提金额,然后可以点击Button来提款,当然后台我们财务团队会手动完成流程,商家就会收到汇款。注意从商家角度,其实这个问题已经解决了。但是我们团队需要投入一定的功夫,目的是为了探索。这需要一定的成本,所以我们必须在期望发掘的信息以及成本投入之间有一个平衡。

PO同学这时候也召集了技术同学和运营同学。因为完全手动的话,会增加运营的工作量,所以大家一起讨论出一个性价比高的业务与技术方案。

1

 

2

 

团队共同设计了试验的方案。

另外降低成本的方向,是与另外一种傆型试点区(Provincial)结合。 我们会从所有的~1000个记录中取出一定的样本做试验。最终从1000个号码中找到了123个留过2+次号码的商家,因为我们会认为这部分商家的意愿很强。

同时一个靠谱的试验应该先设计好度量,其实也就是如果达到了什么样的目标,就说明试验成功了。下面是事先一起讨论的度量。

  • 样本范围100个商户(如果技术允许的话)
  • 功能上线1周以内,20%商户使用自提功能
  • 功能上线2周以内,40%商户使用自提功能
  • 功能上线1个月,60%商户使用自提功能,40%商户超过2次(含两次)使用自提功能

一个星期后,功能上线了。

开始的时候,我们决定不通知商家,因为原先的仿真门上线的时候,其实我们也没有通知商家。我们只是通知了内部同学们。

3

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4

 

结果
晚上上线后,下午有了第一个商家提出需求。

5

 

周五的时候,我们发现真正使用该功能的商家并不如我们想象的那么多,是不是他们还没有发现这个功能?PO同学在下班前对123个商家发了短信通知。两个星期内我们有过两轮短信通知,下面是两个星期后的商家记录。

6

 

两个星期的记录看下来,只能说马马虎虎,而且有意思的是一共有60个商家点击过该页面,只有43个商家真正操作,有17家没有啥都没做!所以接下来需要对各类商家进行访谈了。这也就是我们探索的第三步 – 探索者要做的事情。下回分解。

Share

傆型实战之一 – 仿真门

前一阵子与某客户团队一起做了一下客户自动提款功能的产品探索,过程很有意思,现在把过程总结了一下,变成了一个探索系列。第一步是仿真门(Fake Door)。

背景
客户需要周期性的给它的客户打款。竞争对手打款频率是比较慢,客户是打款周期要快不少。因此竞争对手推出了一个“主动提款”的功能,它的客户,也就是商家可以在网站上自己提出提款请求,竞争对手就会给商家打款。因为很多商家同时也是我的客户的客户,他们给提了这个要求,希望也推出相应的功能。

假设
打款频率足够高,因此这个功能的优先级不高。

试验
既然有了假设,有必要设计一个试验来验证一下,我们需要从客户那里收集是否有很多客户认为这个功能很重要。仅仅问可能不够,最好能让客户在于我们商家后台交互的过程中,给我们提供这些信息。所以我们就设计了一个仿真门(Fake Door)。我们照抄前一阵子我写的一篇维珍航空的仿真门的做法,我们也可以依葫芦画瓢。

方案
实现方案十分简单,一个只有一个文本框和一些文本的页面在九月底上线了。

7de981b2c7ad4673529433f26a89b592

 

 

期待
因为感觉这个功能优先级不会很高,所以猜想也就会受到~100个电话号码

结果
十月份回来之后收到了~1000个电话号码。

结论
看来想要这个功能的商家还真不少,似乎功能的优先级应该提高,赶紧去实现了。事实确实如此吗?下回分解

Share