The Lean Startup Method: Test a New Offer Before You Buy the Van

The Lean Startup method treats a business idea as a guess that has to be tested cheaply before it gets funded. Not researched. Tested, with real customers, real money and a result you cannot argue with.

Eric Ries named the approach in a 2008 blog post and built it out in a 2011 book, drawing on lean manufacturing and agile development. Its core proposition is that most new ventures fail not because the team executed badly but because they built something nobody wanted, and that the fix is to find that out in week two rather than month fourteen (The Lean Startup).

Most writing about the Lean Startup assumes you are founding a company. This is the version for a business that already exists and is considering something new: a product line, a new market, or offering delivery to your customers for the first time. The decision is the same shape. You are about to spend money on the belief that demand exists, and you can test that belief for a fraction of what committing to it costs.

The Bottom Line

• The Lean Startup method exists to answer one question before you spend: does anyone actually want this at a price that works?
• CB Insights’ post-mortem analysis of venture-backed failures put poor product-market fit at the top of the list, around 43% in their 2024 update, essentially unchanged from the 42% “no market need” figure in earlier rounds (CB Insights).
• A minimum viable product is the smallest thing that produces a real decision from a real customer. For a service, that is usually doing it manually for a handful of people.
• Test demand first, then build the operation. Kanban and Scrum are how you run the thing once you know it should exist.

What the Lean Startup method actually is

It is a loop, not a plan: build the smallest possible version, measure what real customers do with it, learn whether your assumption held, and repeat.

Ries defines the minimum viable product as the version that produces the maximum validated learning for the least effort. The word doing the work there is validated. An MVP is not a cheap version of the product. It is an experiment that happens to be shaped like a product, and its job is to return an answer.

The method rests on a claim about what is actually scarce in a new venture. It is not money and it is not effort. It is knowing which of your assumptions are wrong. Every week spent building on an untested assumption is a week of work that may have to be discarded, so the discipline is to spend as little as possible until the riskiest assumptions have been checked against reality.

That reframing is what makes the Lean Startup useful to an established business. You have more resources than a founder does, which sounds like an advantage and often is not, because it means you can afford to build the wrong thing properly.

Why an established business needs this more than a founder does

Because you have an existing operation the new idea has to fit into, and that constraint is invisible until you test it.

A bakery adding Saturday delivery is not running one experiment. It is running three at once: whether customers will pay for it, whether Saturday order volume justifies a vehicle and a driver, and whether the packing team can absorb the extra work without the Monday wholesale run slipping. A founder tests one assumption. You are testing how a new thing interacts with everything already working.

The other reason is that the downside is larger. A failed experiment costs a founder time. It costs you a signed vehicle lease, a hire you now have to unwind, and the goodwill of customers who were promised a service you have since stopped offering without announcing it. Those costs are exactly what a small test buys you out of.

And there is a cost to the alternative that rarely gets counted. Delivery economics have moved fast. U.S. delivery costs rose roughly 12% from 2024 to 2025 on labor, fuel and congestion, before carrier residential surcharges (SmartRoutes). A plan built on last year’s assumed cost per drop is not a conservative plan. It is an untested one.

How to run the build-measure-learn loop

The loop is named build-measure-learn and is best designed in reverse.

Start at learn: write the question. Not “should we offer delivery” but something falsifiable. “Will at least fifteen of our regular retail customers pay $8 for Saturday delivery within three miles?” A question with a number in it can be answered. A question without one produces a meeting.

Then measure: decide the evidence in advance. What result means yes, what result means no, and what you will do in each case. Deciding this after you see the data is how every experiment ends up confirming what somebody already wanted to do.

Then build: the smallest thing that produces that evidence. Almost always smaller than instinct suggests. To test the question above you need an order form, a price, and one Saturday. Not a route planning system, not a fleet, not a rebranded delivery page.

Then run it and hold your nerve. The hardest part is not rescuing a failing test. If the offer is not selling, resist the temptation to discount it into life, because then you have tested a discount.

One loop should take weeks, not quarters. If designing your experiment takes longer than running it, the experiment is too big.

What a minimum viable product looks like for a service

For a physical service, the MVP is nearly always manual. Three shapes cover most cases.

The concierge MVP. You deliver the service by hand, personally, to a small number of customers, with no systems behind it. The owner drives the Saturday orders in their own car for three weekends. It does not scale, and it is not supposed to. It is a demand test that also teaches you what the work actually involves (ParallelHQ).

The pre-sale. Offer the thing before it exists and take real orders. Money committed is the only demand signal that cannot be politely faked. A florist can list a next-day delivery option for two weeks, count the orders, and refund anyone if the numbers do not support running it.

The single-segment pilot. Run the new offer for one customer segment, one zip code or one day of the week. Deliberately narrow, so a failure costs you one segment’s goodwill rather than your whole customer base’s.

