The document discusses myths and truths about Lean Startups. It dispels four common myths: that Lean means cheap, that it only applies to web/internet companies, that Lean Startups are small, and that they replace vision with data. It then provides an overview of Lean Startup principles like building a Minimum Viable Product, conducting rapid split tests, and achieving continuous deployment through small, frequent code releases.

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

2. Myth #1 Myth Lean means cheap. Lean startups try tospend as little money as possible. Truth The Lean Startup method is not about cost,it is about speed.

3. Myth #2 Myth The Lean Startup is only forWeb 2.0/internet/consumer software companies. Truth The Lean Startup applies to all companies that face uncertainty about what customers will want.

4. Myth #3 Myth Lean Startups are small bootstrapped startups. Truth Lean Startups are ambitious and are able to deploy large amounts of capital.

5. Myth #4 Myth Lean Startups replace vision with dataor customer feedback. Truth Lean Startups are driven by a compelling vision, and are rigorous about testing each element of this vision

8. Most Startups Fail

9. Most Startups Fail

11. We can do better.

15. They started out as digital cash for PDAs, but evolved into online payments for eBay.

16. They started building BASIC interpreters, but evolved into the world's largest operating systems monopoly.

17. They were shocked to discover their online games company was actually a photo-sharing site.

19. A Tale of Two Startups

20. Startup 1

21. Stealth Startup Circa 2001

22. All about the team

24. Raise plenty of capital.

25. Hire the absolute best and the brightest.

26. Hire an experienced management team with tons of startup experience.

27. Focus on quality.

28. Build a world-class technology platform.

31. Raise plenty of capital.

32. Hire the absolute best and the brightest.

33. Hire an experienced management team with tons of startup experience.

34. Focus on quality.

35. Build a world-class technology platform.

37. IMVU

38. IMVU

40. Charged from day one

41. Shipped multiple times a day (by 2008, on average 50 times a day)

42. No PR, no launch

44. In traditional business, value is created by delivering products or services to customers

45. In a startup, the product and customer are unknowns

47. Agile Product DevelopmentUnit of Progress: A line of Working Code “Product Owner” or in-house customer Problem: known Solution:unknown

48. Product Development at Lean StartupUnit of Progress: Validated Learning About Customers ($$$) Hypotheses, Experiments, Insights Problem:unknown Data, Feedback, Insights Solution:unknown

49. Minimize TOTAL time through the loop

50. There’s much more… Build Faster Unit Tests Usability Tests Continuous Integration Incremental Deployment Free & Open-Source Components Cloud Computing Cluster Immune System Just-in-time Scalability Refactoring Developer Sandbox Minimum Viable Product Learn Faster Split Tests Customer Interviews Customer Development Five Whys Root Cause Analysis Customer Advisory Board Falsifiable Hypotheses Product Owner Accountability Customer Archetypes Cross-functional Teams Semi-autonomous Teams Smoke Tests Measure Faster Funnel Analysis Cohort Analysis Net Promoter Score Search Engine Marketing Real-Time Alerting Predictive Monitoring Measure Faster Split Tests Clear Product Owner Continuous Deployment Usability Tests Real-time Monitoring Customer Liaison

52. http://StartupLessonsLearned.com

53. In print: http://bit.ly/SLLbookbeta

54. Getting in touch (#leanstartup)

55. http://twitter.com/ericries

56. eric@theleanstartup.com

59. Minimum viable product

60. Five why’s

61. Rapid split-tests

64. Get lots of them signed up

65. Make a lot of money

66. Realize a big vision; change the world

68. build a great product with enough features that increase the odds that customers will want it

69. Problem: no feedback until the end, might be too late to adjust

70. “Release early, release often”

71. Get as much feedback as possible, as soon as possible

73. Avoid building products that nobody wants

74. Maximize the learning per dollar spent

76. Allows us to achieve a big vision in small increments without going in circles

77. Requires a commitment to iteration

79. SEM on five dollars a day

80. In-product split testing

81. Paper prototypes

82. Customer discovery/validation

84. Visionary complex: “but customers don’t know what they want!”

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

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

91. Has to be simple enough for everyone to use and understand it

92. Make 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 }

94. Accessible

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

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

100. Revert a bad change quickly

101. And “shut down the line”

102. Work in small batches

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

105. Everyone has a complete sandbox

106. Continuous Integration Server (BuildBot)

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

108. Automatic feedback if the team is going too fast

109. Incremental deploy

110. Monitor cluster and business metrics in real-time

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

112. Alerting & Predictive monitoring (Nagios)

113. Monitor all metrics that stakeholders care about

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

115. Use historical trends to predict acceptable bounds

116. When customers see a failure

117. Fix the problem for customers

118. Improve your defenses at each level