This document summarizes the key principles of the Lean Startup methodology for building startups with a high chance of success. It discusses how traditional management practices fail for startups due to extreme uncertainty, and promotes an approach of continuous learning through building minimum viable products and customer feedback. Specific Lean Startup techniques mentioned include continuous deployment, the five whys problem-solving method, and running frequent A/B tests to rapidly validate hypotheses about what customers want.

1. The Lean Startup#leanstartupEric Ries (@ericries)http://StartupLessonsLearned.com

2. Entrepreneurship = AwesomeIt is the best time in the history of the world to be an entrepreneurCosts are falling in all industriesBarriers are being destroyedDisruption and chaos are everywhere

3. Why build a startup?Only entrepreneurship combines these three elementsChange the worldBuild an organization of lasting valueMake customers’ lives better

4. Most Startups Fail

5. Most Startups Fail

6. Most Startups Fail

7. Most Startups FailBut it doesn’t have to be that way. We can do better. This talk is about how.

8. What is a startup?A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty. Nothing to do with size of company, sector of the economy, or industry

9. Entrepreneurship is managementOur goal is to create an institution, not just a productTraditional management practices fail “general management” as taught to MBAsNeed practices and principles geared to the startup context of extreme uncertaintyNot just for “two guys in a garage”

10. The PivotWhat do successful startups have in common?They started out as digital cash for PDAs, but evolved into online payments for eBay. They started building BASIC interpreters, but evolved into the world's largest operating systems monopoly. They were shocked to discover their online games company was actually a photo-sharing site.Pivot: change directions but stay grounded in what we’ve learned. http://startuplessonslearned.blogspot.com/2009/06/pivot-dont-jump-to-new-vision.html

11. Speed Winsif we can reduce the time between major iterationswe can increase our odds of success

12. A Tale of Two Startups

13. Startup #1

14. Stealth Startup Circa 2001

15. All about the team

16. A good plan?Start a company with a compelling long-term vision. Raise plenty of capital.Hire the absolute best and the brightest.Hire an experienced management team with tons of startup experience.Focus on quality. Build a world-class technology platform.Build buzz in the press and blogosphere.

17. Achieving FailureCompany failed* $40MM and five years of painCrippled by “shadow beliefs” that destroyed the effort of all those smart people.

18. Shadow Belief #1We know what customers want.

19. Shadow Belief #2We can accurately predict the future.

20. Shadow Belief #3Advancing the plan is progress.

21. A good plan?Start a company with a compelling long-term vision. Raise plenty of capital.Hire the absolute best and the brightest.Hire an experienced management team with tons of startup experience.Focus on quality. Build a world-class technology platform.Build buzz in the press and blogosphere.

22. Startup #2

23. IMVU

24. IMVU

25. New planShipped in six months – a horribly buggy beta productCharged from day oneShipped multiple times a day (by 2008, on average 50 times a day)No PR, no launchResults 2009: profitable, revenue > $20MM

26. Making ProgressIn a lean transformation, question #1 is – which activities are value-creating and which are waste?In traditional business, value is created by delivering products or services to customersIn a startup, the product and customer are unknownsWe need a new definition of value for startups

27. Traditional Product DevelopmentUnit of Progress: Advance to Next StageWaterfallRequirementsSpecificationDesignProblem: knownSolution: knownImplementationVerificationMaintenance

28. Agile Product DevelopmentUnit of Progress: A line of Working Code“Product Owner” or in-house customerProblem: knownSolution: unknown

29. Product Development at Lean StartupUnit of Progress: Validated Learning About Customers ($$$)Customer DevelopmentHypotheses,Experiments,InsightsProblem: unknownData,Feedback,InsightsSolution: unknown

30. Minimize TOTAL time through the loopIDEASLEARNBUILDDATACODEMEASURE

31. How to build a Lean StartupLet’s talk about some specifics. Continuous deploymentFive why’s

