精益创业(Lean_startup_note)

IMVU做的是切?入的是IM市场，提供了三维虚拟?人像聊天服务。假设：

2. ?用户会容易接受使?用现有IM的附加软件

3. ?用户会邀请?自?己的IM好友使?用

4. 需要兼容各?大主流IM的互通性

认知：

1. ?用户不介意安装和使?用新的IM软件

2. ?用户不想?用陌?生的IM软件邀请好友

3. ?用户需要?一个陌?生交友的IM社交??网络

构建：最?小可?行化产品 MVP (Minimium Viable Product)

投?入最少的资源构建?一个刚刚能够体现创新点或核?心价值的产品，并?立刻将其投?入市场。客户需求只有在实际使?用中才能验证，再多的前期调研也只能发现客户认为他们想要什么，?而不是客户实际上想要什么。因此在不了解客户真实需求的情况下，只会多做多错。

?一般意义上，功能越多的产品，将会有越多部分不满?足客户的实际需求，因?而变成?无?用功。很多?人不肯把?一个简陋的产品推给客户，但这实际上是?一种病态的完美主义。?比认为产品简陋更糟糕的是客户对产品不屑?一顾。认为产品简陋，?至少说明客户?用了这个产品。如果客户对产品的核?心价值表?示赞许，那正可以在此基础上进?一步完善；如果客户表?示不满意，那就应该改弦易辙。

案例Zappos

Zappos要建?立??网上鞋店，为了验证这个idea是否可?行，?用户是否会到??网站上?面去买鞋，创始?人跑到?人家的鞋店去和?老板商量，允许他给店家所有的鞋?子拍照?片，将这些照?片放到Zappos??网站上?面展?示，验证销售鞋?子，收取货款，处理退货和客服?支持的全部流程。

案例Dropbox

Dropbox公司创?立时，希望将??网盘与不同类型的OS进?行?无缝集成，该功能的实现需要较?高的技术?门槛，也需要?一定周期。因此在创业初期，Dropbox很难拿出原型呈现给?用户和投资者。于是Drew Houston（Dropbox的CEO）做了?一个3分钟的视频演?示放在??网站?首?页，在演?示中描述了产品的功能特点。这段演?示令产品的预订者在?一夜之间从5000?人增?至75000?人，很好地验证了市场对

这?一概念的接受程度。

Food on the Table(FotT)，?一家帮助家庭?用户提供菜蔬预订配送和?食谱建议的互联??网公司。FotT 最初只有?一个?用户。在没有任何IT ?手段辅助的情况下，FotT 的CEO 和产品VP 每周上?门收集客户订单并为其配送菜蔬。在这种极度没有效率的原型服务中，FotT 逐步地累积了对市场需求的认识并扩?大了客户群。随着?用户的增多，他们逐渐添加了邮件下单、菜单推荐、??网上?支付等各种?自动化功能。这过程中每?一项功能的增加都不是源于空想，?而是源于实际的、迫切的?用户需求。??目前，FotT 提供覆盖许多美国城市的?食谱选择、菜蔬团购和配送的?自助式??网络服务。

Groupon 是团购的鼻祖，Groupon 创业初衷是做?一个叫做热点的集体?行动平台，把?人们聚集起来共同?行动，但是效果不佳。08年底创始?人安德鲁梅森开始尝试团购的idea 。为了快速构建MVP 产品，?用WordPress 搭建了简单的??网站，?用FileMaker 保存优惠券，?用脚本把PDF 格式的优惠券通过Email 群发出去。以这种?方式?支撑了公司7个月快速的业务增?长。

MVP 与开发?高质量产品并不?矛盾。你应该放弃?一切对你需要验证的假设没有直接?用处的功能。?无论某项功能在开发的时候看起来多么重要，只要它不在你认知流程所需之内，都是浪费资源。简单说就是：集中?一点最核?心功能，其他所有功能全部砍掉不做，简化产品到极致。

