1 Always a choice:一直在选择
最近跟市场的同学进行交流,发现他们最兴奋的事情就是:choice(选择)。市场变化很快,往往每一个选择都影响着之后的战略部署。
对于产品经理来说,有很多很多的想法,每个产品又有很多很多的功能,挑哪些来做才是正确的,这是一个难点,同时也是一个兴奋点。我们也是Always a choice。
花最大力气来做有价值的事情,这是大家都期望的。
本文介绍一个方法:MVP(最小可行产品),希望对读者有帮助
2 真实案例
2.1 用户真的会购买商品么?
之前认识了一个朋友,他们公司研发了一款新产品,在京东上发起了预售。预售效果非常好,有130多万台的预订量。公司非常惊喜,于是投入生产了4W台产品。但是到了正式发售的时候,只有2000多的实际销售量,结果库存积压,造成了不少损失。
2.2 商家会愿意使用新功能么?
2012年团购进入的白热化阶段,某团购为了进一步巩固供应商的关系,在结算方面进行了优化,由每月定期结算改成供应商自主结算。在调研阶段抽取了100个忠实的供应商进行深入访谈,有98个希望有这个新功能。在新功能上线的时候,结果只有2个供应商使用。
2.3 朋友会积极参加聚餐么?
前段时间有同学组织10周年毕业聚会,初定5月份搞起。全班60人左右,报名去的人有42个,等到聚会前的一周再确认的时候,结果只有7个人.总结一下上述的情况:感兴趣的人很多,实际参与的人很少。
3 ILI和OLI
这里引申两个概念:ILI和OLI。
ILI: Initial Level of Interests(上套指数)
OLI: Ongoing Level of Interests(上瘾指数)
一般来说,ILI是一个很好的指标,如果ILI的反映很好,是不是我们就需要开始进行需求评审、数据库设计、编码了呢。
上述三个真实案例,ILI的表现都非常好,但是OLI却很差。为了验证产品的价值,我们需要做一些尝试,来保证OLI是符合我们预期的。
4 MVP:Minimum Viable Products
MVP提倡两个方面:核心功能、足够小可用。
要判断核心功能,提供一个技巧。可以不断地问:如果缺少了****功能,则该产品就没价值,或者这个版本就没意义了。直到最后会发现剩下的只有少数几个功能,砍掉90%的功能后,该产品还是凑巧可用的。
足够小可用,这里需要模拟设计一个原型,主要用于快速验证产品价值和获取市场反馈。
5 成功实践
5.1 一个按钮和一个页面
刚才的案例二中提到的团购网站,有100个忠实供应商,其中98个(ILI)都希望有自主结算,结果只有2个(OLI)使用了该功能。
当时收到反馈有98个供应商希望有这个功能的时候,他们不立刻设计数据库和编码开发,而是做了一个MVP原型。针对访谈的100位供应商进行的结算系统进行特殊处理,增加了一个按钮“立刻结算”,经过一周的统计发现只有2个供应商使用了该功能。
于是公司继续进行采访,最终发现供应商都习惯了定期结算,并且对于供应商本身的营收账务也便于管理。而另外2位供应商只是因为手上刚好缺钱,所以才使用了这个功能。
这是一个成功的案例。
第一:核心功能是结算,对于这两位供应商,后台技术人员进行收工结算即可。
第二:功能足够小,加一个按钮和简单的页面,就可以验证了供应商的使用情况。5.2 两位客服
大众点评网想开发一个声讯餐厅订位功能。简单来说就是流程如下:1)用户在大众点评APP提交订单
2)APP后台使用技术把订单转化为声音3)通过电话服务商把用户的要求发送到相应的餐厅
4)餐厅接到电话后可以简单地按1或者2来选择是否接受预订5)最后大众点评把结果通过短信告知用户
需要开发出这套系统,至少需要几个月的时间。到底做,还是不做?
为了验证这个系统的价值,他们构建了一个MVP模型。
第一:提交订单功能使用一个按钮代替
第二:雇佣两位客服人员,把2-5步采用人工执行,把声讯从系统转为人工
结果发现这个功能挺受欢迎,目前该服务已在上海铺开。
6 我所学到的十件事(转)
1. 有人说愿意买,这话基本不靠谱
2. 如果有人跟你说:“虽然我个人不会用,但是我打赌,肯定有人喜欢用”,最终基本上不会有人用的。
3. 你要是问“你想要…吗”,“你关心…吗”这类的问题,答案毫无疑问,通常都是肯定的。
4. 如果有人抱怨说:“或许是我比较挑剔,但是…”,其实不是他挑剔。特别是,抱怨你产品很难用或者市场不明确。
5. 如果产品最终要收费,不要找那些啥事都想免费的人了解情况。(他们或许最终会成为你们的客户,然而这一般发生在你的产品成为主流产品,或者成为事实的标准之后了)。
6. 大部分人都会满足你的请求,前提条件是:请求很短,你很有热情,他们不需要做任何需要思考超过一分钟的决定。
7. 购买或使用产品的两大驱动力:孤立感和认同感。
8. 只有发自内心的喜欢用户才能构建出来好的产品。你不用是他们的同一类人,但是必须喜欢他们。
9. 当你开始思考:“这事比我原来想的要复杂”的时候,当机立断,停下手头的活,找人给你提提意见。这时候,你要么是搞错了,要么是把问题想太多了,旁观者清,第三者会比你更快发现这点。
10. 你的客户说要某项功能,这项功能本身远没有为什么他想要这个功能来的重要。
推荐文章:
《用户说卡,怎么办》
http://blog.csdn.net/minidrupal/article/details/24544573
《Scrum -- 晨会那些事》
http://blog.csdn.net/minidrupal/article/details/25547577
《产品经理的日常工作》
http://blog.csdn.net/minidrupal/article/details/26092691
《快速验证产品价值 -- MVP(最小可行产品)》
http://blog.csdn.net/minidrupal/article/details/26986885
《如何进行产品定位(上)》
http://blog.csdn.net/minidrupal/article/details/29386543
《用户研究那些事》
http://blog.csdn.net/minidrupal/article/details/35841945
《合理构建产品形态(一)——谁是目标用户》
http://blog.csdn.net/minidrupal/article/details/37767955
Introduction: Web工程师、项目经理、产品经理
Sign: 做人如果没有梦想,跟咸鱼有什么区别