The Lean Startup

Eric Ries defines a startup as an institution creating a new product or service under conditions of extreme uncertainty. The uncertainty is the important part. In an established operation, better execution against a known model can create progress. In a startup, flawless execution of the wrong model only consumes resources faster.

The Lean Startup replaces the question “Can we build this?” with two prior questions: Should this product be built, and can a sustainable business be built around it? The startup’s early job is to turn assumptions about customer behavior into evidence before time and money run out.

Ries calls that evidence validated learning. The term is meant to prevent “learning” from becoming a story teams tell after any result. Learning is validated when a specific change in the product or strategy produces measurable behavior that supports or weakens a stated hypothesis.

Build–Measure–Learn begins with the decision you need to make

The book’s central feedback loop is build, measure, learn. It is often reduced to “ship quickly,” but speed matters only if the loop answers an important question. Releasing more features without connecting them to a hypothesis can increase activity while leaving uncertainty untouched.

Planning the loop therefore runs backward. First decide what you need to learn. Then identify the evidence that would distinguish plausible outcomes. Only then build the smallest intervention capable of producing that evidence.

The loop’s cycle time is a strategic resource. A team that can test a consequential assumption in a week receives more opportunities to correct its model than a team that learns only after a six-month launch. This does not mean every question can be resolved cheaply or that short-term signals are sufficient. It means the design of the work should expose false assumptions as early as the situation allows.

At IMVU, Ries’s own startup, the team spent months building integration with existing instant-messaging networks because it assumed users would want to bring their established friends into a new 3D social experience. Early users resisted the integration and preferred meeting new people through the product. The engineering was functional; the customer model was wrong. The example grounds the book’s argument that waste includes well-executed work that does not create learning or customer value.

The minimum viable product is the start of a test

A minimum viable product is the version that allows a team to complete one Build–Measure–Learn loop with the least effort. “Minimum” is relative to the hypothesis. A test of technical performance may require working software. A test of demand, comprehension, or willingness to adopt may require a landing page, demonstration, manual service, or conversation with commitment attached.

Ries discusses Zappos founder Nick Swinmurn photographing shoes in local stores and posting them online. When an order arrived, he bought the shoes at retail and shipped them. The process could not support a mature business, but it tested whether people would buy shoes online without requiring inventory and distribution infrastructure first.

The example captures the MVP’s logic. The artifact need not be scalable because it is testing whether the reason to scale exists. A concierge service can manually deliver the proposed value while revealing what customers actually need. A video can test whether a novel interaction is understandable enough to attract serious interest. The MVP should preserve the part of the experience relevant to the risk and omit work that cannot change the current decision.

“Minimum” does not excuse avoidable harm, deceptive claims, insecure handling of data, or damage to trust. Reputation and safety may be among the assumptions a product must respect from the first test. The correct minimum is not the cheapest thing a team can release; it is the smallest responsible test that generates interpretable evidence.

Innovation accounting separates progress from reassuring numbers

Traditional measures such as tasks completed, release dates, or total revenue can mislead an early venture. They reward execution without showing whether customer behavior is becoming sustainable. Ries proposes innovation accounting: establish a behavioral baseline, attempt to improve the drivers of the model, then decide whether to pivot or persevere.

The baseline should use a real product or test to show what customers currently do. The team then identifies the parts of the model that must improve—activation, retention, referral, conversion, cost, or another causal measure—and runs experiments aimed at them. If repeated changes do not move the model toward viability, more optimization may be protecting a false strategy.

Ries favors cohort analysis over cumulative totals. Aggregate signups can rise every month while each new cohort abandons the product at the same rate. A cohort view asks how people exposed to a particular version behaved, making product changes easier to connect to outcomes.

He describes useful metrics as actionable, accessible, and auditable. Actionable metrics have a plausible causal connection to a decision. Accessible metrics are understandable to the people using them. Auditable metrics can be traced back to real customers or events. These properties make disagreement inspectable instead of allowing every group to choose the number that flatters its work.

Value and growth hypotheses are the two fundamental risks

Ries separates the value hypothesis from the growth hypothesis. The value hypothesis asks whether the product delivers enough value that target customers use, adopt, pay, or otherwise make a meaningful commitment. The growth hypothesis asks how new customers will discover and adopt it sustainably.

Attention is weak evidence for value. Downloads, wait-list signups, compliments, or time on a page may indicate curiosity without showing that a problem has been solved. The appropriate behavior depends on the model: repeated use, switching from an existing method, payment, referral, or a costly operational commitment may be more revealing.

Growth also needs a mechanism. Ries describes sticky, viral, and paid engines of growth. A sticky engine depends on retaining customers faster than they leave. A viral engine depends on existing customers bringing new ones. A paid engine depends on acquiring customers for less than the value they generate. The categories make growth a causal system rather than a generalized ambition.

The distinction prevents acquisition from hiding weak value. A company can buy or promote its way to growing top-line numbers while every cohort leaks. Sustainable growth depends on an engine whose inputs and losses can be measured.

A pivot changes strategy while preserving the learning

A pivot is a structured course correction that tests a new fundamental hypothesis about product, business model, or engine of growth. It is not any feature change, and it is not a euphemism for failure. The vision may remain while the strategy used to pursue it changes.

Ries names many pivot forms: narrowing to one feature, expanding a feature into a broader product, focusing on a different customer need or segment, changing the platform, value capture, channel, technology, or growth engine. The taxonomy matters less than the discipline of identifying which hypothesis is being replaced.

The pivot-or-persevere meeting gives the feedback loop a decision point. Without it, teams can run experiments indefinitely while interpreting every ambiguous result as a reason to continue. The meeting should compare the expected model, cohort evidence, and learning from experiments, then make an explicit commitment.

Persistence is justified when evidence shows the model improving toward viability, not merely because the team can imagine another feature. Pivoting is justified when the core assumptions remain unsupported and a materially different hypothesis is available. Stopping is also a legitimate decision when neither path warrants more investment.

Small batches make problems visible sooner

Borrowing from lean manufacturing, Ries argues for working in small batches. Large batches feel efficient because they reduce the frequency of handoffs and releases, but they allow defects and mistaken assumptions to accumulate. Small batches expose errors earlier and shorten the distance between cause and feedback.

Continuous deployment, automated testing, and cross-functional teams are implementation methods for reducing that distance. Their value is not technical modernity. They allow a venture to change the product safely enough that learning can occur at the pace uncertainty demands.

The method is not appropriate for every decision in the same way. Some systems have safety, regulatory, infrastructure, or trust consequences that make live experimentation costly. Evidence may need to come from simulation, staged trials, expert review, or slower longitudinal observation. “Move fast” is not the principle; reducing uncertainty responsibly is.

The book’s most useful standard is whether each cycle buys a decision. State the assumption that matters, choose behavior that would meaningfully support or weaken it, build only what the test requires, examine cohorts rather than reassuring totals, and decide what the evidence changes. A startup progresses when uncertainty falls around a model worth scaling, not when the feature count rises.