The Lean Startup

Most entrepreneurship courses teach you to write a detailed business plan before selling anything: revenue projections, competitor analysis, a five-year timeline. Ries proposes the opposite: treat the new company as a series of scientific experiments, where every assumption becomes a question to be tested against the real market, not against a pretty spreadsheet.

This changes the central question from "Is this plan well made?" to "What do I need to learn before spending more money on this?" A startup, for him, isn't a small company. It's any team trying to create something new under conditions of extreme uncertainty, whether in a garage or inside a giant corporation.

In practice, this means accepting that a good part of what you imagine about your customer is wrong, and the early work is figuring out which part, as cheaply and quickly as possible, before building anything at scale.

The book's most quoted concept is the minimum viable product: the leanest possible version of an idea, able to generate real learning about customer behavior with the least building effort. It isn't an unfinished version of the final product. It's an experiment disguised as a product.

A classic example from outside the book: before coding an entire app, a founder creates a single page explaining the offer, with a "I want to buy" button that actually processes nothing and just records how many people clicked. If nobody clicks, the idea changed course before costing six months of development.

The most common mistake among people who read about the MVP is confusing "minimum" with "sloppy." The point isn't to deliver something bad. It's to deliver the smallest possible piece that still answers a real question about whether the customer wants it.

Instead of a fixed launch schedule, Ries proposes a short cycle that repeats: build a small version of something, measure how the market really reacts, learn from the result, and use that learning to decide the next step. The faster this cycle spins, the faster the company discovers what works.

The common trap is spending months only on the build stage, pushing measuring and learning until after the official launch, when it's too late to fix things cheaply. The cycle only works if all three stages are treated as equally urgent, not as separate phases of a linear schedule.

Think of a street food stand testing a new dish: make a small batch, see how many people reorder the following week, adjust the recipe or the price, and only then decide whether the dish joins the permanent menu. It's the same cycle, just without the Silicon Valley jargon.