新产品必须?而且只能抓?一个痛点功能，围绕?一个痛点把功能做透。任何痛点功能之外的其他功能都是对产品没有信?心的表现，必然失败。?一个痛点功能如果做透了产品还没成，说明?用户刚需没踩准，换个痛点功能重新做。每次做且仅做单痛点功能产品，不?行就换另?一个单痛点功能产品，?而不是堆砌了?一个多痛点的产品，让?用户去换不同痛点去试。

案例FotT

案例Groupon

MVP 的质量担忧

测量：创新核算 (Innovation Accounting)

测量的??目的是通过?一系列真实有效的指标来判断，当前的产品相对于上?一个版本，是否带来了真正的价值提升。测量的指标?非常重要，不能以总量的变化、?而应以增?长速度的变化来衡量产品的价值。例如，对?一项头?一个月有500名注册?用户、头?一年有6000名?用户的新服务?而?言，虽然?用户总量在持续增?长，但每月的新增?用户数却基本持平。那只能说明，它在这?一年中所做的更新或变化，并未增强对潜在?用户的吸引?力。因此，真正有效的测量指标必须要能够揭?示产品特性的变化与业务增速之间的因果关系，以便识别正确的增?长引擎。

创新核算的步骤

1. 确定基准线：搜集MVP产品的基础运营数据，如?用户?自然增?长率、留存率、活跃度和ARPU

值等，确定测量的基准线

2. 优化引擎：尝试把增?长引擎从基准线逐步优化到理想状态，任何改动都必须以改进某项关键

数据为??目标，?无数据导向的产品改动都是盲??目和可耻的

3. 坚持或者转型

案例IMVU的同期群分析 (cohort analysis) cohort

不是看测量指标的累计总数(虚荣指标)，?而是对测量?用户进?行分组对?比测试，观测不同分组之间的数据差异性。

尽管IMVU注册?用户数量始终上升，但是同期群分析显?示?用户黏性没有增?长，?而且?用户付费购买率只有1%。

案例Grockit的对?比测试(A/B Test)和看板管理 (Dashboard management)

Grockit的对?比测试：Grockit开发了?一项新的功能，先试?用再注册。允许?用户先体验过产品之后，当必须使?用某些功能的时候才注册。这是很多??网站的最佳实践，?而且从直觉上会认为这样做也能够提升?用户的注册率和留存率。但是Grockit开发了此项功能之后，采?用对?比测试发现，并没有提升任何数据指标，开发此项功能完全?无?用。

产品功能列表分为以下4种状态：

1. 待开发

2. 开发中

3. 已完成

4. 已验证

当D、E和A没有被验证之前，B和C即使已经完成，也不能被挪?入已完成队列中。H和I也是同理，在开发中队列已满的情况下，H和I功能不允许进?入开发阶段。

看板管理的规则：

1. 同时只允许有3项?工作任务出现在每个阶段的队列中，?一旦队列填满，就不允许再加?入新任

务。

2. 验证?一项功能必须通过对?比测试，?用数据指标测量它对产品的作?用，没有对?比测试，不准验

证通过。

3. 每次只验证?一项功能，如果多个功能同时验证，则?无法得到准确的数据测量结论。

4. ?一项功能只有通过验证阶段，才能从看板上删除，如果验证失败，发现这个功能对数据指标

不能带来提升，那么必须把和它相关的所有功能从看板中删除。

5. 团队的?工作量不是根据完成多少功能来衡量的，?而是根据通过对?比测试的，经证实的认知数

量来衡量的。

我们的dashboard：

分为三种状态：上线运营中，正在开发，等待处理中。总共34个项??目(还未细分)，每个状态队列?至少包括了11项?大型完整项??目。?无数据验证阶段，尽管?大家?工作很努?力，但得不到认可；每个队列?工作任务太多，疲于奔命。

Votizen的四次转型

Votizen 的创业idea 当中，需要验证4个假设：

