How Minimum Should an MVP Really Be?

Arguments about an MVP almost always begin as arguments about scope: does this feature go in, does that screen make the first release.

They rarely run long because the list is long. They run long because nobody has written down the one sentence that settles them: what are we trying to learn from this release?

Without an answer, "minimum" is a word with no unit. Everyone draws the line by instinct, and the scope ends up shaped by whoever is most insistent.

An incomplete product and a minimum one are not the same

From outside they look alike: both have few features. The difference is which axis the reduction happened on.

A minimum product is narrowed. It serves fewer types of user and fewer situations, but within the slice it serves, it finishes the job. Someone arrives, completes what they came for, and never encounters a half-built edge.

An incomplete product is punctured. The scope is broad but every path has a hole in the middle. The user gets three steps in and then has to send an email or phone someone.

In practice the distinction reduces to one question: in the first release, can a user complete the narrow scenario you chose without help? If yes, the product is minimum. If no, it is incomplete — however small it happens to be.

Hypothesis first, scope second

The point of an MVP is not to make the product smaller. It is to reduce a specific uncertainty. So the right order starts with the question rather than the feature list.

A good hypothesis contains three things: what you believe, how you will measure it, and which result would change your mind. That last part is skipped most often and is worth the most, because a belief no outcome could overturn is not a hypothesis.

Once it is written, the scope narrows on its own. "We want to learn whether this group of users will choose to do this task our way" also tells you which screens are needed — and, more usefully, which are not.

A hypothesis also makes failure readable. Where no measure was agreed in advance, low usage can always be explained away as insufficient marketing, and nothing is learned.

What you may cut, and what you may not

Narrowing scope has safe axes and unsafe ones.

Safe to cut:

Range of users. Serving one type of user and deferring the rest does not break a product. Plenty of products work initially without an admin panel.

Number of scenarios. Building the main path and handling edge cases by hand is reasonable — provided it is known that they are handled by hand, and the user never feels it.

Degree of automation. Work done manually behind the scenes in a first release does not mean the product doesn't work. It is often the cheapest way to learn whether automating that step is worth it at all.

Readiness for scale. A system that works for a hundred users does not have to be ready for a hundred thousand.

Not safe to cut:

Usability. Even in a narrow scope, people have to understand what to do. When usability is cut, the measurement breaks: you cannot tell whether the idea failed or the interface did. We looked at that separately in why a beautiful interface can still be hard to use.

Data integrity and security. If real user data is going in, "it's only temporary" changes nothing.

Basic technical soundness. Being able to release, roll back, and see what happened when something breaks is needed from day one.

Who sees it matters as much as what they see

Even with the scope narrowed correctly, an MVP shown to the wrong audience produces a result nobody can interpret.

The mistake runs in two directions. The first is an audience that is too friendly: existing customers, acquaintances, people close to the team. They use the product because they value the relationship; their feedback is generous and their usage is unrelated to actual need. A positive signal from that group tells you the relationship is good, not that the product is.

The second is an audience that is too broad. In a release opened to everyone, most people do not have the problem the product solves. Low usage then says nothing at all, because the measurement was taken on people it was never meant for.

The right audience is usually small and defined by a single quality: they have the problem today. Those people use the product out of need rather than courtesy, and when they stop, the reason has something to do with the product — which is the thing you were trying to learn.

The number matters too. Five to ten genuine users yield more than hundreds of uninterested sign-ups. Working with few people has a second advantage: each one can be watched closely, so where they hesitate, what they misread, and which step they skip are directly observable rather than inferred.

Setting expectations with that group helps as well. Saying plainly that this is a first release, that the gaps are deliberate, and that feedback is the point turns those gaps into contribution rather than a loss of confidence.

The fragile prototype problem

One of the most common outcomes is a quick prototype ending up in production.

This rarely happens through a bad decision. The prototype works better than expected, someone shows it to a customer, the customer wants to use it, and the temporary becomes permanent. Nobody says "let's ship this." Nobody stops it either.

The cost is not immediately visible. A few months later, every feature added on top takes longer than expected — because the foundation was never built to carry anything. This is among the most expensive forms of technical debt, precisely because it was never recorded as a deliberate trade.

The protection is simple: say at the outset that the prototype is disposable, and treat promoting it to production as a separate decision requiring its own answer. "It already works" is not a reason.

An MVP inside a product that already has customers

The MVP idea is usually explained for products starting from nothing. Most companies apply it while adding a new capability to something that already exists and works — and the conditions there are different.

Existing customers do not extend the same tolerance to a first release, because for them it is not an experiment but a new part of the product they rely on. A half-finished flow reads as "early days" in a new product and as a drop in quality in a mature one.

What works in that situation is limiting the audience rather than the scope. The new capability is opened to a selected or opt-in group, while everyone else continues on the existing flow. Learning still happens; confidence is not spent to get it.

The second point is keeping the way back open. If the new flow does not work as expected, people need to be able to return to the old one. That lowers the risk and turns the choice itself into a measurement: how many stayed on the new path?

After the MVP

The most neglected part of an MVP is what happens next.

Once the measurement is in, there are three legitimate options: continue, change direction, or stop. The third is rarely discussed and therefore rarely chosen — the product carries on because nobody decided anything.

What makes that decision easier is having written the measure down in advance. Setting a date helps too: how long will we watch this release, and when do we decide?

When the decision is to continue, the first move is usually not new features. There is a list of things deliberately deferred during the MVP, and unless it goes to the top of the roadmap it quietly disappears.

In closing

"How minimum" has no single correct answer, because the answer depends on the hypothesis. Once what you are trying to learn is clear, the scope argument usually settles itself.

In practice a good MVP is a product that works completely within a narrow area. To the user it feels small but whole; to the team it produces the basis for the next decision.

In our software consulting work, we usually derive the first release scope not from a feature list but from a single question: what will this release answer?