David Cancel, Performable
Seu SlideShare está sendo baixado.
×
Confira estes a seguir
Recomendadas
Mais Conteúdo rRelacionado
Diapositivos para si (20)
Semelhante a 2010 03 09 the lean startup - gdc (20)
Mais de Eric Ries (20)
Mais recentes (20)
2010 03 09 the lean startup - gdc
- Building a Virtual World: Lean Startup Style<br />#leanstartup<br />Eric Ries (@ericries)<br />http://StartupLessonsLearned.com<br />
- In Memoriam<br />
- Entrepreneurship = Awesome<br />It is the best time in the history of the world to be an entrepreneur<br />Costs are falling in all industries<br />Barriers are being destroyed<br />Disruption and chaos are everywhere<br />
- Why build a startup?<br />Only entrepreneurship combines these three elements<br />Change the world<br />Build an organization of lasting value<br />Make customers’ lives better<br />
- Most Startups Fail<br />
- Most Startups Fail<br />
- Most Startups Fail<br />
- Most Startups Fail<br />But it doesn’t have to be that way. <br />We can do better. <br />This talk is about how.<br />
- What is a startup?<br />A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty. <br />Nothing to do with size of company, sector of the economy, or industry<br />
- Entrepreneurship is management<br />Our goal is to create an institution, not just a product<br />Traditional management practices fail<br /> “general management” as taught to MBAs<br />Need practices and principles geared to the startup context of extreme uncertainty<br />Not just for “two guys in a garage”<br />
- The Pivot<br />What do successful startups have in common?<br />They started out as digital cash for PDAs, but evolved into online payments for eBay. <br />They started building BASIC interpreters, but evolved into the world's largest operating systems monopoly. <br />They were shocked to discover their online games company was actually a photo-sharing site.<br />Pivot: change directions but stay grounded in what we’ve learned. <br />http://startuplessonslearned.blogspot.com/2009/06/pivot-dont-jump-to-new-vision.html<br />
- Speed Wins<br />if we can reduce the time between major iterations<br />we can increase our odds of success<br />
- A Tale of Two Startups<br />
- Startup #1<br />
- Stealth Startup Circa 2001<br />
- All about the team<br />
- A good plan?<br />Start a company with a compelling long-term vision. <br />Raise plenty of capital.<br />Hire the absolute best and the brightest.<br />Hire an experienced management team with tons of startup experience.<br />Focus on quality. <br />Build a world-class technology platform.<br />Build buzz in the press and blogosphere.<br />
- Achieving Failure<br />Company failed <br />$40MM and five years of pain<br />Crippled by “shadow beliefs” that destroyed the effort of all those smart people.<br />
- Shadow Belief #1<br />We know what customers want. <br />
- Shadow Belief #2<br />We can accurately predict the future. <br />
- Shadow Belief #3<br />Advancing the plan is progress. <br />
- A good plan?<br />Start a company with a compelling long-term vision. <br />Raise plenty of capital.<br />Hire the absolute best and the brightest.<br />Hire an experienced management team with tons of startup experience.<br />Focus on quality. <br />Build a world-class technology platform.<br />Build buzz in the press and blogosphere.<br />
- Startup #2<br />
- IMVU<br /> <br />
- IMVU<br /> <br />
- New plan<br />Shipped in six months – a horribly buggy beta product<br />Charged from day one<br />Shipped multiple times a day (by 2008, on average 50 times a day)<br />No PR, no launch<br />Results 2009: profitable, revenue > $20MM<br />
- Making Progress<br />In a lean transformation, question #1 is – which activities are value-creating and which are waste?<br />In traditional business, value is created by delivering products or services to customers<br />In a startup, the product and customer are unknowns<br />We need a new definition of value for startups<br />
- Traditional Product Development<br />Unit of Progress: Advance to Next Stage<br />Waterfall<br />Requirements<br />Specification<br />Design<br />Problem: known<br />Solution: known<br />Implementation<br />Verification<br />Maintenance<br />
- Agile Product Development<br />Unit of Progress: A line of Working Code<br />“Product Owner” or in-house customer<br />Problem: known<br />Solution: unknown<br />
- Product Development at Lean Startup<br />Unit of Progress: Validated Learning About Customers ($$$)<br />Customer Development<br />Hypotheses,<br />Experiments,<br />Insights<br />Problem: unknown<br />Data,<br />Feedback,<br />Insights<br />Solution: unknown<br />
- Minimize TOTAL time through the loop<br />IDEAS<br />LEARN<br />BUILD<br />DATA<br />CODE<br />MEASURE<br />
- How to build a Lean Startup<br />Let’s talk about some specifics. <br />Minimum viable product<br />Five why’s <br />
- Minimum Viable Product<br />IDEAS<br />LEARN<br />BUILD<br />Learn Faster<br />Customer Development<br />Five Whys<br />Build Faster<br />Continuous Deployment<br />Small Batches<br />Minimum Viable Product<br />Refactoring<br />DATA<br />CODE<br />MEASURE<br />Measure Faster<br />Split Testing<br />Actionable Metrics<br />Net Promoter Score<br />SEM <br />
- Why do we build products?<br />Delight customers<br />Get lots of them signed up<br />Make a lot of money<br />Realize a big vision; change the world<br />Learn to predict the future<br />
- Possible Approaches<br />“Maximize chances of success”<br />build a great product with enough features that increase the odds that customers will want it<br />Problem: no feedback until the end, might be too late to adjust<br /> “Release early, release often”<br />Get as much feedback as possible, as soon as possible<br />Problem: run around in circles, chasing what customers think they want<br />
- Minimum Viable Product<br />The minimum set of features needed to learn from earlyvangelists – visionary early adopters<br />Avoid building products that nobody wants<br />Maximize the learning per dollar spent<br />Probably much more minimum than you think!<br />
- Minimum Viable Product<br />Visionary customers can “fill in the gaps” on missing features, if the product solves a real problem<br />Allows us to achieve a big vision in small increments without going in circles<br />Requires a commitment to iteration<br />MVP is only for BIG VISION products; unnecessary for minimal products.<br />
- Techniques<br />Smoke testing with landing pages, AdWords<br />SEM on five dollars a day<br />In-product split testing<br />Paper prototypes<br />Customer discovery/validation<br />Removing features (“cut and paste”)<br />
- Fears<br />False negative: “customers would have liked the full product, but the MVP sucks, so we abandoned the vision”<br />Visionary complex: “but customers don’t know what they want!”<br />Too busy to learn: “it would be faster to just build it right, all this measuring distracts from delighting customers”<br />
- Five Whys<br />IDEAS<br />Code Faster<br />Learn Faster<br />BUILD<br />LEARN<br />Continuous<br />Deployment<br />Five Whys Root<br />Cause Analysis<br />CODE<br />DATA<br />Measure Faster<br />MEASURE<br />Rapid Split Tests<br />
- Five Whys Root Cause Analysis<br /><ul><li>A technique for continuous improvement of company process.
- Ask “why” five times when something unexpected happens.
- Make proportional investments in prevention at all five levels of the hierarchy.
- Behind every supposed technical problem is usually a human problem. Fix the cause, not just the symptom.</li></li></ul><li>There’s much more…<br />IDEAS<br />Code Faster<br />Learn Faster<br />BUILD<br />LEARN<br />Unit Tests<br />Usability Tests<br />Continuous Integration<br />Incremental Deployment<br />Free & Open-Source Components<br />Cloud Computing<br />Cluster Immune System<br />Just-in-time Scalability<br />Refactoring<br />Developer Sandbox<br />Minimum Viable Product<br />Split Tests<br />Customer Interviews<br />Customer Development<br />Five Whys Root Cause Analysis<br />Customer Advisory Board<br />Falsifiable Hypotheses<br />Product Owner Accountability<br />Customer Archetypes<br />Cross-functional Teams<br />Semi-autonomous Teams<br />Smoke Tests<br />CODE<br />DATA<br />Measure Faster<br />MEASURE<br />Split Tests<br />Clear Product Owner<br />Continuous Deployment<br />Usability Tests<br />Real-time Monitoring<br />Customer Liaison<br />Funnel Analysis<br />Cohort Analysis<br />Net Promoter Score<br />Search Engine Marketing<br />Real-Time Alerting<br />Predictive Monitoring<br />
- Get Started Today<br />You are ready to do this, no matter <br />who you are<br />what job you have<br />what stage of company you’re in<br />Get started now, today. <br />
- Thanks!<br /><ul><li>Startup Lessons Learned Blog
- http://StartupLessonsLearned.com/
- In print: http://bit.ly/SLLbookbeta
- Getting in touch (#leanstartup)
- http://twitter.com/ericries
- eric@theleanstartup.com
- Startup Lessons Learned Conference</li></ul> April 23, 2010 in San Franciscohttp://sllconf.com<br />
- Rapid Split Tests<br />IDEAS<br />Code Faster<br />Learn Faster<br />BUILD<br />LEARN<br />Continuous<br />Deployment<br />Five Whys Root<br />Cause Analysis<br />CODE<br />DATA<br />Measure Faster<br />MEASURE<br />Rapid Split Tests<br />
- Split-testing all the time<br />A/B testing is key to validating your hypotheses<br />Has to be simple enough for everyone to use and understand it<br />Make creating a split-test no more than one line of code:<br />if( setup_experiment(...) == "control" ) {<br /> // do it the old way<br />} else {<br /> // do it the new way<br />}<br />
- The AAA’s of Metrics<br />Actionable<br />Accessible<br />Auditable<br />
- Measure the Macro<br />Always look at cohort-based metrics over time<br />Split-test the small, measure the large<br />
- Continuous Deployment<br />IDEAS<br />LEARN<br />BUILD<br />Learn Faster<br />Customer Development<br />Five Whys<br />Build Faster<br />Continuous Deployment<br />Small Batches<br />Continuous Integration<br />Refactoring<br />DATA<br />CODE<br />MEASURE<br />Measure Faster<br />Split Testing<br />Actionable Metrics<br />Net Promoter Score<br />SEM <br />
- Continuous Deployment<br /><ul><li>Deploy new software quickly
- At IMVU time from check-in to production = 20 minutes
- Tell a good change from a bad change (quickly)
- Revert a bad change quickly
- And “shut down the line”
- Work in small batches
- At IMVU, a large batch = 3 days worth of work
- Break large projects down into small batches</li></li></ul><li>Cluster Immune System<br />What it looks like to ship one piece of code to production:<br /><ul><li>Run tests locally (SimpleTest, Selenium)
- Everyone has a complete sandbox
- Continuous Integration Server (BuildBot)
- All tests must pass or “shut down the line”
- Automatic feedback if the team is going too fast
- Incremental deploy
- Monitor cluster and business metrics in real-time
- Reject changes that move metrics out-of-bounds
- Alerting & Predictive monitoring (Nagios)
- Monitor all metrics that stakeholders care about
- If any metric goes out-of-bounds, wake somebody up
- Use historical trends to predict acceptable bounds</li></ul>When customers see a failure:<br /><ul><li>Fix the problem for customers
- Improve your defenses at each level</li>