1. ?用户对选民社交??网络感兴趣，使?用注册率指标

2. ?用户必须是已经注册的选民，使?用激活率指标

3. ?用户在??网站上能够产?生?行为，使?用留存率指标

4. ?用户把??网站推荐给朋友使?用，使?用传播率指标

开发时间

投?入资源注册率激活率留存率传播率3个月

1200美元5%17%002个月

5000美元17%90%5%4%3个月14000美元17%90%8%6%

留存率和传播率偏低证明假设3和假设4不成?立，产品需要转型。创始?人Davy 根据搜集到的?用户反馈，决定放?大式转型，即聚焦产品中的?一项受?用户欢迎的功能。

业务增?长?方式转变为?小额付费，因此需要测量?用户付费率和?用户ARPU 值，对?比转型之前的数据如Votizen 第?一次尝试：选民社交??网络

Votizen 第?二次尝试：社交游说平台 @2gov

下：开发时间投?入资源注册率激活率留存率传播率付费率ARPU 值8个月20000美元17%90%8%6%?无?无4个月

30000美元

42%

83%

21%

54%

1%

极?小

测量数据表明，?用户留存率和传播率都不错，满?足增?长假设，但是?用户付费率太低，ARPU 值太低，不满?足价值假设，?无法?支撑?一项盈利的业务。

客户细分市场转型，从B2C 转型为B2B 。3个月后发现?大型组织客户的签单达成交易?非常困难，不是产品的早期使?用者，创业转型再次失败。

开发时间投?入资源注册率激活率留存率传播率付费率ARPU 值8个月20000美元17%90%8%6%?无?无4个月30000美元

42%

83%

21%

54%

1%

极?小

3个月1个月

51%

92%

28%

64%

11%

0.2PM

付费率从1%提升到11%，每条消息收费0.2美元，验证了商业模型。Votizen 总共进?行了四轮精益产品迭代过程，迭代速度从8个月，4个月，3个月到1个月，迭代速度越来越快。精益创业的??目标就是：尽快?用尽可能少的时间和资源完成尽可能多的迭代过程。

每次迭代结束，创业者可以有两个选择，继续或转型。如果分析结果表明之前的假设基本正确，在学习过程中实现的?小的改变让产品越来越趋向于假设中的理想状态，那么?自然应当保持。如果数据不理想，是继续坚持改进，还是放弃转型呢？决策应该取决于你是否通过这次精益迭代获得了有价值的“经证实的认知”。如果没有得到经证实的认知，就盲??目放弃?无疑是错误的。但如果再怎么努?力，假设也与现实渐?行渐远，则可能需要通过转型对假设做?一些本质性的改变，这种改变可能涉及到创新的各个层?面：核?心技术、应?用模式、??目标市场、??目标需求、增?长模型、推??广渠道等等。?至于到底哪些因素的改变会带来最佳效果，可以在下?一轮迭代中验证。

为了处理有太多新的想法需要验证的情况，创业者可以?用之前某个较为稳定的产品版本作为基线，在此之上升级出多个平?行的版本，展开多个循环分别验证新想法的合理性，剔除其中不佳的部分，并将较好的想法合并到下?一个基线当中。

Votizen 第三次尝试：转型做B2B ，为?大型组织服务

Votizen 第四次尝试：?自助销售平台 @2gov

转型 (Pivot)

产品变得更好的想法?飘荡在空中，但?大多数想法带来的效果微乎其微，只能算是产品优化?而已。早期创业公司必须关注能产?生经证实的认知的重?大增?长?方?面。可持续增?长?方式主要有：

黏着式增?长引擎

通过增加已有客户对产品的黏着度，提升产品的价值。因此关键数据指标：?用户留存率和?用户活跃度。?用户的?自然增?长率必须超过?用户流失率，才能保证复合增?长率(?自然增?长率 - 流失率)。

