How to Validate an MVP Before You Build

Most founders we meet want to validate an MVP by building it, which is the most expensive way to find out an assumption was wrong. MVP validation is the work of proving, with evidence from real people, that a problem is painful enough and a proposed solution is wanted enough to justify building software.

The useful version tests one assumption at a time and measures what people do, not what they say. That is cheaper than code and usually faster. This post covers why validation comes before the build, how to match a method to your riskiest assumption, a six-step process, a worked concierge example, the mistakes that make results worthless and how to tell when it is time to build.

Why MVP Validation Comes Before the Build

Early product work is mostly uncertainty. Building the full product first assumes the problem is severe, the buyer is reachable and your solution is the right one, all at once. When any of those is wrong, the code becomes rework or gets abandoned.

The Lean Startup framing is useful here. It treats validated learning as the unit of progress for a startup, rather than features shipped. We agree with the spirit of that, because a feature that nobody needed is not progress, however well it is built.

Validation methods that avoid a full build shrink the cost of being wrong. They give fast feedback on the core assumptions, and that feedback decides which expensive engineering work is worth starting. In our experience the biggest saving is not the code you avoid writing but the months you avoid spending on the wrong problem.

Match the Validation Method to the Riskiest Assumption

Each validation method answers one kind of question well and others badly. We pick the method by asking which assumption, if wrong, would sink the product fastest.

A smoke test is a page that describes the product as if it exists and measures interest, which we cover in depth in when a landing page is a better MVP than working software. A concierge MVP delivers the service by hand, so you learn the real workflow before automating any of it.

A Wizard of Oz test looks automated but is run by a person. Nielsen Norman Group describes it as a method in which a user interacts with an interface that appears to be autonomous but is fully or partially controlled by a human. It is the cheapest way we know to test a flow that would otherwise need serious engineering, such as matching, recommendations or AI responses.

How to Validate an MVP in Six Steps

Validate an MVP by writing down one critical assumption, choosing the cheapest test that produces behavior, setting a pass mark in advance and deciding from the result. We run the same six steps whatever the method.

1. Write the Core Hypothesis in One Sentence

State the single assumption that matters most, in a form that can be wrong. A good shape is that a named type of user has a specific problem and will take a specific action to solve it.

If the sentence needs several clauses, you are testing several things at once. Split it and start with the one that would hurt most if false.

2. Pick the Smallest Testable Unit

Find the minimum artifact or interaction that can test the hypothesis. That might be a one-page site, a form and a spreadsheet, or a manual service delivered over email.

Leave out everything not tied to the hypothesis. Extra features dilute the signal and make a failed test hard to read.

3. Choose a Method That Produces Behavior

Use the method from the table that matches your riskiest assumption. Prefer methods where people spend something real, such as time, data, reputation or money.

Opinions are cheap to give and easy to misread. A signup, a booked call or a deposit is much harder to fake politely.

4. Set the Pass Mark Before You Start

Decide in advance what result counts as validation and what counts as failure. Write the threshold down with the date, the segment and the channel you will use.

Without a pass mark, almost any result can be read as encouraging. We have seen teams reinterpret weak numbers for months because nobody committed to a line beforehand.

5. Run Small Tests and Record Everything

Run the test with a small group and keep notes on every interaction, including drop-offs and confusion. For usability questions, Jakob Nielsen's guidance is that the best results come from testing no more than 5 users and running as many small tests as you can afford.

Small rounds let you change the test between sessions. One large round tells you less, later.

6. Decide to Build, Change or Stop

Compare the result with the pass mark and make one of three calls. Build the next version, change the hypothesis and test again, or stop and redirect the effort.

Write the decision down with the evidence behind it. That record is what keeps the next test honest.

A Concierge MVP Example From Invoicing

Here is a hypothetical example, not a client story, that shows how a concierge test can redirect a build. A team believes small businesses need simple invoicing connected to their bank, and building a full transactional system would take a long time.

Instead the team runs a concierge MVP. Businesses enter invoice details in a simple form, a team member creates the invoices from a template and sends them by email, and payment tracking lives in a spreadsheet. No product code is written.

After a month with a small group of businesses, the team sees that users like the simplicity, but the real pain is reconciling payments, not creating invoices. Manual reconciliation becomes the bottleneck of the concierge service itself. The validation confirms the need for an invoicing product and changes its core feature, so the first build focuses on bank connections and reconciliation instead of invoice design.

We like this example because the manual version exposed the real bottleneck before a single bank integration was built. A smoke test alone would have confirmed interest in invoicing and missed the reconciliation problem entirely, which is why we pair demand tests with at least one test of the actual workflow.

Mistakes That Make MVP Validation Worthless

Validation fails quietly when the test cannot produce a clear answer. These are the mistakes we see most often.

• Over-building the test, such as a landing page that describes ten features and therefore validates none of them.
• Treating compliments as evidence, when people who like an idea still decline to spend time or money on it.
• Skipping the pass mark, which makes every result look like a reason to continue.
• Explaining away negative results instead of treating an invalidated hypothesis as engineering time saved.
• Building after one positive signal, when a single good week is not a pattern.

The common thread is asking a question the test cannot answer. Many of the features founders defend most strongly turn out to be ones first users never touch, and a sharp validation test is the cheapest way to find that out.

When Validation Says It Is Time to Build

It is time to build when several independent tests point the same way. We look for a validated problem, a reachable segment, a solution people used even in manual form and some evidence of willingness to pay.

At that point the build should be small and aimed at the part of the workflow the tests proved. Complex domains need extra care, which we cover in how to scope an MVP when your domain is complex. Our playbook for founders covers how we turn validated assumptions into a first release plan, and it is the same sequence we follow in MVP development work.

If the tests disagree, run another round before writing code. A week of extra validation is cheap next to a quarter of building the wrong thing.

Validate an MVP With Behavior, Not Opinions

To validate an MVP, test one assumption at a time with the cheapest method that makes people act, and decide against a threshold you wrote down first. Build only when the evidence from several tests agrees.

We think that discipline is what separates a founder who learns fast from one who builds fast in the wrong direction. If you want help designing the test or scoping the build that follows it, Better Software can work through it with you.

Frequently Asked Questions

What Are the Requirements for an MVP?

An MVP needs one clear hypothesis, a defined user segment, the smallest experience that delivers the core value and a way to measure what users do. We would add a written success threshold, because without one the MVP cannot validate or reject anything.

Can You Give Me an Example of a MVP?

A concierge invoicing service is a good example, where a team creates and sends invoices by hand before writing any code. We like it because it shows the real workflow and the real pain, which often differ from what the founders expected before validation began.

How Do You Validate Your Customers?

We validate customers by checking that a specific segment has the problem, is reachable and will act. Interviews about recent behavior confirm the problem, outreach confirms you can reach them, and sign-ups, pilots or payments confirm they will act. Opinions alone do not count.

How Do I Validate My Startup Idea?

We would start with problem interviews about what people did recently, not what they might do. Then run a smoke test or concierge version with a written pass mark. If people spend time or money on the manual version, the idea has earned a small build.

What Does MVP Stand For?

MVP stands for minimum viable product, the smallest version of a product that lets a team learn from real users. We treat it as a learning tool rather than a cheap first release, so its success is measured by validated assumptions, not by features shipped.