What should an MVP actually prove before you build more?

An MVP should validate the single uncertainty that matters enough to change what you build next. Not a long feature list. Not whether people say the idea sounds useful. The first release should produce evidence about a risky assumption: whether the right users want the outcome, whether they can reach value through the core workflow, whether the commercial model can work, or whether a technical constraint can be made reliable enough to support the product.

That sounds obvious until a roadmap opens and every feature suddenly looks essential.

The practical move is to write the decision before you write the scope.

Start with the decision, not the feature list

A weak MVP brief starts like this:

account creation
dashboard
notifications
billing
admin panel
analytics

A stronger brief starts with a sentence:

This release exists to find out whether [specific user] will [specific behaviour] because [specific value].

Now the scope has a job.

If a feature does not help the user complete that behaviour, help the team observe it, or make the result trustworthy, it is probably not part of the first proof.

That does not mean "build badly and learn later." It means separate what must be true for the test to be credible from what can wait until the evidence justifies more investment.

Our MVP development work follows the same rule: identify the bet first, then build the smallest credible release that can produce useful evidence.

The four things an MVP may need to prove

Not every MVP needs to prove all four at once. The point is to identify which one is most dangerous to assume.

1. Demand: will the right user act?

The question is not whether people agree that the problem exists. The question is whether they do something that indicates real interest.

Depending on the product, that might be:

completing the core workflow;
joining a waitlist after seeing the real proposition;
booking a pilot;
importing real data;
inviting a teammate;
returning to complete a repeated task;
paying, depositing or otherwise committing when payment is the assumption under test.

The strongest evidence is behaviour that matches the assumption. A signup is useful evidence for acquisition. It is weak evidence for retention. A payment is useful evidence for willingness to pay. It tells you much less about whether the product becomes habitual.

2. Value delivery: can the user actually reach the outcome?

A product can attract interest and still fail because the core journey does not deliver enough value.

This is where a working MVP matters more than a presentation prototype.

The question becomes:

Can a real user enter with a real problem and reach the product's promised result without the team quietly carrying the workflow behind the scenes?

Sometimes manual work is acceptable because the manual layer is not the risky part. Sometimes it invalidates the test because the exact thing you need to learn is whether the workflow can operate reliably without intervention.

The distinction has to be made deliberately.

3. Viability: can the business around the product make sense?

A product can be desirable and technically possible while still having a weak business model.

If pricing, payment, service cost, supplier economics or support burden are central assumptions, the MVP needs a way to gather evidence about them.

That does not always mean implementing the final billing system immediately. It does mean avoiding a test that produces users while learning nothing about the commercial question that could kill the product later.

4. Feasibility: can the dangerous technical constraint work under real conditions?

Founders sometimes hear "MVP" and assume engineering risk should always be postponed.

That is wrong when the technical constraint is part of the product's value.

If the core proposition depends on payment correctness, permissions, an external integration, model behaviour, synchronization, offline recovery or another high-consequence system, then that constraint may be exactly what the first release has to prove.

The scope can still be small. The proof cannot be fake.

Use evidence that matches the question

A useful way to avoid false confidence is to write the evidence threshold before the test starts.

For example:

Assumption	Weak evidence	Stronger evidence
Users have the problem	"That sounds useful"	users already attempt a workaround
Users want this workflow	feature requests	completion of the core workflow
Users will return	first-session activity	repeated use after the first session
Users will pay	pricing-page visit	real commitment or payment when appropriate
The system is feasible	a controlled demo	reliable behaviour with real inputs and failure handling

The point is not that one signal is universally better than another. The point is that the evidence has to answer the assumption you wrote down.

Strategyzer makes the same underlying distinction when it asks teams to identify their most critical hypotheses across desirability, feasibility and viability before choosing experiments. Y Combinator's MVP guidance similarly frames the first product around testing demand rather than completing a miniature roadmap. Microsoft for Startups describes the MVP as a focused working product that should generate real data from real users rather than behave like a demo.

A worked example: Providia

For Providia, the first useful product question was not "can we build a scholarship website?"

A basic scholarship directory would not have proved much.

The more important workflow was whether scattered opportunities could become a structured path:

Discover → Match → Readiness → Prepare

That is why the product is organised around discovery, fit and readiness instead of treating every scholarship as another card in a feed.

The product also keeps scholarship information useful before payment, while paid access is treated as a durable entitlement rather than a cosmetic interface toggle. Those are different decisions because they test different parts of the product: whether the information is useful, whether the workflow helps a user act, and whether access can be managed correctly when payment is involved.

We do not need to claim that one product validates a universal MVP formula. The lesson is narrower: the feature list followed the questions the product needed to answer.

The Kochab MVP Proof Map

Before a build starts, write these four lines.

1. The bet

We believe [specific user] will [specific behaviour] because [specific value].

2. The failure condition

If we do not observe [specific evidence], we will reconsider [specific product or business decision].

This matters because an MVP that cannot fail is not really testing anything.

3. The minimum credible system

List only what is required to:

let the user attempt the behaviour;
make the experience trustworthy enough that the result is meaningful;
capture the evidence;
protect any high-consequence state that cannot be treated as a mock.

4. The next decision

Write what happens after the evidence arrives.

continue building;
change the audience;
change the workflow;
change the commercial model;
solve a technical constraint first;
stop the idea before more money is committed.

Without this final line, teams often collect data and then continue with the original roadmap anyway.

What should stay out of the MVP?

Anything that makes the product look more complete without making the proof more credible deserves suspicion.

Common examples include:

secondary dashboards no first user needs;
broad role systems when one user type can test the core value;
automations for work that can be performed manually without corrupting the experiment;
integrations that do not affect the assumption under test;
settings, reports and edge-case polish that exist mainly because the eventual product may need them.

But the reverse is also true.

Do not remove authentication, payment correctness, data integrity or another core constraint merely because it feels "too production" when the experiment depends on those things working honestly.

Minimum scope and credible proof are not opposites.

When have you proved enough to build more?

Not when the product feels finished.

Not when the team is tired of the MVP.

And not when one positive comment appears.

Build more when the evidence is strong enough to make the next investment rational—or clear enough to tell you that the original assumption was wrong.

That is why thresholds matter. Define them before launch, observe real behaviour, then make the next product decision from what happened rather than from how attached the team is to the roadmap.

If the next question is timing, read How long does it take to build an MVP?. If the question is budget, read How much does an MVP app cost?.

If you already have a feature list but cannot say what the first release is meant to prove, send the brief. We will start by narrowing the decision before narrowing the build.