Tuesday, May 3, 2016

The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses


https://www.leangoo.com/9332.html
传统的创业理念有三个误区:
1、人们相信一个成功的产品来自于创始人的高瞻远瞩,似乎他们是一群独具慧眼、看穿未来的天才;
2、传统的产品研发周期较长,期间并不会有具体用户的参与,只有在产品发布之后,客户才有机会接触产品;
3、客户被认为并不能讲清楚自己的需求到底是什么,只有当产品摆在面前时,才会恍然大悟。
其实就算是现在,仍然有众多的创业者仅仅凭着自己想当然的一个想法去创业,并没有真的考虑过真实客户的实际情况和感受。从这个角度考虑,如果一个想法本身并没有解决任何问题,那这个想法就不应该形成一次创业的开始。如果大家能够掌握如何判断一个idea是否靠谱,那估计可以避免很多不必要的资源浪费。之前听过钱致远和袁店明老师的课,都对这个问题有过很好的阐述。任何一个idea,都应该通过分析是否可以为具体用户在何种特定场景遇到绕不开的问题提供有效的解决方案,来确定这是不是一个真的好想法。所以一个好idea的诞生,一定是要深入到用户中去的。
闭门造车,想当然地去创业,有以下三个重大危害:
1、你所认为你解决的痛点可能是个伪需求;
2、即便不是伪需求,你提出的解决方案并不能真的解决这个痛点;
3、就算能够解决,但市场上已经有了更优化的解决方案。
如果采用闭门造车的方法,就可能会在错误的方向上越走越远,且不自知。这将极大的增加创业的失败率。为了尽早验证想法,必须尽快让自己的idea接受用户的审视和考验。
精益创业究竟是什么?一言概括之,就是“用最小的成本和最快的速度验证一个想法,然后提取出对于客户来说最迫切的功能快速推出最初版本,并通过快速迭代不断修正并完善,使其不断贴近用户和市场的需求。”
那精益创业方法究竟如何应用呢?
1. 当你有了一个自认为惊天地泣鬼神的idea后,在你挽起袖子准备开干之前,需要周密的审视。首先利用精益画布工具整理idea的商业模式。
大家可以注意到“解决方案”只占整个画布的一小部分,而创业者通常只会对自己想到的解决方案激动不已,却对其他的要素暂时性忽略。这种不理性也导致了很多创业的失败。其实用户不关心你的解决方案是什么,他们只关心自己存在的问题。所以创业者的任务并不只是提供最佳解决方案,而是形成一套完整的商业模式,并保证模式中的所有元素都能相互配合,构筑坚固的逻辑链条。从一个idea出发,成功地创立一家可持续发展的公司,必须要面对表格中的所有难题。因此在你决定创立一家公司的时候,如果能对所有的这些问题有过深思熟虑,必将增加你成功的可能性。
创业其实最忌讳的就是贪大求全,任何伟大的公司,都是从一个极细分市场逐渐成长起来的

创业的初期一定需要脚踏实地,从一个客户的小痛点出发,逐渐扩充自己的功能。
创业公司的风险分成三大类:
a、产品风险(P) – 能否把产品做好;
b、客户风险(C) – 能否建立客户渠道;
c、市场风险(M) – 能否长期发展。
为不同的商业模式排序,遵循的原则是找到满足以下要求的商业模式,“有足够大的市场,有合适的客户渠道,客户真的需要你的产品,且你能借此发展壮大。”
具体来说,可以有以下顺序的判断:
A、客户痛苦程度。应针对最需要你的产品的客户开展业务。
B、获取客户渠道的难易程度。
C、价格/毛利的多寡。
D、市场规模。
E、技术可行性。

