Lean Startup

Method

A way of building a business when nobody is sure what to build yet: ship something small, read the response, and let it decide what comes next.

Why it exists

For a long time there was one order of operations for starting a company. Write a thick business plan, build the product the plan describes, and put it in front of customers once it is finished. Waterfall, which finishes one stage before moving to the next, was the default for the business the same way it was the default for the software.

When the plan is right, this is the fastest route there is. The trouble is that plans for new businesses are rarely right. A team spends eighteen months building, times a press release to the launch date, watches signups stall at two hundred in the first month, and sees a dozen of those people come back in the second. The only thing the team knows for certain at that point is that one of the assumptions made eighteen months ago was wrong, and it still doesn't know which one.

Lean startup proposes flipping the order. Instead of building everything and then checking, you put out the smallest thing that can settle a question and let the answer decide what gets built next. What counts as waste moves too. In a factory the waste is inventory sitting on a shelf; in a new business the largest waste is the months spent holding on to an idea that was already wrong.

How to run it

One turn of the cycle takes five steps.

  1. Pick the single riskiest assumption in the business — the one that makes everything else meaningless if it turns out to be false. "People find this problem annoying enough to pay to solve it" comes before "changing the signup button color lifts conversion."
  2. Write it as a statement that can come out true or false. A guess written down so it can be tested is a hypothesis, and the bar for passing gets written next to it as a number: "15 percent of people who see the team invite screen actually invite a colleague."
  3. Build the smallest thing that can answer it. That minimum form is a minimum viable product (MVP). When the hypothesis is about demand, a signup screen with no product behind it is sometimes enough.
  4. Put it in front of real users and measure the number you named in advance. Fix the window too, so a two-week test gets read at two weeks rather than whenever the result looks better.
  5. Decide from the number. Clear the bar and you push one step further in that direction; miss it and you consider a pivot, which is changing direction while keeping what you learned.

The loop those five steps form is called build-measure-learn. The quantity to manage is not how big one turn is but how long one turn takes. A team that goes around every six months learns twice a year; a team that goes around every three weeks learns seventeen times.

What counts as learning is also settled in advance. The rule that only results confirmed by real data count is validated learning. "The response seemed good" doesn't qualify; "32 of 400 people sent an invite" does.

When it fits and when it doesn't

The method fits best in an early business where what to build hasn't been settled yet. If the customer isn't narrowed down, a wrong turn is cheap to undo, and a fix can reach users within days, more turns of the loop is straightforwardly better.

The opposite conditions make it hard to apply as written.

  1. Failure hurts people or loses their money. Medical devices and payment settlement can't be shipped half-built to see how people react, and the regulators who sign off on them expect a finished thing rather than a test.
  2. The product already fits its market. Past the point called product-market fit (PMF), where what was built lines up with real demand, the question shifts from what to build toward how to deliver it more reliably and to more people.
  3. Buying decisions take months. When a single contract takes four months, one turn of the loop takes four months, and following a handful of customers closely beats running experiments.

Choosing the wrong thing to measure undoes the method even when every step is followed. Set the bar on a vanity metric like cumulative signups, which only goes up and can't decide anything, and every result will look like confirmation.

How it sounds at work

"Let's do this the lean startup way. Don't build it all — take signups first and decide from there."

Check that demand exists before finishing the thing.

"If this is the MVP, why is it two months of work? Cut it to something we can answer in two weeks."

Strip out the scope that the test doesn't need.

"The result missed the bar, but we learned something. We're dropping this hypothesis and moving to the next one."

A turn did its job if it settled a question, even when the number disappointed.

At Pagedeck the phrase came up over a document approval feature for enterprise customers. Engineering sized it at six months, and Sofia reported that most of the companies she had talked to asked about it. Mia proposed spending two weeks first. Instead of the feature, the settings screen would show an approval entry, and anyone who clicked it would get a signup box.

Over those two weeks, 2 percent of paid team accounts clicked the entry against a bar set at 10 percent. Grace put the six months toward other work. What customers had meant by approval turned out not to be a chain of sign-offs but a team lead glancing at a document before it went outside, which the existing sharing settings already covered.

What people get wrong

The most common misreading is that lean startup means building something cheap and rough in a hurry. "Lean" sounds like frugality, and the instruction to build small reads like an instruction to lower quality. What actually gets cut is scope the test doesn't need, not craft. Narrow it to one feature if you like, but that one feature has to work. Miss this distinction and a poor result becomes unreadable: nobody can tell whether the hypothesis was wrong or the build was bad, and a full turn of the loop produces nothing.

The other misreading is that every decision now has to be an experiment, which comes from applying the validated-learning rule everywhere. Questions with known answers don't need testing. Login screen layout and invoice formatting have settled conventions, and spending cycles on them means the risky assumptions go untouched for another quarter. An experiment costs a turn of the loop, so it is worth spending where being wrong would be expensive.

Where to go next

  • Lean

    the thinking this method branched off from

  • Build-measure-learn

    the loop that turns the five steps into a habit

  • MVP

    the minimum form you end up building on each turn

Last updated 2026-09-16