一、用户验证和MVP
1、需求探索和用户访谈不能代替用户验证
- 用户访谈中，用户表达的内容大多是基于想象的，和真正使用过产品后的体验可能有很大偏差；如年轻人听到潜水会觉得好玩激动，实际上潜水是很危险的运动，很累，对体能要求很高等，和想象中是不同的
- 在做用户访谈时，无论你多么有技巧，大家都会碍于面子说一些你想听的话；
- 在用户验证阶段，观察用户真实的使用行为，以及他们是否真的会为产品付费；用户都说感兴趣，但是最终会不会买单，通过用户访谈时得不到真实结果的；
- 通过用户验证，得到意料之外的痛点；访谈不能代表实际的用户体验，如不同人买房考虑不同因素，你买房不会完全提供别人的，还是回根据自身实际情况考量；
2、企业不愿做MVP的4个认知误区
- 完美主义倾向：完美主义者总想把最全最好的产品或版本给用户，对于粗糙的产品或半成品不好意思拿出手；
- 这本身就不可能实现：因为如果没有用户的反馈，产品不能完善
- 也没必要：核心用户的宽容度比普通用户高得多，不会觉得产品有bug是多大的问题，会以帮助你找到bug为荣，会提出很多建议
2.担心被大公司抄袭：
- 想要争取先发优势：实际上先发优势并没有想象中那么明显；如做视频网站的土豆早于优酷早于爱奇艺，但现在爱奇艺规模/流量最大；如做团购拉手网早于美团，但现在美团位居第一；如做下载FlashGet、网络蚂蚁早于迅雷，但是迅雷的下载速度大幅提升；早期工具类App猎豹的其管理大师等软件位于下载榜的前列，但后来者百度、360也进入前列；所以先发优势并不明显
- 大公司在一件事情前景不明确之前，不会轻易出手/抄袭
3.担心品牌风险：大公司担心推出一款MVP，因为不成熟比较差会拖累公司品牌
4.担心MVP不成功，导致团队不稳定：时间成本是最大的成本，MVP不成功再等一年后也不可能成功
3、设计MVP的4个关键步骤
- 找出最需要验证的一个问题，每次只验证一个问题而不是两个或多个，其他问题通过常识判断
- 针对这个问题设计一个最简单、最有效的MVP，推给核心用户去体验
- 数据收集、亲自体验，然后再次访谈：数据不能代替你的亲自体验，并不是数据好就是真的好，一位内数据很容易被“修饰”
- 验证假设：对之前验证的问题下一个结论，就是这件事到底有没有得到验证
- 几个精彩的MVP案例
- 团购鼻祖Groupon（相当于美国的美团）的精益打法：
- 成立于2008年当时还没有网购网站的概念，主要验证两个问题：用户会不会花钱购买优惠券（常识判断会），商家利润低用户会不会重复到店消费-新客转化为常客（需要验证）；
- 传统需求验证：做一个网站-网站有很多商品分类/内容管理-网上支付购买优惠券/代金券-与线下商家做对账系统对接；
- 如果做MVP，最想验证的是商家是否接受/通过团购到底能不能帮助商家招揽生意/新客转化为常客这个问题
- 精益方法：在博客里发布信息，受众是博客的粉丝，每天只团购一个产品不做内容管理，用户手动通过PayPal付款不做网上支付，Groupon手动把优惠券生成pdf格式通过邮箱发送给用户，默认购买了优惠券的都会到店消费不做对账系统，极大简化了流程，更快的验证团购这件事可不可行
- 网上开店卖鞋快速做用户验证：
- 传统方式：找渠道、签订代理协议、订货有库存、物流合作、支付手段等问题
- 我们真正想验证的是用户会不会在你这里购买鞋子
- 精益方法：到实体店拍照、发朋友圈、用户感兴趣购买支付宝支付、线下购买并发货
- 迅雷的精益打法：
- 传统下载软件主要分为三个部分：一是BHO（Brower Helper Object）如何让浏览器拉起迅雷，什么情况该拉不该拉；二是下载功能本身，对HTTP/FTP/BT等协议的支持；三是下载管理，如果下载的人太多影像别人无法上网是否要限速，多个任务优先下载哪个，下载后是否自动关机等
- 最想验证的是迅雷创新的P2SP算法，能不能比被人下载快10倍
- 精益方法：不做BHO和下载管理，只能下载HTTP，只支持下载一个任务；提供一个对话框，用户把下载的URL从浏览器拷贝出来粘贴在对话框中下载