相信一定有很多创业者会对过早地针对自己的idea进行客户访谈有担忧,害怕有人剽窃自己的idea。但实际上把一个idea转化成真正有效运营的公司,更多的是看创业者的行动能力,idea仅仅是一个开始。更何况很多成功的公司最终的产品和它最原始的样子相比可以说是面目全非了。成功的公司一定像个健康的有机体,是可以不断新陈代谢的。一个成功的公司,一定能建立它独特的竞争优势,也就是它的竞争壁垒,但这壁垒一定不是仅仅来自于一个idea。
事实上,采用精益创业的方法,客户访谈是非常重要的步骤,不仅仅在验证想法阶段,在推出最小可用产品(MVP)后,在产品快速迭代过程中,都是必不可少的。成功的创业,一定意味着你能用独特的方法解决特定人群相当困扰的难题,如果你不能贴近你的用户,倾听他们的声音,你如何知道自己的行动奏效了呢?
奏效的客户访谈,一定是一对一的面谈。忘记那种许多人一起参加的见面会或者是问卷调查吧。人都有从众心理,只有在单独一个人的时候,才能真实地表达想法。也不要去搞那种街头访谈,应给每次访谈留出至少半个小时。几分钟的匆匆交谈,大部分的人都不会敞开心扉。
使用你总结的精益画布,针对上面的重点问题,例如痛点,痛点背后的用户场景假设,用户实际生活中的感受和现有解决方案等,设计合适的访谈稿。虽然针对不同的访谈对象,访谈内容可以有所不同,但必须以访谈稿为主线,以防遗漏和跑题。
这一阶段的访谈,重点在于对想法的验证,因此你并不需要真的准备好你的产品,甚至不要去谈自己的解决方案,以免让用户感觉是在参与一场产品推介。
访谈至少要进行20到30次。每次访谈之后都需要详细记录。最后针对访谈获得的信息,再次审视自己的精益画布,做出有针对性的修改。
4.针对自己对痛点的解决方案进行用户访谈。
经过上一个步骤,你应该对自己的idea有了更加深入的思考,对解决方案一定有了全新的认识。如果你所想到的客户痛点是真实存在的,而你也认为你的解决方案是真实可行的,请不要忙着去做开发,你应该再做一次针对解决方案的访谈。
你并不需要拿出真的产品,你只需要准备一个可以演示你的解决方案的东西,比如photoshop做的界面图,或者是CAD模型之类的东西。总之要既快又省钱。
但演示产品必须遵循以下原则:
A. 演示产品必须是可实现的;
B. 演示产品看起来要够真实;
C. 演示产品必须能迅速改进;
D. 演示产品应尽量避免浪费;
5.推出1.0版的产品。
经过两轮访谈,你的画布也许已经有了不少修改了。现在到了推出真实产品的时候了。要注意的是,第一版一定应该是精简版的,只包含那些最必要的功能,至于那些不紧迫的和锦上添花的功能,暂时通通忘记吧。1.0版的产品,就是所谓的MVP。
之后便是在你的受访者或其他愿意成为早期用户的人群中推广使用。这个过程中,一定要积极主动地去获取用户的反馈,也就是你要安排更多的访谈了。根据回馈,筛选出和你的目标功能方向一致的意见,迅速对产品进行迭代修改,快速发布更新。
这个阶段一定要注意,你要争取更多的获取定量的反馈,如果你开发的是一个手机app,就一定要根据实际情况预先准备好相应指标的监测功能。
有一点必须注意,必须全面的分析用户的反馈,并不是任何用户的反馈都需要加入待改进工作表里的。一定要持续关注产品的最核心功能,不要让其他的功能将其湮没.
6.正式上线产品。
MVP经过快速多轮的迭代改进,已经得到很大改善,初期的天使客户也积累到一定程度,这时可以正式上线产品了。但这可不意味着高枕无忧了。监测用户使用状况和积极获取反馈的工作必须持续进行。
随着产品的完善,你自然而然地会想到丰富产品的功能。但这时必须提高警惕。添加功能应该是以MVP为逻辑起点,不断增强自己的核心卖点,绝不应该为了添加而添加,变成酷炫功能的堆积,这样做只会减弱产品在用户心目中独特的定位。在这个阶段可以用看板工具来管理开发任务。
有一个原则必须清楚,功能的开发必须在公司可支配资源的框架下,继续采用快速开发快速迭代,绝不能陷入一个长期的封闭开发的困局。
不论是开发软件,还是开发具体的产品,精益创业方法都可以立即帮助到创业者。采用精益创业方法,创业者会时刻保持清醒的头脑,时刻关注资源,时刻微调方向,这将会是走向成功的重要保障。从我本人的经历来讲,之前的几个项目,其实就是失误在没有系统性地分析idea,想当然地评估风险,并且没有最有效地利用资源。各位如果有过创业失败的经历,一定能从这本书中找到共鸣。
http://www.jianshu.com/p/456d0f8003eb
如果说《从0到1》在讲战略上你应该如何定位,那《精益创业》更多的在讲策略上和执行上你应该如何做。

