A minimum viable offer cuts the product, never the promise

"Minimum viable" gets read as a size instruction. Build a smaller version, ship it sooner. That reading produces a weak product that tests nothing, because a shrunken version of everything is still everything, just worse.

It is a targeting instruction. Find the assumption most likely to sink you, then build the smallest honest thing that puts that specific assumption at risk. Everything else can stay imaginary for now.

What to take away

Minimum of what, exactly

Start by naming the assumption. Not "people want this", which is not testable. Something with an edge on it:

Then the design question is narrow and answerable: what is the smallest thing that would make somebody actually do that? Not a smaller product. The smallest situation in which the assumption is genuinely at risk of being disproved. Writing the offer as a sentence with the risky slot underlined is the method in offer testing.

Cut the product in a fixed order

Most minimum offers get built by starting from nothing and adding until the thing feels substantial. That produces a thin version of everything. Start from the whole instead.

One paragraph describing the offer as it would exist in three years, every feature and response time in it. Beside it, one sentence naming the assumption most likely to sink you.

Work down this list. For each line, strike it from the paragraph and write what replaces it before you decide.

Every replacement has to be something you can actually do. "A person doing the step by hand" only counts if you have timed yourself doing it once.

Four items sit off this list. Cutting any of them makes the offer a different promise rather than a smaller one.

The one-page spec

What survives the cut goes on a single page. The spec has ten fields. "Not included" and the stop rule are the two people skip, and the two that carry the sale.

The fields this page has already fixed:

Fill the rest with delivery steps you have run yourself.

The promise is not allowed to be minimum

This is the distinction that matters most, and the one the phrase itself obscures. The product can be minimal. The promise cannot.

If you promise a partial outcome, nobody responds, and you learn nothing except that a half-solution is uninteresting, which you already knew. Nobody buys most of a result. A person with a leaking roof does not want a partly dry room.

Take the outcome seriously and cut everywhere else, but delivery can be manual, slow, ugly, undocumented, and available on Tuesdays only. It can also be limited to five customers.

What arrives must be the real thing, and it must arrive when you said. Where money changes hands before delivery, the order and shipment rule turns a stated window into a duty of notice, consent, or a prompt refund.

Which outcome is worth taking seriously in the first place is settled upstream, in problem discovery.

Manual delivery is a feature

Doing the work by hand while you are validating is not a compromise. It is the fastest way to learn things that no amount of planning surfaces.

You see every exception, and exceptions are what software gets wrong. You can change what you do for the next customer that afternoon, not next quarter. You learn how long the work really takes, the number your pricing depends on.

You discover steps that seemed essential but are never used, and the one step nobody mentioned that turns out to be the whole job.

Log every exception as it happens. The log is what makes the third repeat visible.

There is a moment to stop, and it has a recognizable shape: the same exception showing up for the third time, or the point where you cannot take the next customer without dropping an existing one. That is the specification for what to automate first, and it is far more reliable than a specification written in advance.

What you can fake and what you must not

You can leave a great deal unbuilt, and it is legitimate to do so as long as the customer gets what was promised.

The working standard for all of those is the FTC's small business advertising rule: a reasonable basis must exist before a claim runs, not after someone challenges it.

The working rule: you may under-describe your machinery, and you may not misdescribe your results, your protections, or your identity. If a customer would feel deceived on learning the truth, you have crossed from lean into dishonest, and the reputational cost lands exactly on the small early audience you can least afford to lose.

Customer data never comes off the list either. Handle and store it the way a finished business would, describe that truthfully, and delete it on request.

Design for ten, not for one

The seductive version of a minimum offer is a bespoke arrangement with one delighted customer. It teaches you a lot, and it can quietly turn into a job.

Before you sell the first one, ask what happens if nine more say yes this month. If the honest answer is that you would collapse, then you are not testing an offer, you are auditioning for consultancy. Trim the scope until ten is survivable, even if the trim makes the offer less impressive.

Set the cap by walking ten deliveries through on paper. If you would break at six, the cap is six, and you say the number out loud to the customer.

This also protects the reading. An offer you can only deliver once tells you nothing about whether the thing is repeatable, and repeatability is most of what you are trying to find out. The price the ten have to clear is your own floor, built the way pricing validation describes.

Decide the verdict in advance

Write down, before you sell one, what result would make you continue and what would make you stop. Both. In numbers where numbers apply and in plain sentences where they do not.

Then hold to it. The most common way a minimum offer fails as an experiment is that it succeeds slightly: two happy customers, neither of whom would have bought at a viable price.

That gives a founder enough encouragement to keep going another year without ever testing the thing they worried about.

Slight success is the hardest result to read. Deciding what it means before you have an emotional stake in the answer is the only reliable defense.

Where it goes next

A minimum offer that works gives you three things: a delivery process you have run yourself, a set of exceptions worth automating, and a small group of people who have paid you and will now tell you the truth.

What it does not give you is proof of demand. A handful of hand-delivered results, sold personally, says nothing yet about whether strangers will buy through a channel you can repeat.

That question belongs to launch planning, a different test with a different way of going wrong. Whether the audience can be reached at all is the third question in market validation.

Common questions

How small can the first offer be?

Small enough that you can deliver it well ten times, and no smaller than the promise. Those two constraints usually meet in one place, and where they do not, the scope has to shrink rather than the promise.

Is it dishonest to sell something I have not built?

No, provided the buyer knows what state it is in and when it arrives, and you can honor both. It becomes dishonest at the point where the description implies something that does not exist.

Should I tell customers the delivery is manual?

Yes, and usually as an advantage. A person checking every one of these is a stronger sentence than most of what would replace it, and the alternative is a discovery that costs you the customer.

What if the first ten customers all want different things?

The segment is too wide, and that is the finding. Narrowing the audience is nearly always a better response than building the union of the requests.

When do I stop doing it by hand?

When the same exception appears for the third time, or when you cannot take the next customer without dropping one you have. Boredom with manual work is not a signal.