例如社区??网站，我们不能仅仅看每天新增?用户注册量，?而应该精确核算注册?用户的回访率，即?用户注册之后，在?一段时间之内回访的频率。使?用同期群分析，观测?用户留存率。例如??网站的签约招聘客户，关键指标是续单率，决定了业务的增?长潜?力。

病毒式增?长引擎

具有病毒式增?长特质的产品依靠?人拉?人传播。?用户并?非刻意充当传播者，?而是产品设计了潜在的?用户邀请完成任务的环节，只要?用户使?用产品，就?自然带动了增?长。关键数据指标：病毒系数，病毒循环的速度取决于病毒系数。当病毒系数?大于1.0以上，将带来?用户的?几何级数增?长。

例如开?心??网的游戏：买卖奴?隶，停?车?大战，五分钟的开?心农场。邀请?用户参与游戏互动是产品本?身的?一部分，只要你玩游戏，就会产?生病毒式传播；例如Dropbox的任务系统，你要想获得更多的存储空间，可以通过邀请?用户来获得；Facebook也实现了病毒式增?长。

付费式增?长引擎

典型的代表是Google关键词??广告，关键数据指标：?用户获取成本和?用户ARPU值。只要?用户ARPU值?高于?用户获取成本，就可以实现可持续增?长。

?一项业务可以同时运?行?几种增?长引擎，即使是同?一产品，在其演化的不同阶段，采?用的增?长引擎也可能是不?一样的。但是成功的创业公司在?一个阶段只关注?一种增?长引擎，优化好增?长引擎。同时建?立三种引擎驱动的业务增?长需要的运营技能?非常复杂，欲速则不达。

四步创业法 (The Four Steps)

客户开发?方法 (Customer Development)

1. 从需求调研开始建?立假想的概念模型，先考虑少数?用户的需求，避免??广种薄收。

2. 从概念模型开始，寻找天使?用户去验证概念模型，检验产品是否能解决他们亟待解决的问

题。

3. 验证概念模型的??目的，并?非为了修改产品功能，?而是为了寻找天使?用户，为了?用天使?用户来

验证我们的假设，?而不是迎合?用户的奇思怪想，因此切忌被?用户牵着鼻?子?走，?用户说什么就改什么。

构建价值主张

1. 具有情感吸引?力，应该抓住?用户的情感?而不是理智，应该让?用户不由?自主的掏腰包，?而不是

下意识的按计算器

2. 要凸显优势，让?用户感到产品可以解决他们的问题

3. 名副其实，不要虚假宣传

4. 要符合相应的市场类型区分

技术接纳?生命曲线(Technology Adoption Life Circle)

鸿沟理论 (Chasm theory)

1. 不同?用户群接纳新技术新产品需要的时间不同。根据接纳速度快慢，可以分为：技术爱好

者、产品尝鲜者、实?用主义者、保守主义者和怀疑主义者五类。

2. 技术爱好者和产品尝鲜者构成了早期市场；实?用主义者和保守主义者构成了主流市场。

3. 相邻的?用户群体时间存在接纳鸿沟，其中早期市场迈向主流市场的鸿沟是最难跨越的。不同

?用户需求和消费习惯是导致鸿沟出现的主要原因。

4. 跨越鸿沟最?大的困难在于：赢得早期市场的成功经验难以运?用到主流市场。为了赢得主流市

场?青睐，需要全新的策略。

精益创业原则

1. 创业第?一天就设定收?入??目标 Revenue Goal from Day One

2. 持续的客户互动 Continuous Customer Interaction

3. 如果没有收?入，就不要扩张 No Scaling until Revenue

4. 产品开发周期-以?小时计?而不是月或者年 Product release cycle in hours not years

5. 产品开发功能- 最少的功能，最?大的客户覆盖 Minimum Feature Sets, Maximum Customer

Coverage

6. 产品开发 – 与客户拓展并驾 Coupled with Customer Development

本文来源：https://www.bwwdw.com/article/bc5q.html