How to define an MVP that doesn't blow up halfway

When a founder arrives with a list of forty screens, the problem is almost never that they want too much. The problem is that nobody has decided what version one is supposed to prove, so every screen looks equally essential. Without a criterion there is no way to cut.

The way we work starts from one question: what is the thing you still do not know, and that this version is meant to find out. If the answer is "will people pay for this", the product has to include payment and can drop profile management. If the answer is "will they come back", it needs a return mechanism and can drop payment. Two completely different builds, from the same idea.

Why scope grows

Scope does not grow in a jump. It grows through small deferred decisions, each of which sounds reasonable at the time. "We'll decide later whether there are two user types" sounds like postponing a question; in practice it is an instruction to build both, because nobody knows which one will be dropped.

• A deferred decision: every option left open is eventually priced as though both were implemented.
• An edge case mentioned in a meeting that nobody marked as out of scope — it will get built.
• An admin screen added because "we'll need to maintain this", before anyone knows whether there is anything to maintain.
• Support for a browser, device or language that was never required and never explicitly ruled out.

The practical consequence is that the list of what is not included matters exactly as much as the list of what is, and that it has to be written down. For us it lives in the document rather than the conversation, because whatever is said in conversation returns a month later as an assumption.

What does have to be in

There are three things we watch founders cut and pay for immediately. The first is failure states: what a user sees when there are no results, when an upload fails, when the connection drops. A product that looks excellent in a demo and falls apart the moment something goes wrong builds trust with nobody, least of all in an investor meeting.

The second is measurement. If the version's question is "will they come back", and launch arrives with not one event instrumented, you have a product rather than an answer. The third is an entry path: how the first user understands within thirty seconds what this is and what to do now.

That matters here because it explains why a large scope is a risk rather than a safety margin: the bigger version one is, the later it arrives, and the higher the chance it builds something with no buyer.

What this looks like in practice

In the definition session we ask for three things: the question this version answers, the first user by name — not "small businesses" but somebody specific you could phone — and the date by which somebody has to see it. The date is what turns cutting from a discussion into a fact.

1. State, in one sentence, the question version one is meant to answer.
2. Mark each capability as required to answer that question or not. Whatever is not required moves to a written "not in this version" list.
3. Add back the failure states, the measurement and the entry path, even though none of them is a "feature".
4. Set a date to put it in front of a real user, and plan backwards from it.

What actually happens is that the list shrinks by roughly half, and the loudest objections come over capabilities nobody could explain a question for. That is usually a good sign.

If you are at this stage, it is worth also reading how long an MVP really takes and what to check before choosing a development partner in the working with a software house cluster.

And when cutting hurts

There is a moment in every definition session where a founder says that without a particular capability there is no product at all. Sometimes that is true, and sometimes it is a statement about the fear rather than about the product. The way to tell is to ask what happens if the first user gets the version without it — can they not complete the path, or will they simply be disappointed.

Being unable to complete a path is a blocker and stays in scope. Disappointment is a signal that the capability matters, but it can arrive in version two — and in the meantime you will know whether there was anybody there to disappoint. That distinction sounds small, and it is the one that separates six weeks from six months.