创业的根本目的是在极不确定的情况下建立组织机构,它最重要的功能就是学习。为了实现愿景,我们必须明确哪些策略是可行的,哪些是过滤的。我们必须了解顾客真正需要的是什么,而不是他们自己说想要什么,或者我们认为他们应该要什么,我们必须认清自己是否朝着可持续企业之路发展成长。作者用自己的IMUV项目实例解释说明了经实证的认知过程。我们的努力有多少创造了价值,有多少被浪费了?学会预见到浪费所在,并有系统的排除他们,是精益生产的核心。经证实的认知就是了解到:顾客所需之外的任何努力都可以不要。“需要开发这个产品吗?”、“围绕这一系列的产品和服务,我们能建立一项可持续的业务吗?”是我们每次需要用实验获取的“经证实的认知”。



五、最小化可行产品
一个最小化可行产品(Minimum Viable Product)有助于创业者尽早开启学习认知的历程,以最快的方式、最少的精力完成“开发-测量-认知”的反馈循环。MVP并非用于回答产品设计或技术方面的问题,而是以验证基本的商业假设为目标。因此,任何超出早期使用者需要的额外功能或修饰,都是资源和时间上的浪费。开发最小化可行产品的简单原则:放弃对你需要的认知没有直接用处的一切功能、流程或努力。最后,MVP常常带来坏的消息,做好接受这些事实的准备,会对你有所裨益。
六、衡量
商业计划内的财务考量包括:预测企业期望吸引的顾客数量,要花多少钱,以及将产生多少收入和利润。然而这只是个理想,离实际相去甚远。一家新创企业的工作:
1)严格测量企业目前的状况,正视评估中揭示的现实真相;
2)设计实验,从而了解如何让真实数据向商业计划中的理想目标靠的再近些。
创新核算始于把信念飞跃式的假设转化为定量的财务模型。该模式提出一些假设:即将来业务成功时,会是什么样子的?两类不同增长驱动因素:
1)公司的增长主要取决于三个因素:单一客户获利率、获得新顾客的成本、现有顾客的重复购买率;
2)网络效应(新卖家和新买家的高保留率)。
创新核算分三步走:
第一、使用MVP确定企业目前所处阶段的真实数据;
第二、尝试把增长引擎从基准线逐步调整至理想状态;
第三、决定坚持原来的战略还是转型。
MVP让新创企业在其增长模式中填入了第一串真实的基础数据——转化率、注册和使用率、顾客生命周期等。当你在商业计划内众多的假设中进行挑选时,先选最冒险的假设来测试才有意义。如果你找不到降低这些风险的方法,也没有必要测试别的假设了。比如从事广告销售的媒体业务有两个基础假设:它能持续捕获一个既定客户细分市场的注意力吗?它能把这种注意力卖给广告商吗?在这两个假设中,风险更高的是持续捕获受众注意力的能力,因此第一个实验应该涉及内容制作,而不是广告销售。
追踪对增长引擎非常重要的“漏斗式衡量指标”行为:从顾客注册、下载应用程序、使用、重复使用到购买行为产生。新创企业必须以高标准来衡量其进展状况:即能够围绕产品或服务建立起一项可持续业务的证据。只有当新创企业做出清晰、实际的预测,才能对这个标准进行评估。如果你开发的东西是错的,那么优化产品或者营销方式都不会产生什么重大结果。

