Minimum viable offers: common questions and clear answers

"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

• Doing the work by hand while you are validating is not a compromise.
• You can leave a great deal unbuilt, and it is legitimate to do so as long as the customer gets what was promised.
• The seductive version of a minimum offer is a bespoke arrangement with one delighted customer.
• Write down, before you sell one, what result would make you continue and what would make you stop.

Minimum of what, exactly

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

• That people will hand over their own data to get this done.
• That the person who feels the problem can get the money approved.
• That the result is good enough to replace what they do now.
• That they will change the order they do things in.
• That they will wait three days for an answer.
• That we can produce the result at all, reliably, for a stranger.

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.

Assumption at risk	Smallest honest offer that risks it	What it still cannot tell you
They will pay for the outcome	A paid pilot for one customer, delivered by hand	Whether it scales, or the price holds broadly
They will hand over their data	Ask for the file before anything is built	Whether they will keep doing it monthly
The result is good enough	Deliver one result manually and ask them to use it	Whether quality holds when you are tired
The buyer will approve it	A written quote sent to the actual budget holder	Anything about the wider market
They will change their process	Watch one person do it your way for a week	Whether the change survives without you watching
You can deliver it at all	Do it once, end to end, timing yourself	What it costs at ten times the volume

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.

So take the outcome seriously and cut everywhere else. The delivery can be manual, slow, ugly, undocumented, available on Tuesdays only, and limited to five customers. What arrives at the end has to be the real thing, and it has to 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 rather than next quarter. You find out how long it really takes, which is the number your pricing depends on. You discover the steps that seemed essential and turn out never to be used, and the one step nobody mentioned that turns out to be the whole job.

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.

Reasonable to fake: automation that is currently a person, integrations that are currently a copy and paste, a dashboard that is currently a document you send, the team implied by the word "we", scale you do not have, a self-service flow that is currently you setting up each account by hand.

Not open to negotiation: the outcome itself, how you handle and store their data, what security or compliance you claim, any credential or certification, any regulatory permission, any third party's endorsement, and how far along you say the thing is if they ask directly. The working standard for all of those is the one the FTC sets for small business advertising: a reasonable basis has to exist before a claim runs, not after somebody 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.

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.

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 customers, both happy, neither of whom would have bought at a viable price, and a founder who now has enough encouragement to keep going for another year without ever having tested the thing they were 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, and it is 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.