32. Continuous DeploymentIDEASLEARNBUILDLearn FasterCustomer DevelopmentFive WhysBuild FasterContinuous DeploymentSmall BatchesContinuous IntegrationRefactoringDATACODEMEASUREMeasure FasterSplit TestingActionable MetricsNet Promoter ScoreSEM

33. Continuous DeploymentDeploy new software quickly

34. At IMVU time from check-in to production = 20 minutes

35. Tell a good change from a bad change (quickly)

36. Revert a bad change quickly

37. And “shut down the line”

38. Work in small batches

39. At IMVU, a large batch = 3 days worth of work

40. Break large projects down into small batchesCluster Immune SystemWhat it looks like to ship one piece of code to production:Run tests locally (SimpleTest, Selenium)

41. Everyone has a complete sandbox

42. Continuous Integration Server (BuildBot)

43. All tests must pass or “shut down the line”

44. Automatic feedback if the team is going too fast

45. Incremental deploy

46. Monitor cluster and business metrics in real-time

47. Reject changes that move metrics out-of-bounds

48. Alerting & Predictive monitoring (Nagios)

49. Monitor all metrics that stakeholders care about

50. If any metric goes out-of-bounds, wake somebody up

51. Use historical trends to predict acceptable boundsWhen customers see a failure:Fix the problem for customers

52. Improve your defenses at each levelFive WhysIDEASCode FasterLearn FasterBUILDLEARNContinuousDeploymentFive Whys RootCause AnalysisCODEDATAMeasure FasterMEASURERapid Split Tests

53. Five Whys Root Cause AnalysisA technique for continuous improvement of company process.

54. Ask “why” five times when something unexpected happens.

55. Make proportional investments in prevention at all five levels of the hierarchy.

56. Behind every supposed technical problem is usually a human problem. Fix the cause, not just the symptom.There’s much more…IDEASCode FasterLearn FasterBUILDLEARNUnit TestsUsability TestsContinuous IntegrationIncremental DeploymentFree & Open-Source ComponentsCloud ComputingCluster Immune SystemJust-in-time ScalabilityRefactoringDeveloper SandboxMinimum Viable ProductSplit TestsCustomer InterviewsCustomer DevelopmentFive Whys Root Cause AnalysisCustomer Advisory BoardFalsifiable HypothesesProduct Owner AccountabilityCustomer ArchetypesCross-functional TeamsSemi-autonomous TeamsSmoke TestsCODEDATAMeasure FasterMEASURESplit TestsClear Product OwnerContinuous DeploymentUsability TestsReal-time MonitoringCustomer LiaisonFunnel AnalysisCohort AnalysisNet Promoter ScoreSearch Engine MarketingReal-Time AlertingPredictive Monitoring

57. Get Started TodayYou are ready to do this, no matter who you arewhat job you havewhat stage of company you’re inGet started now, today.

58. Thanks!Startup Lessons Learned Blog

59. http://StartupLessonsLearned.com/

60. In print: http://bit.ly/SLLbookbeta & at the Webstock booth

61. Getting in touch (#leanstartup)

62. http://twitter.com/ericries

63. eric@theleanstartup.com

64. Lean Startup Wellington Meetuphttp://www.meetup.com/Lean-Startup-Wellington/@davemosk @joshuavial @maximonos @andrewfantastic

65. Lean Startup Wikihttp://leanstartup.pbworks.com/Rapid Split TestsIDEASCode FasterLearn FasterBUILDLEARNContinuousDeploymentFive Whys RootCause AnalysisCODEDATAMeasure FasterMEASURERapid Split Tests

66. Split-testing all the timeA/B testing is key to validating your hypothesesHas to be simple enough for everyone to use and understand itMake creating a split-test no more than one line of code:if( setup_experiment(...) == "control" ) { // do it the old way} else { // do it the new way}

67. The AAA’s of MetricsActionableAccessibleAuditable

68. Measure the MacroAlways look at cohort-based metrics over timeSplit-test the small, measure the large