This action might not be possible to undo. Are you sure you want to continue?
Overwhelming majority fail Chart of web 2.0 companies -‐> someone took it and put an X over all failures, and Os over successes (a lot of red ink… grim time for the industry) Collectively as an industry, we pour a lot of energy and resources into sector with terrible mortality rate It doesn’t have to be that way We can do better This talk is about how -‐> this talk is about alternate reality that we can reach, where mortality rate is different
Certainly not quality of ideas -‐> Favorite exemple: Microsoft, PayPal Successful companies achieved enough iterations to reach product/market fit Figured out how to match crazy vision with what reality would accomodate Evolution: ‘chip marble away from the statue’ -‐> our job as entrepreneur is to figure out which is the crazy delusion part from the elements of truth What is a startup? abandon the idea of ‘two guys in a garage’: folklore, focuses on side effects! A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty. Core characteristic: extreme uncertainty about what the future holds Core need of a startup: develop a methodology to learn about the future! A good plan? Start a company with a compelling long-‐term vision Raise plenty of capital Hire the absolute best and the brightest
But how do you know if you actually made progress? People fall back on ‘making the plan’
Back to ‘a good plan?’
What was the problem? How to make money? No! Super detailed business plan. Did actually work, people did pay for it. Didn’t ship before credit card integration etc. Just a failure compared to their expectation. New plan: IMVU Bad idea #1: Shipped in 6 months -‐ a horribly buggy beta product Concerns overblown: nobody ever tried it Bad idea #2: Charged people for it, from day one Even more, Metcalfe’s law was working against them! ‘We didn’t mind’ Bad idea #3: Shipped multiple times a day By 2008, on average 50 times a day Continous deployment. Fears: ‘what if it breaks!?’ ‘what if an engineer removes the Checkout button!?’ Bad idea #4: No PR, no launch Published everything on the website, even business model!! But had to become part of top 1000 websites before journalists were interested! Lean startups go faster 3 key ideas: Commodity technology stack Customer development Agile software development Commodity technology stack Product development leverage: for each ounce of effort you invest in your product, you take advanteg of the efforts of thsoudans or millons of other Drives costs down, but more important: impact on speed! Time to bring a new product to market is falling rapidly. Q: how about IP concerns? A: not the real value. Today, value is in data and customer relationship, not technology companies are defended by their business, not lawyers
Q: how to convince a customer to buy if there uncertain about solidity of your business? Wrong person to talk to: talk to early adopters, people that have an acute enough pain to engage in crazy activity. Early users are more visionary about product than you are! Q: you disclosed your business plan. Weren’t you afraid that big guys would copy you? Do you know how hard it is to pitch an idea to top manager at Yahoo? Steve Blank: ‘the only company that can put you out of business Actually had a buyout offer by a company who said ‘well, if you say no we’ll copy you and put you out of business’. Poached a co-‐founder and put him in charge of team designing . Luckily, had core in-‐competency. Spent two years building a product to the specs of what IMVU’s was 2 years ago – IMVU had already make mistakes. Customer development “Read the book” (literally!) http://bit.ly/tpTtE Agile development Traditional Product Development: Waterfall Unit of progress: Advance to Next Stage Works! Works extremely well for a lot of situations Important to understand what circumstances where it works Works well when predictable problem and solution Can build a model of the future. Dangerous for a startup: getting this reinforcement from advance Agile development Unit of progress: a line of working code: Any activity that does not contribute to building lines of code is eliminated Code that doesn’t work is a form of waste No code to anticipate future needs that we might not have No documentation that people never run, no specs that become stale, no tests that never get run
(!!!) Problem: known Solution: unknown In Extreme Programming (Eric’s favorite agile dev methodology), ‘domain expert’ is a customer that sits directly next to the software engineer. Product development at lean startup Unit of progress: validated learning about customers (!!!) Problem: unknown Solution: unknown Cross-‐functional Solution Team in direct contact with a Problem team -‐> break departmental barriers: “Startup dollhouse fallacy”: startup = small big company Tangible unit of progress: learning Best measure is revenue, but just a measure -‐> it’s all about knowledge! Revenue: try it There is a few special cases, but very few “You wouldn’t believe the number of entrepreneurs who come to me and tell me they are a special case” THE LEAN STARTUP The Lean Startup Heuristic ONE Heuristic to decide if any process is harmful or Minimize TOTAL time through the loop Three ‘fallacies’: Engineering fallacy: Data warehouse fallacy: MBA fallacy: there is one super fast way to iterate: do it at the whiteboard by yourself. Spend the day moving boxes around, then start again Idea is to minimize the TOTAL time, not suboptimize one aspect.
Q: doesn’t that mean you need a product to learn? Need to put a product out there, not necessarily a real one. However, wary of this idea cf. MBA fallacy. Minimum viable product Can’t talk too much, go see the blog. I can say with confidence that many of you have a way too big idea of what is minimum. Heuristic: pare features down until you feel uncomfortable. Then you are within 50% of target. Techno for agile: continuous deployment Deploy new software quickly At IMVU time from check-‐in to production: 20 minutes During this time, does a battery of test. First test on sandbox, then run battery of tests, and then do incremental deployment: first on a few systems, then if works on the full cluster. If fails, receive an email, then all your coworkers as well, then commit cycle is broken. Tell a good change from a bad change (quickly) Revert a bad change quickly Work in small batches At IMVU, a large batch = 3 days worth of work Cluster Immune System Run tests locally (SimpleTest, Selenium Continuous Intergation Server (BuildBot) Incremental deploy One server at a time, while monitoring Alerting and predictive maonitoring (Nagios) When customers see a failure: Committed to the idea that we could have any issue, once Then have to learn from that mistake as much as possible Whatever is in the HEAD of the SCM is production!!!!
Split testing all the time Make it really easy: one line of code AAA’s of Metrics Actionable Has to give people Accessible Has to be easy to deploy Auditable Has to be able to convince used to kill people’s features Measure the macro Always look at cohort-‐based metrics over time Split-‐test the small, measure the large -‐> idea is to do split-‐tests for small features, but to measure the impact on the large stuff! Not the small stuff. E.g. final revenue, not click-‐through of that one button. Q: how about first impression? Don’t you risk turning users away? Well, you better fail at the beginning Any mistake, you want to make it now! Not later. Every day increases the risk of feature failure. Q: ‘fail early, fail often’ doesn’t work today! Paradox: if you’re succeeding on a regular basis, you’re not taking risks, so you’re not creating innovation. The goal is to learn as much as you can from each failure, so you will. If you say ‘my goal is to be right every time’, you won’t take enough chances. Five whys root cause analysis 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. There’s much more… … read the blog! Q: differences between teams? No! Exact same team! Failure is important. People who have gone to success to success are not open. People who have tried the traditional way and failed are the most open.