Upload
robbin-fan
View
1.074
Download
6
Embed Size (px)
DESCRIPTION
The Lean Startup notes
Citation preview
Lean Startup Discussion
Robbin Fan
Why Creative Products Fail
• 不确定性太高– 新创产品对用户预测有太多假设,万一不成立,
就会失败• 产品定位可能错了• 研发周期太长以致错过机遇• 给产品赋予了过多职责,乃至不堪重负• 并非以用户需求为出发点• ......
Lean Startup
• 是程序员出身的硅谷创业者 Eric Ries 就任IMVU 创业公司 CTO 期间提出的
• 核心理念:通过加快产品迭代,尽可能早期上线产品,消除创新产品的风险
• 是一整套开发创新产品的理念和方法学• 每次迭代都是:未经证实的假设 -> 经证实
的认知
Lean Product Lifecycle - BML
idea -> (build) -> product -> (measure) -> data -> (learn)
Key Concept
• Idea• Build• Measure• Learn
Lean Product Lifecycle Target
• 快速迭代:加快速度• 小步前进:缩短迭代周期• 测试驱动:测量数据指标,得到可证实的
认知• 迭代结果:调整或者转型
Idea
• 未经证实的假设 (Unproven Assumption)– 价值假设 (value hypothesis)– 增长假设 (growth hypothesis)
• Facebook 的案例:网站上线 1 个月– 超过半数用户每天访问:价值假设– 哈佛 3/4 的学生注册:增长假设
Learn
• 经证实的认知 (Validated Learning)– 当你提出一个 idea ,它是一个未经证实的假设
(Unproven Assumption) ,精益创业通过一系列快速迭代,将它转变为一个经证实的认知,来调整你的产品方向。
Case Study: IMVU
• Idea– 用户不会愿意加入一个全新的 IM 社交网络– 用户会容易接受使用现有 IM 的附加软件– 用户会邀请自己的 IM 好友使用– 需要兼容各大主流 IM 的互通性
• Learn– 用户不介意安装和使用新的 IM 软件– 用户不想用陌生的 IM 软件邀请好友– 用户需要一个陌生交友的 IM 社交网络
Build
• 最小可行化产品 MVP (Minimum Viable Product)– 投入最少的资源构建一个刚刚能够体现创新点
或核心价值的产品,并立刻将其投入市场。客户需求只有在实际使用中才能验证,再多的前期调研也只能发现客户认为他们想要什么,而不是客户实际上想要什么。因此在不了解客户真实需求的情况下,只会多做多错。
Case Study: Zappos
• 最大的网上鞋店, 12 亿卖给 Amazon• 到别人的鞋店去拍照,让鞋店老板允许把
照片放在网上,帮人卖鞋• 验证网上卖鞋想法的可行性:销售鞋子,收取货款,处理退货和客服支持的全部流程
Case Study: Dropbox
• Dropbox估值 40 亿美元,有 2 亿注册用户• Dropbox难以实现一个可以实际运行和演示
的 MVP 产品,创始人录制了一段 3分钟视频放在网站上演示。
• 产品的预订者在一夜之间从 5000 人增至75000 人,很好地验证了市场对这一概念的接受程度
Case Study: FotT
• 帮助家庭用户提供菜蔬预订配送和食谱建议的互联网公司
• 使用了最小 VIP 用户的方式构建 MVP– CEO 和产品 VP亲自给一个用户提供全程人肉服务
• 随着 VIP 用户增加,逐渐添加邮件下单,菜单推荐,网上支付等网站功能
Case Study: Groupon
• 为了快速构建 MVP ,使用 WordPress搭建网站
• 用 FileMaker保存优惠券• 用简单的脚本命令将 PDF 的优惠券群发邮
件• 支持了 7 个月的公司业务增长
More Cases
• 联想乐 Phone2 的人肉 Siri服务– 联想的乐 Phone2 可识别用户的中文语音,然后为用户服务。并能够应对中国主流方言如东北话、上海话和四川话等。联想专门弄了个几百号人接听电话的呼叫服务中心,所有流程靠人肉来完成。
• 脉可寻名片扫描识别 App– 陈果 _George :刚使用了这个名为“脉可寻”
的“云端名片识别软件”,速度慢得惊人,准确率高得惊人,有些怀疑是云那端是人肉识别。
Measure
• 创新核算 (Innovation Accounting)– 测量的目的是通过一系列真实有效的指标来判断,当前的产品相对于上一个版本,是否带来了真正的价值提升。测量的指标非常重要,不能以总量的变化、而应以增长速度的变化来衡量产品的价值。
Measure Steps
• 确定基准线:搜集MVP 产品的基础运营数据,如用户自然增长率、留存率、活跃度和 ARPU 值等,确定测量的基准线
• 优化引擎:尝试把增长引擎从基准线逐步优化到理想状态,任何改动都必须以改进某项关键数据为目标,无数据导向的产品改动都是盲目和可耻的
• 坚持或者转型
Case Study: IMVU
虚荣指标
Case Study: IMVU
Cohort analysis
Case Study: Grockit
• A/B Test– 对比测试,将功能改动前后的版本同时放在网
上,对比不同版本之间的数据指标变化率• Dashboard management– 对产品功能划分状态阶段,每个阶段队列只能
有 3项功能,严格跟踪产品功能状态和强调数据验证
Case Study: A/B Test
• Grockit先试用后注册功能– 允许用户先体验过产品之后,当必须使用某些功能的时候才注册。这是很多网站的最佳实践,而且从直觉上会认为这样做也能够提升用户的注册率和留存率。但是 Grockit 开发了此项功能之后,采用对比测试发现,并没有提升任何数据指标,开发此项功能完全无用。
Dashboard Management
• 产品功能分为以下状态:–待开发– 开发中–已完成–已验证
Dashboard Rules• 同时只允许有 3项工作任务出现在每个阶段的队列中,
一旦队列填满,就不允许再加入新任务• 验证一项功能必须通过对比测试,用数据指标测量它
对产品的作用,没有对比测试,不准验证通过• 每次只验证一项功能,如果多个功能同时验证,则无
法得到准确的数据测量结论• 一项功能只有通过验证阶段,才能从看板上删除,如
果验证失败,发现这个功能对数据指标不能带来提升,那么必须把和它相关的所有功能从看板中删除
• 团队的工作量不是根据完成多少功能来衡量的,而是根据通过对比测试的,经证实的认知数量来衡量的
Case Study: Votizen
Votizen 1
• 选民社交网络– 用户对选民社交网络感兴趣,使用注册率指标– 用户必须是已经注册的选民,使用激活率指标– 用户在网站上能够产生行为,使用留存率指标– 用户把网站推荐给朋友使用,使用传播率指标
Votizen 1
开发时间 投入资源 注册率 激活率 留存率 传播率
3 个月 1200美元 5% 17% 0 0
2 个月 5000美元 17% 90% 5% 4%
3 个月 14000美元 17% 90% 8% 6%
8 个月, 2 万美元,留存率和传播率太低,产品失败!
Votizen 2: @2gov
开发时间 投入资源 注册率 激活率 留存率 传播率 付费率 ARPU
8 个月 20000 17% 90% 8% 6% 0 0
4 个月 30000 42% 83% 21% 54% 1% 极小
用户付费率太低, ARPU 值太低,不满足价值假设,无法支撑一项盈利的业务,产品失败!
Votizen 3: B2B
• 客户细分市场转型–从 B2C 转型为 B2B 。 3 个月后发现大型组织客
户的签单达成交易非常困难,不是产品的早期使用者,创业转型再次失败。
Votizen 4
开发时间 投入资源 注册率 激活率 留存率 传播率 付费率 ARPU
8 个月 20000 17% 90% 8% 6% 0 0
4 个月 30000 42% 83% 21% 54% 1% 极小
3 个月
1 个月 51% 92% 28% 64% 11% 0.2PM
付费率从 1% 提升到 11% ,每条消息收费 0.2美元,验证了商业模型。
Pivot
• 每次迭代结束,获取认知,继续还是转型–决策应该取决于你是否通过这次精益迭代获得
了有价值的“经证实的认知”。如果没有得到经证实的认知,就盲目放弃无疑是错误的。
–如果再怎么努力,假设也与现实渐行渐远,则可能需要通过转型对假设做一些本质性的改变
–如果有太多想法要验证,可以确定基线,发展多个并行版本,每个版本做一次精益产品迭代去验证
Pivot Type
• 放大转型• 缩小转型• 客户细分市场转型• 客户需求转型• 平台转型• 商业架构转型• 价值获取转型• 增长引擎转型• 渠道转型• 技术转型
Lean Startup: Drive
• 精益产品迭代的制订应该是反向驱动的:– 客户市场细分:打算给哪个目标用户群体提供服务?
– 价值主张假设:打算给目标用户提供什么服务?希望获得哪些“经证实的认知”? (必须包括价值假设和增长假设 )
– 测量数据指标:为了验证价值假设和增长假设,需要观测哪些数据指标?
–规划产品功能:为了测量到数据指标,应该开发哪些产品功能来获取数据?
TDD vs Lean
• 描述用户故事• 编写测试用例• 编写功能代码• 跑通测试用例
• 价值主张假设• 建立观测数据• 开发产品功能• 搜集数据验证
Emphasize
• 先建立假设,然后设置数据指标,最后描述产品功能。做产品是为了验证假设和获取测量数据服务的
• 先设置数据指标,后描述产品功能,而不是先开发产品上线,然后才考虑测量数据
• 开发产品功能是为了用数据验证假设,没有清晰的目标导向,没有完整的观测数据指标,无的放矢的开发产品功能是可耻的
Data
• 增长引擎 (Engine of growth)– 增长引擎是早期创业公司用来实现可持续增长
的机制。创业公司不会饿死,只会撑死。总有无数让产品变得更好的想法飘荡在空中,但大多数想法带来的效果微乎其微,只能算是产品优化而已。早期创业公司必须关注能产生经证实的认知的重大增长方面。
Engine
• 黏着式增长引擎• 病毒式增长引擎• 付费式增长引擎
Stickiness Engine
• 通过增加已有客户对产品的黏着度,提升产品的价值。
• 关键性数据指标:用户留存率和用户活跃度,用同期群分析留存率变化,而不是总量增长
• 用户的自然增长率必须超过用户流失率,才能保证复合增长率 ( 自然增长率 - 流失率 )
Virus Engine
• 依靠人拉人传播:用户并非刻意充当传播者,只要用户使用产品,就自然带动了增长。
• 关键数据指标:病毒系数,大于 1.0– 开心网 (买卖奴隶,停车大战 )–五分钟的开心农场–疯狂猜图 (微信朋友圈 )– Dropbox 任务系统:拉用户获得存储空间– Facebook 邀请系统
Pay-growth Engine
• Google关键词广告• 关键数据指标:用户获取成本和 ARPU• 只要用户 ARPU 值高于用户获取成本,就可
以实现可持续增长
The Four Steps
Discovery Stage
• 创业探索阶段:验证产品的价值主张 (value proposition) 和商业模型是否成立,不需要成立公司– Customer Discovery 进行用户市场细分,寻找天使用户,
通过和用户访谈,确定产品方向– Customer Validation 开发 MVP 产品,验证假设,如果不
成功,转型到第 1 步• 商业模型得到验证的标志:成单, MVP 产品有人买单。
• 精益迭代过程应用于创业探索阶段:– 寻找产品基本价值主张,验证商业模型
Execution Stage
• 创业执行阶段:开拓用户,建立公司组织– Customer Creation - 投入营销资源开拓用户渠道
– Company Building - 成立公司,建立组织架构• 精益迭代过程应用于创业执行阶段:–强化产品的价值主张,树立竞争门槛,拓展用
户
Innovators
• 天使用户– 早期小型试验的意义不在于找出普通用户,而
是要找到“天使用户”,就是那些最迫切需要产品,对你的产品相见恨晚的人。他们对错误更容易谅解,更渴望提供反馈意见,愿意传播产品。
• 天使用户的实证案例–纯银,白鸦,四海邮团队在微博上对彩程设计
产品 Tower.im 的吹捧和推荐。
Customer Development
• 从需求调研开始建立假想的概念模型,先考虑少数用户的需求,避免广种薄收
• 从概念模型开始,寻找天使用户去验证概念模型,检验产品是否能解决他们亟待解决的问题
• 验证概念模型的目的,并非为了修改产品功能,而是为了寻找天使用户,为了用天使用户来验证我们的假设,而不是迎合用户的奇思怪想,因此切忌被用户牵着鼻子走,用户说什么就改什么
Value Proposition
• 具有情感吸引力,应该抓住用户的情感而不是理智,应该让用户不由自主的掏腰包,而不是下意识的按计算器
• 要凸显优势,让用户感到产品可以解决他们的问题
• 名副其实,不要虚假宣传• 要符合相应的市场类型区分
Technology Adoption Life Circle
Chasm theory
• 不同用户群接纳新技术新产品需要的时间不同。根据接纳速度快慢,可以分为:技术爱好者、产品尝鲜者、实用主义者、保守主义者和怀疑主义者五类
• 技术爱好者和产品尝鲜者构成了早期市场;实用主义者和保守主义者构成了主流市场
• 相邻的用户群体时间存在接纳鸿沟,其中早期市场迈向主流市场的鸿沟是最难跨越的。不同用户需求和消费习惯是导致鸿沟出现的主要原因
• 跨越鸿沟最大的困难在于:赢得早期市场的成功经验难以运用到主流市场。为了赢得主流市场青睐,需要全新的策略
Lean Principle
• 创业第一天就设定收入目标 Revenue Goal from Day One
• 持续的客户互动 Continuous Customer Interaction• 如果没有收入,就不要扩张 No Scaling until Revenue• 产品开发周期 - 以小时计而不是月或者年 Product
release cycle in hours not years• 产品开发功能 - 最少的功能,最大的客户覆盖
Minimum Feature Sets, Maximum Customer Coverage• 产品开发 – 与客户拓展并驾 Coupled with Customer
Development