Part 2 of 4

Lean startup methodology: build, measure, learn. How it works in practice

Lean startup methodology: build, measure, learn. How it works in practice

Lean startup is a way of building new products under high uncertainty: instead of carrying out a ready-made plan, you test the most important assumptions in small steps and, based on what real people do, decide on the next step. The method was described by Eric Ries in the book "The Lean Startup" (2011). The name refers to lean manufacturing at Toyota: less waste, shorter cycles, decisions based on what you can see.

Waste in a new product isn't overtime or an expensive server. It's building something nobody wants. Lean startup is meant to detect that before you spend most of your budget on it.

Five principles of the method

Ries builds the method on a few principles. In short:

  1. A startup is anyone creating something new under uncertain conditions — including a team inside a large company building a new product.
  2. Such a project has to be managed differently from an ordinary one, because you don't know in advance what will work.
  3. The goal is validated learning, meaning proof from customers' behaviour, not from what they say.
  4. You work in a build–measure–learn loop and try to make each turn as short as possible.
  5. You measure progress with metrics that mean something (Ries calls this "innovation accounting"), not with the number of features or downloads.

The build–measure–learn loop

This is the heart of the method. Although the name starts with "build", you plan it backwards.

First the question: what do you want to find out? For example: "Will owners of small clinics pay for a system that automatically reminds patients about appointments?"

Then the measure: what would have to happen for you to call the answer "yes"? For example: "At least 5 of the 30 clinics I talk to pay for the first month."

Finally the build: what is the smallest thing that will let you measure this? It might be a pricing page and conversations, or a simple app with one feature. That is your MVP.

Only now do you go in order: build, measure, draw conclusions. And you immediately start the next turn with the next question.

Hypotheses: where to start

Ries singles out two hypotheses that are worth testing first.

The value hypothesis: does the product really solve a problem people are willing to pay for with time or money? You test it by watching whether users come back, pay and recommend it.

The growth hypothesis: how will new customers find out about the product? Through referrals, search, direct sales, ads? The answer determines how much it costs to acquire a customer and whether the business adds up.

A good hypothesis is specific and can be disproved. "People will like our app" is a wish. "30% of the people who create an account will come back in the second week" is a hypothesis.

Metrics that tell you something

It's easy to measure things that nicely grow: page views, downloads, number of accounts. Ries calls them vanity metrics, because they lift your mood but don't help with decisions.

The metrics that help are tied to behaviour and money:

  • Activation — what share of new people reached the moment when the product gave them value.
  • Retention — how many users come back after a week, after a month.
  • Conversion to payment — how many of the active users started paying.
  • Acquisition cost compared with how much a customer spends over their whole time as a user.

Look at groups of users from consecutive weeks separately (cohorts), not at one total. The total always grows when new people arrive, even if all of them leave quickly.

Pivot or persevere

After a few turns of the loop, a decision comes. Ries describes two paths:

Persevere — the metrics are moving in the right direction, so you keep developing the product the same way.

Pivot (change of direction) — you keep what you've learned but change one element of the strategy. For example:

  • a different customer group (a product for clinics turns out to be more needed by beauty salons),
  • one feature becomes the whole product,
  • a different payment model (a subscription instead of a one-time fee),
  • a different channel to reach customers.

A pivot is not a failure. The failure is to keep spending money on a direction that the data has been saying for months doesn't work. That's why it's worth deciding in advance when you'll return to this decision: for example after three turns of the loop or after a set amount spent.

Example: a new app step by step

Take an idea for an app for ordering meals for companies with offices in one building.

  1. Biggest risk: do offices want to order together, or does everyone prefer to order alone in a familiar app.
  2. First test, a few days: a page describing the service with an order form for one building, orders fulfilled by hand with one restaurant. Measure: how many offices order more than once within two weeks.
  3. Result: offices do order, but only for meetings and occasions, not every day.
  4. Conclusion and pivot: a product for company meetings and catering instead of daily lunches.
  5. Second turn: a simple app for ordering catering for meetings, with an invoice for the company. Measure: repeat orders and average basket value.

Had this team started with a full app with a map, a loyalty programme and integrations with five restaurants, they would have learned the same thing several months later and for far more money.

Where the method is often misunderstood

"Lean" doesn't mean "sloppy". A small scope doesn't excuse you from the quality of what you do build.

Not every product can be tested in small steps in the same way. A medical device, a banking system or a product with legal requirements has constraints you can't get around with a sign-up page. There you test what you can: demand, the sales model, usability.

Data won't replace conversations. Numbers tell you what people do. Conversations tell you why. You need both.

It isn't a method only for startups. It works in any company that launches a new product and doesn't know whether customers will accept it.

Where to start tomorrow

Write your idea on one page as a lean canvas, mark the riskiest assumption and plan the first turn: a question, a measure, the smallest thing to build. If that thing is meant to be a working app, I can build it — an MVP at a fixed price, 2–6 weeks.

Have an idea and want to test it without burning your budget?

Tell me what you want to build and who it is for. I usually reply within 2 hours with questions or a plan for the first version, with a price and timeline in writing.

Let's talk about your MVP