What none of these involve is buying assets. The sequence that wastes the most money is vehicle, then staff, then marketing, then discovering the demand was forty orders a month. Manual first, assets last. And if the manual version is unbearable, that is a finding too, not a reason to skip ahead.

Which metrics tell you the truth about a new offer

Ries draws a line between actionable metrics and vanity metrics, and the distinction survives contact with a small business better than most startup vocabulary.

A vanity metric goes up and tells you nothing you can act on. Total page views on the new delivery page. Social engagement on the announcement post. Number of people who said the idea sounded great.

An actionable metric is tied to a decision and to a specific group of customers. For a new delivery offer:

• Repeat rate among customers who used it once. The single most informative number. One-time use measures curiosity; the second order measures value.
• Contribution per delivery. Revenue from the order minus the marginal cost of delivering it: fuel, time, packaging. If this is negative at test volume, scale makes it worse, not better.
• Conversion from offered to accepted. Of the customers who saw the option, how many took it. This separates a demand problem from an awareness problem.
• First-attempt success rate. How often the delivery lands the first time. Around 5% of last-mile deliveries fail on the first try across the industry, and a pilot running far worse than that has an operational problem the demand test will otherwise disguise (GoBolt). Price each failure into your contribution figure rather than treating it as noise; the industry average sits near $17.78 per failed attempt (ClickPost’s last-mile delivery statistics).

Track four numbers. A dashboard with fifteen is a way of avoiding the decision.

Deciding whether to pivot or persevere

At the end of the test you have three honest options, and the method’s central discipline is picking one rather than drifting.

Persevere when the numbers cleared the bar you set in advance. Now build the operation properly. This is the point at which routing, scheduling and a real board are worth the investment.

Pivot when demand exists but not in the shape you assumed. A pivot is not abandonment; it is keeping the validated part and changing the untested part. Retail customers would not pay $8 for Saturday delivery, but three restaurants asked whether you deliver on Tuesday mornings. Same capability, different customer, and the second experiment is cheaper than the first because you already own the learning.

Stop when the bar was not met and there is no adjacent version with a signal. This is the outcome the method is built to make cheap and the one businesses are worst at taking, because the test has usually cost enough effort to feel like something that should be salvaged. It has not cost enough to be worth salvaging. That is the whole point of keeping it small.

Set a decision date before you start, and put it in the calendar. Experiments without an end date do not end; they become the thing you do on Saturdays now.

Where the Lean Startup method misleads small businesses

“Minimum” gets read as “poor quality”. Shipping something bad damages relationships you already have. Minimum means narrow in scope, not sloppy in execution: serve five customers properly rather than fifty badly.

Not everything is a hypothesis. Food safety, licensing, insurance, cold chain. You do not test your way to compliance, and “we were running an experiment” is not a defense.

The book’s examples are software companies. Software can iterate daily at near-zero marginal cost. You cannot half-buy a refrigerated van. Physical constraints make the cost of a wrong commitment higher, which strengthens the case for testing first and weakens the case for rapid iteration afterwards.

Pivoting can become a habit. Some businesses pivot away from every result rather than accepting an answer. Three pivots without a persevere usually means the bar keeps moving.

Existing customers are not a neutral sample. Your regulars will be kinder about a new offer than the market will be. Test with people who have no relationship with you where you can, and discount the enthusiasm of those who do.

Frequently Asked Questions

Is the Lean Startup method only for tech startups?

No. It was written with software startups as the primary example, but the underlying loop (test the riskiest assumption cheaply, measure what customers actually do, then decide) applies to any situation where you are about to commit money based on an unproven belief. Established businesses adding a product line, a market or a delivery service are running exactly that kind of bet.

What is the difference between an MVP and a prototype?

A prototype demonstrates that something can be built. An MVP finds out whether anyone wants it. A prototype is shown to your team; an MVP is given to real customers who make real decisions about it, usually involving money.

How long should a Lean Startup experiment run?

Long enough to cover the natural cycle of the behavior you are measuring, which for most delivery or product offers is two to six weeks. Shorter than two weeks and novelty dominates the result. Longer than six and you are no longer testing, you are operating.

How much should a test cost?

Small enough that failing is acceptable. A useful rule is under 5% of what full commitment would cost. If a failed test would hurt, the test is too big, and you will be tempted to interpret the results generously.

What is the difference between Lean Startup and design thinking?

They answer different questions. Lean Startup asks whether a thing should exist by testing demand. Design thinking asks what the customer’s experience should be by studying what people actually go through. Design thinking usually runs first to frame the problem; Lean Startup tests whether the proposed answer sells.

Before you commit

Write down the one assumption that, if wrong, makes the whole idea fail. It is usually demand at a price, occasionally capacity, sometimes both.

Design the cheapest honest test of that single assumption, set the number that counts as success and the date you will decide, then run it manually. If the answer is yes, that is the moment to build the operation around it, and agile methodology in logistics covers how to run the thing you have just validated without letting it calcify into a process nobody reviews.