精益创业(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. ?用户在??网站上能够产?生?行为，使?用留存率指 …… 此处隐藏：3011字，全部文档内容请下载后查看。喜欢就下载吧 ……