转型是一种特殊形式的改变,用于测量新的产品、商业模式和增长引擎的基本假设。转型可分为以下几种情况:
放大转型:之前被视为产品中单独的一个功能特性,成为了产品的全部。
缩小转型:把原来的产品转化为一个更大型产品中的一项单独的功能特性。
客户细分市场转型:产品的前提假设得到部分证实,解决了相关问题,但针对的是与原本预期不同的顾客。
客户需求转型:当我们发现我们想要解决的问题对顾客而言并不那么重要,他们有一个更急迫的需求待解决时,我们可能需要重新定位现有产品,甚至打造新产品。
平台转型:从应用产品转换为平台产品。
商业架构转型:公司有两种主要商业架构——高利润低产量(复杂系统)模式和低利润高产量(规模运营)模式。在转型过程中,新创企业有可能会转变其商业架构。
价值获取转型:收入模式转型,公司获取价值方式的转变,会对产品、市场营销战略带来深远的影响。
增长引擎转型:带动新创企业成长的增长引擎主要由三种:病毒式、黏着式和付费式。公司为追求更快速、更高利润的增长而改变其增长策略。
渠道转型:通常情况下,对渠道的要求决定了价格、功能特性和产品竞争格局。渠道转型认为,可以通过不同的渠道实现相同的基本解决方案,而且效率更好。
技术转型:有时候公司会发现运用一种截然不同的技术,也可以获得相同的解决方案。并且这种新技术比已有技术提供了更优越的价格和产品性能

以小批量工作的最大好处就是能早早发现质量问题。迁移到创业上来说,精益创业的目的并不是高效开发更多产品,而是尽可能迅速地学会如何创建一项可持续的业务。用小批量的生产方式能快速完成开发-测量-认知的反馈循环,对顾客更快了解的能力是新创企业必须拥有的重要竞争优势。

