The Lean Startup

A startup's scarcest resource is not money or talent. It is the number of times it can be wrong before it runs out of road. Ries reframes the early life of a company as a series of experiments rather than a march toward a launch, and everything else in the book follows from that single move.

Under that framing, building a product is not the work. Learning whether anybody wants it is the work, and building is simply the most expensive available way to find out. The discipline the book proposes is about buying that learning at the lowest price the situation allows.

A startup is not a small company. It is an organisation searching for a business model it does not yet have.

Devmark’s reading — not a quotation from the book

The failure mode Ries is writing against is not laziness or bad engineering. It is the well-run team that spends two years building something competently and then discovers nobody wanted it. He calls this achieving failure: executing a plan faithfully when the plan itself was the flaw.

Traditional management assumes a known problem and a known customer, which makes planning sensible. A new venture has neither. Applying tools designed for a known context to an unknown one produces confident, detailed, thoroughly wrong forecasts, and the confidence is the dangerous part.

The book's central loop runs in the order of its name but is designed backwards. You begin by deciding what you need to learn, work out what measurement would teach you that, and only then build the smallest thing capable of producing the measurement.

Teams that read the loop forwards build first, measure whatever is convenient, and learn very little. The loop's value is in its speed: Ries's argument is that total cycle time through the loop, not output per cycle, is the number a startup should be optimising.

The aim is not to build quickly. It is to get through the loop quickly, which sometimes means not building at all.

Devmark’s reading — not a quotation from the book

An MVP is not a cheap version of the product. It is the smallest artefact that generates a valid answer to a specific question, and it may be something a customer never sees as a product at all — a landing page, a manual service dressed as software, a concierge process run by hand.

The term has been widely misused to justify shipping something poor. Ries's definition is narrower and more demanding: if you cannot say what the MVP was built to learn, it is not an MVP, it is just an unfinished product.

Ries wants learning to be something a team can be held to rather than claimed after the fact. Validated learning means a belief was written down, a test was run, and the data moved the belief.

Innovation accounting is the reporting layer for that: establish a baseline with real customers, tune the engine toward the baseline, then decide whether to persevere or pivot. Its purpose is to give a team an honest answer to "are we making progress?" during the long stretch where revenue is too small to answer it.

Total registered users, cumulative downloads and page views share a convenient property: they only go up. They therefore cannot tell you whether anything you did worked, which is precisely why they are so often reported.

The book's alternative is cohort analysis — following each group of customers who arrived in the same period through the behaviour that matters — and split testing, which attributes a change to a cause. The distinction is between numbers that make a team feel informed and numbers that can change a decision.

If a metric can only rise, it cannot tell you that you were wrong — which makes it useless for learning.

Devmark’s reading — not a quotation from the book

A pivot is a structured change of course that keeps one foot planted: the same vision, a different hypothesis about how to reach it. Ries catalogues several kinds — zoom-in, customer segment, platform, business architecture, among others — so that "pivot" names a specific move rather than a mood.

The book's honest observation is that most teams pivot too late. They delay because the current path has not visibly failed, and because a pivot feels like an admission. Innovation accounting exists largely to make that decision earlier and less personal.

Ries borrows from lean manufacturing the finding that small batches surface defects sooner, even when they look less efficient per unit. In software the batch is the release, and the defect is a wrong assumption.

This is where the book's engineering practices — continuous deployment, automated testing, the five whys applied to failures — earn their place. They are not presented as craft virtues but as the machinery that makes a fast learning loop physically possible.

Three misreadings are common. The first treats "lean" as a synonym for cheap or small, when the book is about speed of learning, not frugality. The second uses "MVP" to excuse shipping something broken. The third reads the method as anti-vision, when Ries is explicit that the vision is the one thing a pivot preserves.

There is also a fair criticism the book does not fully answer: iterative customer feedback is well suited to products whose value is quickly legible and poorly suited to work requiring long investment before anything can be evaluated at all.

The vocabulary won completely. MVP, pivot and build-measure-learn are now ordinary usage, often by people who have not read the book and sometimes in senses it would not endorse. That ubiquity is the clearest evidence of its influence and the main source of its dilution.

What has aged best is the underlying stance: treat plans as hypotheses, make the cost of being wrong small, and measure in a way that can change your mind. What has aged least well is the implication that this method suits every kind of venture equally.