The Lean Startup Eric Ries Audio summary. About 68 minutes read aloud at normal speed. ------------------------------------------------------------ Before we begin This is a full-length summary of Eric Ries's The Lean Startup, published in twenty-eleven. Ries was a co-founder and chief technology officer of IMVU, an online avatar and instant-messaging company, and most of the book's hard lessons come from his own failures there rather than from other people's successes. That matters, because the book's tone is confessional rather than triumphant. The central argument is easy to state and hard to accept. Entrepreneurship is management. A startup is not a smaller version of a large company, and it is not a lone genius in a garage waiting for a flash of insight. It is an institution, and it needs a discipline of its own, because the ordinary tools of management assume a stable operating history that a startup does not have. The discipline Ries proposes borrows from lean manufacturing, and from the scientific method. His definition of a startup is deliberately broad: a human institution designed to create a new product or service under conditions of extreme uncertainty. Notice what is absent. Nothing about company size, industry, or sector. If you are building something new and you genuinely do not know whether it will work, you are running a startup, whether you sit in a garage or in a division of a large company. That definition is what lets the book apply to a product organisation inside an established business. The book has three parts. Vision covers what a startup is and what it is for. Steer covers one full turn of the core feedback loop. Accelerate covers how to go faster without falling apart. And it rests on five principles, stated at the outset. Entrepreneurs are everywhere. Entrepreneurship is management. Startups exist to learn how to build a sustainable business, and that learning can be validated scientifically. The core activity of a startup is to turn ideas into products, measure how customers respond, and then learn whether to pivot or persevere. And all of this has to be held accountable by a new kind of accounting, which he calls innovation accounting. ------------------------------------------------------------ Part One. Vision The problem the book is trying to solve Ries opens with a diagnosis of why startups fail, and it is not the one you expect. The obvious explanation is that the good plan, the solid strategy and the thorough market research are missing. Startup people know that story: it says that failure comes from a lack of rigour, and the cure is more planning. But the opposite explanation is at least as common. Planning and forecasting are only accurate when based on a long, stable operating history and a reasonably static environment. Startups have neither. So the elaborate business plan, executed with discipline, produces a beautifully built product that nobody wants. Ries's phrase for this is "achieving failure": successfully executing a plan that led nowhere. He calls the alternative to planning the "just do it" school, which throws out process altogether and relies on chaos and hustle. That fails too, just faster. His argument is that we lack a management paradigm for new ventures, and that the resulting waste is enormous — not just economic damage to employees and investors, but the waste of people's time, passion and skill on products that will be used by nobody. The lean manufacturing analogy is the key move. Taiichi Ohno and Shigeo Shingo at Toyota taught the world the difference between value-creating activity and waste, and how to shrink batch sizes, use just-in-time production, and accelerate cycle times. But you have to translate carefully. In manufacturing, value is a product delivered to a customer, and anything else is waste. In a startup, we do not yet know who the customer is or what they would find valuable. So Ries redefines value for the startup context: value is validated learning about how to build a sustainable business. Anything that does not contribute to that learning is waste. That single redefinition drives everything else in the book. Entrepreneurs are everywhere Ries's opening example is deliberately unromantic: an internal team at Intuit that built SnapTax, a product that lets you photograph a tax form with your phone and file from it. It came out of a large, established, publicly listed company. It behaved like a startup: a small cross-functional team, an early limited release, rapid iteration based on how real people used it. The point of the example is Intuit's founder Scott Cook, who in nineteen eighty-three had validated his idea for Quicken by calling people at random and asking whether they found paying bills by hand frustrating. Ries argues that the strategic challenge for large companies is to do what Cook did in nineteen eighty-three, but on an industrial scale and with a body of managers steeped in traditional management culture. His view is that the period a company can count on holding market leadership is shrinking, which makes an internal "innovation factory" not a luxury but the only sustainable path to long-term growth. Validated learning, and the failure that produced it The heart of part one is Ries's account of IMVU's first year, and it is the most useful failure story in the book. The plan was clever. IMVU would build a three-dimensional avatar chat product, but rather than asking people to adopt a new network — a nearly impossible thing to do — it would build an add-on that plugged into every existing instant messaging network. Users could keep their existing friends and simply add avatars. The engineering to interoperate with all those networks was hard and took months. Ries wrote most of it. They shipped a product that was, by his own account, embarrassing: buggy, incomplete, badly designed. He was mortified. And then nobody used it. Not because of the bugs. Customers refused even to try it. The team went out and talked to teenagers. What they heard destroyed the strategy. Customers did not want to use avatars with their existing friends; they were perfectly happy with their existing instant messaging. What they wanted was to use the product to make new friends. The entire interoperability layer — the hardest, most expensive work, the thing that made the strategy distinctive — was irrelevant. Months of Ries's own code went in the bin. The lesson he draws is not "listen to customers." It is subtler and more uncomfortable. All that work was waste, and the tragedy is that they could have learned it in weeks rather than months, at a fraction of the cost, if they had asked what they most needed to learn and designed the smallest possible thing to learn it. This gives him his central concept: validated learning. Learning is the oldest excuse in business — every failed project claims that at least we learned a lot. Ries's response is that learning only counts if it is demonstrated by real improvement in the drivers of your business model, and if it was obtained faster and more cheaply than the alternative. If you cannot show the data, you did not learn; you rationalised. He then poses the question that reframes everything: if the goal of a startup is to learn what customers want, how much of the effort we are putting in is contributing to that? Look at your team's last month of work and ask which activities created validated learning and which were simply the execution of a plan formed before anyone knew anything. Experiment The consequence is that a startup's work should be structured as experiments, not as projects. A startup experiment is not merely a theoretical enquiry: it is a first product. It begins with a clear hypothesis about what is predicted to happen, and it tests that prediction empirically. The technique Ries recommends is to break the grand vision into component parts. The two most important assumptions any entrepreneur makes are the value hypothesis — does this product actually deliver value to customers once they are using it? — and the growth hypothesis — how will new customers discover it? He gives three worked examples of experiments run as products. The first is a large consumer products company with a volunteer programme that was underperforming. Rather than launching a redesigned programme company-wide, the recommended experiment was to run a small version with a handful of employees and measure whether they volunteered again. Ten early adopters is enough. If all ten decline to volunteer again, that is a highly significant and very negative result, and unlike survey research you already have a cohort of real people to talk to about why. The second is Zappos. Nick Swinmurn wanted to test whether people would buy shoes online. Rather than building warehouses and inventory systems, he photographed shoes in existing shoe shops, posted the pictures, and when someone ordered a pair, went and bought them at full price and shipped them. He was not testing demand in the abstract; he was testing real purchase behaviour, and in the process learning about returns, customer support and what customers actually asked for. The third is a village laundry service in India, run by Hindustan Unilever, where the experiment was a truck with a washing machine parked in a village — a service, not a product, priced per garment — designed to test whether people would pay for laundry at all before anyone built anything. The pattern in each: identify the riskiest assumption, and design the smallest thing that produces real behavioural data about it. ------------------------------------------------------------ Part Two. Steer Part two walks through one complete turn of the Build-Measure-Learn loop, and it is the operational core of the book. The loop is written Build, Measure, Learn because that is the order in which the activities happen. But Ries insists that planning runs in reverse. Figure out what you need to learn. Use innovation accounting to work out what you would need to measure to know whether you are learning it. Then work out the smallest product you need to build to get that measurement. Teams that plan forwards build a lot and learn very little. The goal is to minimise the total time through the loop. Not to optimise any one stage. This is the discipline that most product organisations get wrong: engineering optimises build time, analytics optimises measurement, and the whole loop stays slow. Leap-of-faith assumptions Ries calls the riskiest elements of a startup's plan — the parts on which everything depends — leap-of-faith assumptions. The two most important are always the value hypothesis and the growth hypothesis. His illustration is Facebook in two thousand and four, at the point when investors were unimpressed because it had no revenue and few users. Two facts should have been startling. First, more than half of the people who had signed up came back to the site every single day. That is about as strong a validation of a value hypothesis as exists. Second, the rate of growth: launched on the fourth of February, and by the end of that month roughly three-quarters of Harvard's undergraduates were using it, with no marketing spend at all. That validated the growth hypothesis. He also notes a warning. Some businesses are wildly profitable in the short term but value-destroying — Ponzi schemes, and companies like Enron. He uses the phrase "success theatre" for the practice of using the appearance of growth to seem successful, and says one of the purposes of innovation accounting is to make success theatre impossible. Then comes a principle he takes directly from Toyota: genchi gembutsu, usually translated as "go and see for yourself." Strategic decisions should be based on firsthand understanding of customers. When Toyota's chief engineer for the Sienna minivan was redesigning it, he drove more than fifty thousand miles across North America — every state, every Canadian province, Mexico — because the minivan is bought and used differently there than anywhere else. Insights like sliding doors on both sides and interiors designed for eating in the car came from being there, not from research summaries. But Ries adds an honest caveat. Genchi gembutsu is easier when you know who your customers are. Entrepreneurs face higher uncertainty than a company doing sustaining innovation, so early customer contact is about confirming that your leap-of-faith questions are grounded in reality — that the problem is real and significant enough to be worth solving — not about asking customers what to build. He is emphatic on that last point. Customers do not know what they want. What they can tell you is what frustrates them today. The minimum viable product The MVP is the most misused idea in the book, so Ries's actual definition is worth stating carefully: the MVP is that version of the product which enables a full turn of the Build-Measure-Learn loop with the minimum amount of effort and the least development time. Two things follow. First, the goal is to begin the process of learning, not to end it — the MVP is not a first release you then polish, it is an instrument. Second, unlike a prototype or a concept test, an MVP is designed to answer business hypotheses, not just design or technical questions. Which means, awkwardly, that building one sometimes requires extra work, because you must be able to measure its impact. A prototype evaluated internally by engineers and designers is not an MVP. His rule of thumb: most entrepreneurs and product people dramatically overestimate how many features are needed. When in doubt, simplify. And the sharper formulation: any additional work beyond what is required to start learning is waste, no matter how important it might have seemed at the time. He gives a taxonomy of techniques. The video MVP. Dropbox's leap-of-faith question was whether people would try a superior file synchronisation experience — a problem most people did not know they had. Building the product required deep operating system work across platforms. So Drew Houston made a three-minute video demonstrating the product as though it existed, aimed at an early-adopter audience who would recognise the in-jokes. Overnight, the beta waiting list went from five thousand to seventy-five thousand people. The video was the MVP, and it validated the assumption not because people said they liked it in a focus group but because they actually signed up. The concierge MVP. Food on the Table, a company that plans meals and generates shopping lists from what is on sale at your local store, began with exactly one customer. The chief executive and the vice-president of product visited her personally each week, reviewed what was on sale at her preferred shop, selected recipes to her taste, learned her family's favourite dishes, hand-delivered a packet of shopping list and recipes, collected her feedback — and collected a cheque for nine dollars ninety-five. Then a second customer, and a third, each getting the same treatment, until the overhead forced them to automate one piece at a time. Ries stresses the distinction between this and a small business where the founder simply serves customers directly. In a concierge MVP, the personalised service is not the product. It is a learning activity designed to test the leap-of-faith assumptions in the growth model. A common and valuable outcome is that it invalidates the growth model — even when the manual version is profitable. Without a growth model, many companies get trapped being satisfied with a small profitable business when a pivot might lead somewhere much larger. The Wizard of Oz MVP. At Aardvark, a social search product, the founders repeatedly refused to solve hard technical problems in the early stages. Instead, customers believed they were interacting with a working product while human beings did the work behind the scenes. A service where people ask questions of human researchers for free and get real-time answers would lose money at scale, but it is easy to build at micro scale, and it answers the only question that matters early: if we solved the hard technical problems, would people use this, and would their use create real value? On quality and design, Ries is careful, because this is where the MVP idea gets abused. His position is that a low-quality MVP can serve the building of a great high-quality product, because if customers perceive it as low quality, that is an opportunity to learn which attributes they care about — infinitely better than whiteboard speculation. His own example is IMVU's avatars, which initially could not walk. The industry standard was fluid movement with obstacle avoidance, and building it was expensive. Instead they made avatars teleport instantly to wherever the customer clicked. No walking, no animation, not even a decent teleport effect. They felt terrible shipping it. Customers loved it — it turned out to be more convenient than watching an avatar walk — and it became a signature feature. The lesson is not that quality does not matter. It is that you must always ask: what if they do not care about this in the way we do? He then addresses the objections he hears most. On patents: in some jurisdictions the filing window opens when a product is released publicly, so seek legal advice. In industries where a scientific breakthrough is the competitive advantage, weigh this carefully. In most industries, where patents are defensive, the learning benefits outweigh the risk. On competitors stealing your idea, which he says is the single most common objection: if only it were so easy to have a good idea stolen. He has given entrepreneurs the assignment of trying to get a large company to steal one of their lesser ideas — find the relevant product manager, call them, write a memo, send a press release. Most managers at most companies are already overwhelmed with good ideas. Their problem is prioritisation and execution, and it is precisely that problem which gives a startup any hope of surviving. On brand risk: launch the MVP under a different brand name. And on morale, which is the real one: MVPs often produce bad news, and teams trained in traditional stage-gate development are used to making go or kill decisions, so a failed MVP can cause them to abandon the project entirely. Ries says this is solvable, but it requires agreeing in advance what will be learned and what the decision rule is. Innovation accounting If the MVP is the instrument, innovation accounting is the scoreboard, and this is the chapter Ries considers most important. The problem it solves is the standard startup board meeting, where the answer to "are we making progress?" is a story: we made a number of changes last month, customers seem to like them, our overall numbers are up. That is not evidence. How do you know the changes are related to the results? More importantly, how do you know you are drawing the right lessons? Innovation accounting works in three learning milestones. First, establish the baseline. Use an MVP to get real data on where you actually are — conversion rates, sign-up and trial rates, customer lifetime value — no matter how far from the goal that is. You can test many assumptions with one prototype offered for sale through your main channel, or you can build separate MVPs one assumption at a time, including a smoke test where customers are offered the chance to preorder something that does not exist yet. Test the riskiest assumptions first, because if you cannot get those to a viable level, there is no point testing the rest. For an advertising-funded media business, the two assumptions are whether you can capture the attention of a defined segment on an ongoing basis, and whether you can sell that attention. In a market where ad rates are well known, capturing attention is by far the riskier one, so experiment on content, not on ad sales. Second, tune the engine. Every product, marketing or other initiative should be aimed at improving one of the drivers of your growth model. If you improve the design to make it easier for new customers, you are presupposing that activation rate is a driver and that its baseline is lower than you want. If the design change does not improve activation, the design should be judged a failure. Ries's formulation of this is worth memorising: a good design is one that changes customer behaviour for the better. Third, pivot or persevere. Over time, a team that is genuinely learning will see the numbers move from the horrible baseline toward the ideal in the business plan. A team that is not will watch the ideal recede. Done properly, no reality distortion field survives this: if we are not moving the drivers of our business model, we are not making progress. The IMVU story again illustrates it. Their MVP had many defects and almost no sales, so they naturally assumed the lack of sales was caused by low quality and spent week after week improving it. Before each board meeting they would run their analytics to show what a good job they had done, and each time there was a last-minute panic because the quality improvements had produced no change in customer behaviour. To get enough data to learn, they used a budget of five dollars a day on the then-new Google AdWords, at a five-cent minimum bid. A hundred clicks a day. Commercially insignificant; for learning, priceless. Every day they got a brand new set of customers and a brand new report card the following morning. A new marketing message one day, a changed onboarding flow the next, a new feature, a bug fix, a new layout. Each time they told themselves the product was better, and each time the subjective confidence was put to the test of real numbers. The tool that made it legible is cohort analysis, which Ries calls one of the most important instruments in startup analytics. Instead of looking at cumulative totals — total revenue, total customers — you look at the performance of each group of customers who came into contact with the product independently. Each month's new customers is a cohort, and you track what percentage of that cohort took each action in the funnel. Their chart covered about seven months of very hard work. It showed that the percentage of new customers who used the product at least five times had grown from under five per cent to almost twenty per cent — a fourfold improvement. And it showed that the percentage who paid money was stuck at around one per cent, exactly where it had started. Months of work, thousands of improvements, focus groups, design sessions and usability tests, and the conversion to payment had not moved at all. Cohort analysis is what made that undeniable. They could not blame legacy customers resistant to change, or market conditions. Each cohort was an independent report card, and they were getting straight C's. That failure is what finally sent Ries to talk to customers with the right questions. Before, when a customer in an interview did not like the product, it was easy to say "fire that customer, find me someone in our target demographic," and to treat the next positive response as confirmation. With the data in hand, the questions became urgent and specific: why is our hard work not paying off? And the answer arrived quickly. They had been making it easier and easier to use IMVU with existing friends, and customers did not want that behaviour at all. Making it easier was beside the point. Ries names the general pattern: poor quantitative results force you to declare failure, and that failure creates the motivation, the context and the space for qualitative research, which produces new hypotheses, which may lead to a pivot, which unlocks a new round of experimentation. Establish the baseline, tune the engine, decide whether to pivot or persevere. And the sign of a successful pivot is that the experiments you run afterwards are more productive than the ones before. He is careful to distinguish optimisation from learning. Engineers, designers and marketers are all skilled at optimisation, and in a well-run traditional organisation those skills deliver incremental benefit for incremental effort. But if you are building the wrong thing, optimising it will not produce results. He describes being called in repeatedly to help companies who believe their engineering team is not working hard enough, and finding that the team is executing — with discipline — a plan that does not make sense. The downward spiral is predictable: results do not come, leaders assume the specification was insufficiently detailed, specifications grow, planning slows, batch size increases, feedback is delayed, and eventually people get fired. Vanity metrics, and the three A's The counterpart to innovation accounting is a warning about metrics that feel good and teach nothing. Vanity metrics are gross, cumulative, always-up-and-to-the-right numbers: total registered users, total page views, total revenue. They rise even when nothing is working, because they are dominated by past decisions and by the simple passage of time. Actionable metrics have three properties, which Ries calls the three A's. Actionable means the report demonstrates clear cause and effect. If a number moves, you must be able to say which action moved it, otherwise the number is not a report card, it is a horoscope. Cohort analysis and split testing are what supply that causality. Accessible means everyone in the company can understand it. Reports should be as simple as possible, expressed in tangible units — people, not aggregate hits. As the gross numbers grow, this matters more, not less: it is hard to picture what it means when monthly website hits drop from two hundred and fifty thousand to two hundred thousand, but everyone immediately understands what it means to have lost fifty thousand customers. That is a stadium full of people who have abandoned the product. Auditable means the data must be credible to the people whose work it judges. Managers who do not believe a report will find a way to discredit it, so anyone should be able to check the underlying figures by talking to real customers, and the report should be generated from the primary data rather than from a system nobody can inspect. Pivot or persevere Ries's account of pivoting is more disciplined than the word's popular use suggests. A pivot is not a synonym for change. It is a structured course correction designed to test a new fundamental hypothesis about the product, the business model, or the engine of growth. He recommends holding an explicit pivot-or-persevere meeting on a regular schedule — every few weeks to a few months — attended by both the product development and the business leadership, because if either group meets alone the meeting will fail. Product people need the qualitative customer research; business leaders need the innovation accounting numbers. The most useful part of the chapter is his own failure to pivot. Several years in, IMVU was doing over a million dollars a month in revenue and had created more than twenty million avatars. And they had fallen into a classic trap: they had been so successful with their early methods that they had stopped applying the principles behind them. Early on, when everyone told them to slow down and focus on quality rather than shipping low-quality MVPs, they ignored the advice and were vindicated. Afterwards, the advice changed to "you can't argue with success," and they liked that advice better. It was equally wrong. What they needed was a customer segment pivot. The logic of a minimal product is that anything beyond what early adopters need is waste — but that logic only takes you so far. Once you have succeeded with early adopters, you want to sell to mainstream customers, and mainstream customers are more demanding. The very actions that had made IMVU successful with early adopters were diametrically opposed to what would be needed for the mainstream. The symptoms were all there and all ignored. They had begun trusting vanity metrics. They had stopped using learning milestones. They spent months on activation rate — usability improvements, persuasion techniques, incentive programmes, quests, game mechanics — measuring each one rigorously with A-B tests, and many worked individually, but in aggregate over many months the drivers of growth barely moved. Activation edged up a few percentage points. That is the classic sign of diminishing returns and the need to pivot. But the company was still growing, month after month of up-and-to-the-right, so they ignored it. Meanwhile they were exhausting their early-adopter market. Acquiring customers at the old prices got harder, marketing was pushed toward mainstream customers who were less forgiving of an early product, activation and monetisation of new customers fell, acquisition costs rose, and growth flatlined. The pivot, when it came, felt like a second founding. Designers built a clear customer archetype from extensive in-person conversation and observation. They invested in a major overhaul to make the product dramatically easier to use — the kind of large investment they had stopped making in favour of low-risk, low-yield tests. But they did not abandon experimentation: a cross-functional team worked exclusively on the redesign and continuously tested it head to head against the old one. Initially the new design performed worse, as is usually the case. Months later it performed better, and it became the foundation for growth to over twenty-five million dollars a year. They might have got there sooner if they had pivoted earlier. Then comes the catalogue of pivots, which is the most quotable part of the book. There are ten. A zoom-in pivot: what was one feature of the product becomes the whole product. A zoom-out pivot: the reverse — what was the whole product becomes one feature of something larger. A customer segment pivot: the product solves a real problem for real customers, but not the customers you planned to serve. The hypothesis is partially confirmed — right problem, wrong customer. A customer need pivot: from knowing customers extremely well, it becomes clear that the problem you are solving is not very important to them, but that a related problem is. Right customer, wrong problem. Sometimes this needs only repositioning; sometimes an entirely new product. Potbelly Sandwich Shop, now hundreds of stores, began in nineteen seventy-seven as an antique shop that started selling sandwiches to bring in foot traffic. A platform pivot: a change from an application to a platform, or the reverse. Most commonly, a company that aspires to build a platform begins by selling a single killer application, and the platform emerges later. A business architecture pivot: borrowing from Geoffrey Moore, companies generally follow one of two architectures — high margin and low volume, the complex systems model typically associated with enterprise sales, or low margin and high volume, the volume operations model typically associated with consumer products. This pivot switches between them, in either direction. A value capture pivot: a change in how the company captures the value it creates. Ries objects to the words monetisation and revenue model because they imply that value capture is a separable feature that can be bolted on later. It is intrinsic to the product hypothesis, and changing it has far-reaching consequences for product, business and marketing strategy. An engine of growth pivot: switching between the viral, sticky and paid growth models to seek faster or more profitable growth. Commonly this also requires a change in how value is captured. A channel pivot: recognising that the same basic solution could be delivered more effectively through a different channel. The channel's requirements typically determine a product's price, features and competitive landscape, which is precisely why the internet was so disruptive to industries that had depended on complex sales and distribution. A technology pivot: achieving the same solution with a completely different technology. This is much more common in established businesses, because it is a sustaining innovation — same customers, same problem, same value capture, same channels. The only question is whether the new technology offers better price or performance. And then a warning about the whole catalogue. The ability to pivot is no substitute for strategic thinking. The problem with famous pivot examples is that most people only know the successful end state. Everyone knows Southwest and Walmart as low-cost disruptions, Microsoft as a platform monopoly, Starbucks as a premium brand. What is less known is the pivots required to discover those strategies, because companies have a strong incentive to align their story around the heroic founder and make success look inevitable. Analogies to those companies are unreliable: have you copied the essential features or the superficial ones? Did what worked in that industry work in yours, and does what worked then work now? A pivot is best understood as a new strategic hypothesis that will require a new minimum viable product to test. One more idea from this chapter, which is quietly one of the book's best. Runway is normally measured as the number of months of cash remaining, and the traditional response to a short runway is to cut costs. Ries suggests measuring runway as the number of pivots remaining — how many more opportunities you have to fundamentally change strategy. That reframing changes what you optimise. Cutting costs extends the months but may not add a single pivot. Getting through the Build-Measure-Learn loop faster adds pivots without adding a day of cash. ------------------------------------------------------------ Part Three. Accelerate Small batches The most counterintuitive chapter starts with an image everyone can test at home. You have a hundred letters to put into envelopes: fold, insert, seal, stamp. Almost everyone believes it is faster to fold all hundred letters first, then insert all hundred, then seal, then stamp. It is not. Doing one envelope completely at a time — what lean manufacturing calls single-piece flow — is faster, because of the time lost stacking, moving and restacking the piles between stages. And even if the raw times were identical, small batches would still win, for a reason that matters more. Suppose the letters do not fit the envelopes. With the large-batch approach you find out near the end, after doing all the folding. With single-piece flow you find out on the first envelope. Suppose the envelopes are defective and will not seal. In the large batch you must unstuff everything and start again. That is the history of Toyota. In the post-war economy, Japanese carmakers could not compete with American factories running ever-larger batches on huge specialised machines, driving down unit costs on completely uniform cars. The Japanese market was too small for those economies of scale, and post-war capital was not available for the machines anyway. So Ohno, Shingo and others used smaller general-purpose machines that could make a variety of parts in small batches, which meant they had to be able to reconfigure a machine rapidly. Shingo's concept of single-minute exchange of die reduced changeover times from hours to minutes. And because the batches were small, Toyota could offer far greater product diversity without giving up cost — serving smaller, more fragmented markets, and eventually growing into the world's largest carmaker. The biggest advantage of small batches is that quality problems surface far sooner. This is the origin of Toyota's andon cord, which lets any worker stop the entire production line the moment they notice a defect that cannot be immediately corrected. On its face this is absurd — an assembly line works best rolling smoothly — but the benefit of finding and fixing problems fast outweighs the interruptions, and it is the root cause of Toyota's simultaneous high quality and low cost. Ries's translation to startups is precise. Toyota used small batches to make factories efficient. A startup is not trying to produce more stuff efficiently; it is trying to learn how to build a sustainable business as fast as possible. Small batches minimise the time, money and effort spent before discovering that the thing being built is not wanted. He points out an irony: many high-tech products are manufactured in facilities that follow the latest lean thinking, while the process used to design them is stuck in the mass-production era. Fifteen hundred changes to a phone are released to customers in one giant batch. IMVU's version was continuous deployment: designing, developing and shipping features one at a time, with changes going live to customers within minutes. The key to operating that fast is checking for defects immediately. They ran an extensive automated test suite so that if an engineer accidentally removed something essential — the checkout button, say — the change was blocked. And they went further, because automation has a blind spot: if an engineer changed the checkout button to white on a white background, every functional test would pass while no customer could buy anything. So they built what Ries calls an immune system, monitoring business metrics in real time and automatically pulling the equivalent of the andon cord — reverting the change and alerting the team — when customer behaviour departed from normal. He is careful not to claim this only applies to software. He gives the example of a hardware company, SGW, using rapid manufacturing to design and deliver eight products serving a wide range of functions in twelve months, because feedback on design decisions was almost instantaneous. Injection moulding is the classic large-batch process — expensive and slow to set up, then extremely cheap per unit — and it has historically kept new physical products in the hands of large companies. Newer techniques let entrepreneurs produce small batches at comparable quality, far faster and cheaper. His concession is honest: not every product as it exists today allows design change in small batches, and significant work may be needed to make experimentation in small batches possible. But that is a reason to do the work, not an excuse for keeping outdated methods. The three engines of growth This is the most immediately applicable chapter for anyone running a product. Ries defines sustainable growth by a simple rule: new customers come from the actions of past customers. There are four ways that happens — word of mouth, a side effect of product usage, funded advertising, and repeat purchase or use — and they cluster into three engines. Each engine has its own metrics, its own tuning variables, and its own definition of what "working" means. A company that measures the wrong things for its engine will work hard and go nowhere. The sticky engine of growth. This applies to products designed to attract and retain customers for the long term — a marketplace that becomes the destination for fanatical collectors, or a database vendor whose customers become locked in once they build on it, or a mobile network where cancelling means the customer is either very dissatisfied or leaving for a competitor. Companies on this engine must track churn: the fraction of customers in any period who fail to remain engaged. The rule is simple. If the rate of new customer acquisition exceeds the churn rate, the product grows. The speed is the rate of compounding, which is the natural growth rate minus the churn rate — and like compound interest, a high rate produces extremely rapid growth without any advertising or viral mechanics at all. Ries describes a company that modelled this and found a sixty-one per cent retention rate and a thirty-nine per cent growth rate in new customers. Almost perfectly balanced, giving a compounding growth rate of about zero point zero two per cent — essentially nothing. It had been tracking total customers, activation rate and revenue per customer, none of which drive growth on a sticky engine. The important part is what the model tells you to do. The intuitive response to flat growth is to spend more on sales and marketing. The model says the opposite: there are plenty of new customers coming in the door, and the way to find growth is to make the product more engaging to the customers you already have. Better listings, reasons to check back often, messaging about limited-time offers. Focus on retention. That counterintuitive conclusion is impossible to reach from vanity metrics. The viral engine of growth. Here, awareness spreads person to person as a necessary consequence of normal product use. Ries is precise about this: it is not word of mouth, and customers are not deliberately acting as evangelists. Growth happens automatically as a side effect. Viruses are not optional. Hotmail is the canonical case. In nineteen ninety-six, growth was sluggish and there was no budget for marketing. Then they added one line to the bottom of every outgoing message: "P.S. Get your free e-mail at Hotmail," with a link. Within six months they had more than a million customers, five weeks later two million, and eighteen months after launch they sold to Microsoft with twelve million subscribers. Tupperware's house parties are the same mechanism in physical form: every sales pitch is also an opportunity to recruit the next representative. The engine is governed by the viral coefficient: how many new customers use the product as a consequence of each new customer who signs up. Below one, the loop fizzles — a coefficient of zero point one means a hundred customers bring ten friends, who bring one more, and then it stops. Above one, it grows exponentially. Companies on this engine should focus on the viral coefficient above everything else, because tiny changes produce dramatic differences in outcome. A consequence worth noting: viral products usually cannot charge customers directly, because any friction impedes signup and referral, so they rely on indirect revenue such as advertising. That makes testing the value hypothesis harder. Ries's resolution is that the true test of value is always a voluntary exchange of value, and that exchange can be monetary, as with Tupperware, or non-monetary, as with Facebook — customers invest time and attention, which is what makes the product valuable to advertisers. Such companies serve two sets of customers and exchange a different currency with each. If Facebook or Hotmail had charged in their early days it would have been foolish, because it would have destroyed their ability to grow. The paid engine of growth. Imagine two businesses: one makes a dollar per customer, the other makes a hundred thousand dollars per customer. To predict which grows faster you only need one more fact: what it costs to acquire a customer. If the first pays eighty cents through online advertising and the second spends eighty thousand dollars on salespeople and on-site engineering, both grow at exactly the same rate, because both have the same proportion of revenue — twenty per cent — available to reinvest in acquisition. The engine runs on the margin between customer lifetime value and cost per acquisition. An advertisement costing a hundred dollars that produces fifty signups has a cost per acquisition of two dollars; if lifetime value exceeds two dollars, the product grows, and the size of the margin determines how fast. If lifetime value falls below the acquisition cost, growth slows, and one-time tactics like burning invested capital or publicity stunts are not sustainable. That was the fate of many dot-com flameouts who believed they could lose money on each customer and make it up in volume. This applies far beyond advertising — outbound sales forces and retail foot traffic are the same engine, and all those costs belong in the acquisition cost. And Ries adds a strategic point that is easy to miss. Most sources of customer acquisition are competitive, and over time competition bids up the cost per acquisition. If everyone in an industry makes the same amount per sale, they will all end up paying most of their marginal profit to whoever supplies the customers. So long-term growth on the paid engine requires a differentiated ability to monetise a particular set of customers. IMVU's customers — teenagers, low-income adults, international users — were considered unprofitable by other services who assumed they would not pay for anything online. IMVU developed ways to collect payment from people without credit cards, including billing to mobile phones and accepting cash in the post, which meant it could afford to pay more to acquire those customers than its competitors could. His practical advice is to focus on one engine at a time. Technically more than one can operate simultaneously, but the operational expertise to model all three at once is complicated, and companies that try to build a dashboard covering all three mostly create confusion. Pursue one thoroughly before considering a pivot to another. Finally, Ries uses the engines to sharpen Marc Andreessen's idea of product-market fit — the moment a startup finds a widespread set of customers who resonate with its product. Andreessen's point is that in a great market the market pulls the product out of the startup, and in a terrible market the best product and team in the world will fail. Ries's objection is that entrepreneurs read this as implying a pivot is a failure to achieve fit, and that once you have fit you will never pivot again. Both are wrong. Because each engine can be defined quantitatively, each gives you metrics that show whether you are approaching fit. A viral coefficient of zero point nine means you are on the verge. And two companies with sticky compounding rates of five and ten per cent look very different depending on their trajectory: the one that has climbed from zero point one to five is learning; the one that has drifted from nine point eight down to ten is not. What matters is not the raw number but the direction and degree of progress. Adapt: the five whys The counterweight to all this acceleration is a chapter on going too fast. Ries's position is blunt: you cannot trade quality for time. Defects you cause or miss now slow you down later through rework, low morale and customer complaints. The Toyota proverb he quotes is "stop production so that production never has to stop." There is a genuine tension here that he does not paper over. The logic of validated learning says ship the smallest thing and treat everything beyond it as waste. But the loop is continuous, and shortcuts in quality, design or infrastructure today slow you down tomorrow. At IMVU, shipping a buggy early product was right, because customers would not even try it and most of that work had to be discarded anyway. But as they moved toward mainstream customers, low quality inhibited learning, because defects prevented customers from experiencing the benefits and giving useful feedback. And every feature added made the next feature harder, because of interference with what already existed. The same happens in a service business: every new rule may conflict with existing rules, and the more rules there are, the more conflicts. The resolution is a process with a built-in feedback loop, and Ries's version is the five whys, adapted from Taiichi Ohno. The classic Toyota example: a machine stopped. Why? An overload blew a fuse. Why the overload? The bearing was insufficiently lubricated. Why? The lubrication pump was not pumping enough. Why? The pump shaft was worn and rattling. Why? There was no strainer attached, and metal scrap got in. Without going through all five, you would simply replace the fuse or the shaft, and the problem would recur within months. Notice what happens across those five steps: the root cause moves from a technical fault to a human one. Somebody forgot to fit a strainer. Ries's claim is that this is typical: at the root of every seemingly technical problem is a human problem. His own worked example: a release disabled a feature. Why? A server failed. Why? An obscure subsystem was used incorrectly. Why? The engineer did not know how to use it. Why? He was never trained. Why? His manager does not believe in training new engineers because the team is too busy. A purely technical fault turns out to be a managerial one within five steps. The mechanism that makes this practical is what he calls proportional investment. At each of the five levels, make an investment proportional to the severity of the symptom. Small symptom, small investment. In the example above: fix the server, make the subsystem less error-prone, train the engineer, and have the conversation with the manager. That last one is always hard, and the proportionality is what makes it survivable. Ries admits that as a startup manager, if you had told him to invest in training, he would have said something sarcastic about sparing eight weeks of his time — manager-speak for no. But if the outage is minor, you only do the first hour of that eight-week plan. If the problem recurs, the next five whys session forces further progress. If it never recurs, you have lost an hour. At IMVU he never dropped everything to build a training programme; he made constant incremental improvements that compounded over time, freeing up energy previously lost to firefighting. The elegant property of this system is that it regulates speed automatically. The more problems you cause by going fast, the more you invest in preventing them; as those investments pay off, crises decline and you speed up again. Teams find their own optimal pace rather than having one imposed. Ries also warns about the most common failure mode, which he calls the five blames: the session turns into an exercise in assigning fault, usually to whoever is absent or most junior. His rules for avoiding it are practical. Be tolerant of all mistakes the first time, and never allow the same mistake twice. Have a senior person in the room with the authority to commit to the fixes. Start small and narrow — pick one class of problem, run five whys on it consistently, and expand from there. Appoint a five whys master with authority over the sessions. Innovate: building the engine inside an existing company The final substantive chapter is about how established companies can run internal startups, and it is the part most relevant to anyone leading product inside a going concern. Ries argues that internal teams need three structural attributes: scarce but secure resources, independent authority to develop their business, and a personal stake in the outcome. Secure but scarce is the interesting one. A startup gets less money than a division, but it gets absolute certainty over what it has. Corporate budgets are political, and a division that loses ten per cent of its budget mid-year suffers a setback; a startup that loses ten per cent of its funding is dead. So internal teams need a small, firmly ring-fenced allocation nobody can raid. Independent authority means cross-functional teams that can build, market and deploy without prior approval at each step. Requiring sign-off from every department at every stage guarantees large batches and slow loops. A personal stake means some form of ownership in the outcome — equity where possible, and where not, at least clear public credit for having built the thing. The mechanism he proposes for making this politically survivable is the innovation sandbox. Rather than protecting an innovation team by hiding it — a skunkworks, which eventually produces a resentful parent organisation and a team unable to reintegrate — you contain the impact of its experiments while leaving its methods free. The rules are specific. Any team can run a genuine split test that affects only the sandboxed parts of the product, or only certain customer segments or territories. One team must see each experiment through from end to end. No experiment runs longer than a specified time — a few weeks for simple features, longer for more disruptive work. No experiment affects more than a specified number of customers, usually expressed as a percentage of the mainstream base. Every experiment is evaluated against a single standard report of five to ten actionable metrics, no more. Every team and every product in the sandbox uses the same metrics. And any team running an experiment must monitor the metrics and customer reactions — support calls, social media, forum threads — and abort if something catastrophic happens. The sandbox starts small. In one company it initially contained only the pricing page. An online service might restrict it to certain pages or flows; a retailer to certain stores or regions; a company launching something genuinely new to certain customer segments. Two features make it more than a governance device. First, customers inside the sandbox are real customers, and the team is allowed to build a long-term relationship with them, because they may be experimenting with those early adopters for a long time before the learning milestones are met. Second, because every team reports through the same actionable metrics and innovation accounting, anyone who reads those reports gets an implicit lesson in how to think about them. As Ries notes with some amusement, even someone who wants to sabotage the innovation team will have to learn about actionable metrics and learning milestones in order to do it. He closes with the management portfolio: four kinds of work every company must do simultaneously. Creating something new. Scaling it as it attracts mainstream customers and competitors. Optimising a mature product, where operational excellence and cost reduction drive margins and where predictable growth supports the share price. And running legacy products and infrastructure, the domain of outsourcing, automation and cost reduction, where managers suffer the fate of baseball umpires — criticised when something goes wrong, unappreciated when things go well. The structural problem is that employees tend to follow the products they develop through all four phases. The inventor of a new product typically manages the division that commercialises it, which means strong creative managers get stuck optimising rather than creating. Ries's recommendation is to treat these as different jobs requiring different people, and to design deliberate handoffs — so that entrepreneurs inside the company are freed up to start the next thing rather than being promoted into running the last one. The epilogue: don't become a fad The last chapter is a warning about the book's own success. Ries traces the history of scientific management — Frederick Taylor's stopwatch, the movement's genuine achievements and its later degeneration into rigid, dehumanising practice — and argues that management movements typically begin with real insight and end as pseudoscience: rituals performed because they are the done thing, disconnected from the reasoning that produced them. His fear is that the Lean Startup becomes the same. Teams that hold pivot-or-persevere meetings without innovation accounting. Products shipped in a rough state and called MVPs when nothing is being measured. Five whys sessions that are really five blames. The remedy he offers is to keep asking what the practice is for. If a technique is not producing validated learning, it is a ritual, and it should be dropped no matter what it is called. ------------------------------------------------------------ What this means if you run a product organisation A few translations, offered as one reader's reading. The definition of value is the thing to import first. If value is validated learning, then a sprint that shipped everything on the plan and taught you nothing was a bad sprint. That single change of yardstick will make more difference to your organisation than any process you adopt. Write down the leap-of-faith assumptions behind your current roadmap, and rank them by risk. Most roadmaps contain a small number of assumptions that everything else depends on, and they are usually unexamined because they were settled early and never revisited. The value hypothesis and the growth hypothesis are the two that always matter. Plan the loop backwards. Ask what you need to learn, then what you would have to measure to know you had learned it, then what is the smallest thing you could build to get that measurement. If your planning starts with what to build, you will build a lot and learn little. Know your engine of growth, and make sure your dashboard matches it. This is the highest-leverage half hour in the book. If you are on a sticky engine and your team is optimising acquisition, you will work very hard for no compounding. If you are on a paid engine and nobody in the room can state lifetime value and cost per acquisition, you do not know whether growth is possible at all. And do not let a dashboard try to serve all three. Replace vanity metrics with cohort reports. Ban cumulative totals from the review. Every metric on the wall should be per-cohort, expressed in units of people, and traceable to an action someone took. Hold a real pivot-or-persevere meeting on a schedule, with both product and business leadership in the room, and bring both the numbers and the customer research. The failure mode Ries describes at IMVU — months of individually successful experiments producing no aggregate movement, ignored because the gross numbers were rising — is the single most common way a good product team wastes a year. Watch the boundary where early adopters end. The behaviours that make you successful with early adopters are frequently the opposite of what mainstream customers require, and the transition looks like success right up until growth flatlines. Rising acquisition costs plus falling activation of new cohorts is the signature. Measure runway in pivots, not months. Then ask what would let you get through the loop twice as often, because that is the only thing that buys you more attempts. And use proportional investment on process. When something breaks, do the first hour of the eight-week fix, not none of it and not all of it. Process built this way is process the team actually keeps. ------------------------------------------------------------ Rapid recap Here are the things worth keeping. A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty. Nothing about size or sector. Entrepreneurship is management, and it needs its own discipline, because planning and forecasting only work with a long operating history in a stable environment. Value, for a startup, is validated learning about how to build a sustainable business. Everything else is waste. Validated learning must be demonstrated by movement in the drivers of your business model. Saying "we learned a lot" without data is rationalisation. Build-Measure-Learn is the order the work happens; plan it in reverse — learn, measure, build. Minimise total time through the loop. The two leap-of-faith assumptions that always matter are the value hypothesis and the growth hypothesis. Go and see for yourself. But customers cannot tell you what to build; they can tell you what frustrates them. An MVP is the version that enables a full turn of the loop with the least effort. It answers business hypotheses, not just design questions. Any work beyond what is needed to start learning is waste. MVP techniques include the video, the concierge, the Wizard of Oz and the smoke test. In a concierge MVP the manual service is not the product, it is the instrument. Innovation accounting has three learning milestones: establish the baseline with an MVP, tune the engine toward the ideal, then pivot or persevere. A good design is one that changes customer behaviour for the better. Cohort analysis is the essential tool. Look at each group of customers independently, never at cumulative totals. Actionable metrics are actionable, accessible and auditable. Vanity metrics are gross, cumulative and always rising. Optimisation is not learning. A team executing a bad plan with great discipline looks exactly like a team that is not working hard enough. A pivot is a structured change designed to test a new fundamental hypothesis, not a synonym for changing your mind. There are ten kinds: zoom-in, zoom-out, customer segment, customer need, platform, business architecture, value capture, engine of growth, channel, and technology. Diminishing returns from engine tuning is the signal to pivot, and rising gross numbers are what hide it. Measure runway in the number of pivots remaining, not months of cash. Small batches beat large batches, both in speed and in how early defects surface. Single-piece flow, andon cord, stop production so that production never has to stop. There are three engines of growth. Sticky runs on churn and the compounding rate. Viral runs on the viral coefficient, and needs it above one. Paid runs on the margin between lifetime value and cost per acquisition. Pick one and tune it. On the paid engine, competition bids up acquisition costs over time, so long-term growth requires a differentiated ability to monetise a particular set of customers. The five whys ties investment to symptoms and acts as an automatic speed regulator. At the root of every technical problem is a human one. Beware the five blames. Internal startups need resources that are scarce but secure, independent authority to develop, and a personal stake in the outcome — contained in an innovation sandbox rather than hidden in a skunkworks. Companies run four kinds of work at once — creating, scaling, optimising, and maintaining legacy — and the common mistake is letting the creators follow their product into the optimising phase. And the closing warning: any of this becomes a ritual the moment you stop asking what it is for. If a practice is not producing validated learning, drop it, whatever it is called.