九、成长
增长引擎是新创企业用来实现可持续增长的机制。可持续增长的特征体现在:新顾客是由以往顾客的行动带来的。以往顾客推动可持续增长的方式主要由四种:
1.口碑相传:大多数的产品有一个自然的增长水平,由满意顾客对产品的热衷程度而形成。
2.产品使用带来的衍生效应:不管出于赶时髦还是彰显身份地位的考虑,每次使用像奢侈品这类的产品时,都会引发旁人对该产品的认知。
3.有资金来源的广告:大多数业务用广告来吸引新顾客使用新产品,要让这种方式成为可持续增长的来源,广费费用必须由收入支付,而不是依靠资本这种一次性的资金来源。
4.重复购买或使用:有些产品通过付费计划(有线电视公司)或自愿的多次购买(去同一家食品杂货店),实现重复购买模式。
这些可持续增长的来源为“增长引擎”提供了动力,每架增长引擎都有一套内在的衡量指标,决定了当时使用这架引擎时,公司能增长的多块。增长引擎有以下三种:
黏着式增长引擎:这种增长引擎需要吸引并长期保留顾客。使用黏着式增长引擎的公司要非常仔细地追踪顾客损耗率,即流失率。流失率是指在任意一段时间内,没有继续使用公司产品的那部分顾客占顾客总数的比率。如果取得新顾客的比率超过流失率,产品将会增长。增长的速度取决于“复合率”(自然增长率-流失率),高复合率将带来极快的增长,不需要依靠广告、病毒式增长或公关噱头。
病毒式增长引擎:产品认知度在人群中快速传播,就像病毒散播传染病一样。病毒式增长与口碑增长有明显的区别——具有病毒式增长特质的产品依靠人与人之间的传递,是正常使用产品的必然结果,顾客并非有意充当布道者,只要顾客使用产品,就自然带动了增长,病毒式传播无处不在。病毒系数用来测量每个注册顾客将带来多少使用产品的新顾客。系数如果大于1.0的话,病毒将呈几何数级增长,因为每个注册成员都会平均带来超过1位顾客。依靠病毒式增长引擎的公司必须关心如何提高病毒系数,这比任何其他事情都要重要。通常病毒式产品并不直接向顾客收费,而是依靠广告这样的间接收入来源,因为病毒式产品在获取新顾客和招募他们的朋友过程中,不能有丝毫窒碍,否则会使病毒式产品的价值假设测试变得非常困难。对价值假设的真正测试往往是用来衡量顾客和提供服务的新创企业之间自愿交换的价值。顾客向该产品投入了时间和关注,使该产品对广告商产生了价值。
付费增长引擎:从每位注册顾客赚取的利润减去获取新顾客的成本。如果一家公司企图提高增长率,要么提高来自每位顾客的收入,要么降低获取新顾客的成本。每位顾客在其“生命周期”内为产品支付一定费用,扣除可变成本后,剩下的部分被称为顾客的“生命周期价值”(LTV)。这项收入可用于购买广告,作为成长的投资。
成功的创新企业只关注一种增长引擎,做好所有令此引擎运作的工作。如果你还不确定哪种增长引擎最有效,尽快走出办公楼,花时间理解客户,建立好自己的信念飞跃假设。如果你试图使用病毒式增长引擎,放心地把无关事务放在一边,把开发精力集中在可能影响顾客行为的病毒循环上,而不需要专长于市场、广告或销售职能。相反,如果公司使用的是付费式增长引擎,就需要赶紧建立市场和销售团队。
一家新创企业在调整引擎的过程中,使用创新核算评估每次开发-测量-认知的反馈循环,衡量自己是否向着产品/市场契合(新创企业在某个时候发现了对产品产生共鸣的一大群顾客)靠拢。真正有用的不是原始数据或虚荣指标,而是企业进展的方向和程度。
    http://blog.sina.com.cn/s/blog_53e3a8170101fyn5.html
    第六章《测试》
        本章通过一系列的案例,说明最小化可行产品对创业者来说是多么重要的一个活。
        如果我们不知道谁是顾客,我们也不知道什么是质量。设计是寻找顾客,质量是留住顾客。
        一个最小化可行产品有助于创业者尽早开启学习认识的历程。
        最小化可行产品的开发中,也会遇到很问障碍,如法律问题、对竞争对手的恐惧(特别是对大公司的恐惧,实际上大公司一般懒得来关注你)、品牌风险(这个一般对大公司中的创新者来说)等等。
        总的来说,最小化可行产品出来后,肯定要经受市场的测试,而对于创业者来说,则需要一套科学的方法来达到“认知”的目标,这说是“创新核算”



    No comments:

    Post a Comment

    Labels

    Review (554) System Design (293) System Design - Review (189) Java (178) Coding (75) Interview-System Design (65) Interview (60) Book Notes (59) Coding - Review (59) to-do (45) Knowledge (39) Linux (39) Interview-Java (35) Knowledge - Review (32) Database (30) Design Patterns (29) Product Architecture (28) Big Data (27) Soft Skills (27) Miscs (25) MultiThread (25) Concurrency (24) Cracking Code Interview (24) Career (22) Interview - Review (21) Java - Code (21) Operating System (21) Distributed (20) Interview Q&A (20) OOD Design (20) System Design - Practice (19) Security (17) Algorithm (15) How to Ace Interview (15) Brain Teaser (14) Google (13) Linux - Shell (13) Spark (13) Spring (13) Code Quality (12) How to (12) Interview-Database (12) Interview-Operating System (12) Redis (12) Tools (12) Architecture Principles (11) Company - LinkedIn (11) Testing (11) Resource (10) Solr (10) Amazon (9) Cache (9) Search (9) Web Dev (9) Architecture Model (8) Better Programmer (8) Company - Uber (8) Interview - MultiThread (8) Java67 (8) Math (8) OO Design principles (8) SOLID (8) Scalability (8) Cassandra (7) Git (7) Interview Corner (7) JVM (7) Java Basics (7) Machine Learning (7) NoSQL (7) C++ (6) Design (6) File System (6) Highscalability (6) How to Better (6) Kafka (6) Network (6) Restful (6) Trouble Shooting (6) CareerCup (5) Code Review (5) Company - Facebook (5) Hash (5) How to Interview (5) JDK Source Code (5) JavaScript (5) Leetcode (5) Must Known (5) Be Architect (4) Big Fata (4) C (4) Company Product Architecture (4) Data structures (4) Design Principles (4) Facebook (4) GeeksforGeeks (4) Generics (4) Google Interview (4) Hardware (4) JDK8 (4) Optimization (4) Product + Framework (4) Shopping System (4) Source Code (4) Web Service (4) node.js (4) Back-of-Envelope (3) Company - Pinterest (3) Company - Twiiter (3) Company - Twitter (3) Consistent Hash (3) GOF (3) Game Design (3) GeoHash (3) Growth (3) Guava (3) Interview-Big Data (3) Interview-Linux (3) Interview-Network (3) Java EE Patterns (3) Javarevisited (3) Map Reduce (3) Math - Probabilities (3) Performance (3) Puzzles (3) Python (3) Resource-System Desgin (3) Scala (3) UML (3) geeksquiz (3) AI (2) API Design (2) AngularJS (2) Behavior Question (2) Bugs (2) Coding Interview (2) Company - Netflix (2) Crawler (2) Cross Data Center (2) Data Structure Design (2) Database-Shard (2) Debugging (2) Docker (2) Elasticsearch (2) Garbage Collection (2) Go (2) Hadoop (2) Html (2) Interview - Soft Skills (2) Interview-Miscs (2) Interview-Web (2) JDK (2) Logging (2) POI (2) Papers (2) Programming (2) Project Practice (2) Random (2) Software Desgin (2) System Design - Feed (2) Thread Synchronization (2) Video (2) ZooKeeper (2) reddit (2) Ads (1) Advanced data structures (1) Algorithm - Review (1) Android (1) Approximate Algorithms (1) Base X (1) Bash (1) Books (1) C# (1) CSS (1) Chrome (1) Client-Side (1) Cloud (1) CodingHorror (1) Company - Yelp (1) Counter (1) DSL (1) Dead Lock (1) Difficult Puzzles (1) Distributed ALgorithm (1) Eclipse (1) Facebook Interview (1) Function Design (1) Functional (1) GoLang (1) How to Solve Problems (1) ID Generation (1) IO (1) Important (1) Internals (1) Interview - Dropbox (1) Interview - Project Experience (1) Interview Tips (1) Interview-Brain Teaser (1) Interview-How (1) Interview-Mics (1) Interview-Process (1) Jeff Dean (1) Joda (1) LeetCode - Review (1) Library (1) LinkedIn (1) LintCode (1) Mac (1) Micro-Services (1) Mini System (1) MySQL (1) Nigix (1) NonBlock (1) Process (1) Productivity (1) Program Output (1) Programcreek (1) Quora (1) RPC (1) Raft (1) RateLimiter (1) Reactive (1) Reading (1) Reading Code (1) Refactoring (1) Resource-Java (1) Resource-System Design (1) Resume (1) SQL (1) Sampling (1) Shuffle (1) Slide Window (1) Spotify (1) Stability (1) Storm (1) Summary (1) System Design - TODO (1) Tic Tac Toe (1) Time Management (1) Web Tools (1) algolist (1) corejavainterviewquestions (1) martin fowler (1) mitbbs (1)

    Popular Posts