MVP Validation Plan: Test Before You Build

A MVP validation plan is a structured set of questions and tests you run before writing a single line of code. It helps you confirm that a real problem exists, that people will pay to solve it, and that your proposed solution is the right first version to build. Done well, it takes a week or two and saves months of wasted build time.

Before you hire anyone or open Figma, you need this plan.

---

What an MVP validation plan actually is

The phrase gets used loosely, so let me be specific. An MVP validation plan is not a business plan. It’s not a feature list. It’s not a deck for investors.

It’s a short document that answers three questions before you commit money and time to building:

1. Is the problem real and specific?
2. Will anyone pay for a solution?
3. What’s the smallest version that tests the core assumption?

That’s it. Every exercise in this article feeds one of those three questions. If you can answer all three with real evidence, you’re ready to build. If you can’t, building early is a gamble.

---

Why founders skip MVP validation and regret it

The most common pattern: a founder has a strong conviction, jumps to building, spends $15,000 to $50,000, and launches to silence. Not because the idea was bad, but because the version they built was wrong.

Usually one of three things happened:

• They solved a problem people have but don’t care enough to pay for.
• They built for a customer who isn’t actually their customer.
• They shipped 12 features when two would have proven the idea.

A validation plan doesn’t eliminate risk. Nothing does. But it forces you to make your assumptions visible before they cost you real money.

The goal isn’t to predict the future. It’s to find out which assumptions are load-bearing, then test those first.

This pattern has been documented widely enough that it’s become a standard part of lean startup methodology. The CB Insights analysis of startup post-mortems consistently finds “no market need” as the leading reason startups fail, accounting for a significant share of shutdowns. That’s not a product problem. That’s a validation problem.

---

Step 1: Write down your assumptions

Start here, not with features. Open a blank document and answer these:

• Who exactly has this problem? Be specific about the person, not just the demographic.
• What are they doing today instead of using your product?
• Why is that existing solution bad enough that they’d switch?
• What would they pay for something better?
• What would have to be true for this to work?

That last question is the most important. Every idea rests on assumptions that haven’t been tested. Your job is to list them all, then rank them by how much damage they’d cause if they turned out to be wrong.

The assumptions that would kill the business if false, those are the ones you test first. Everything else can wait.

A practical format for listing assumptions

Don’t overthink the structure. A simple table works:

Assumption	If wrong, what breaks?	Confidence level (1-5)
Customers will pay $49/month	Revenue model collapses	2
Target users do this task weekly	Frequency makes it worthwhile	3
Existing tools are genuinely painful	Switching motivation disappears	4

Low confidence plus high damage equals your first test. That’s the whole prioritization logic.

---

Step 2: Define your riskiest assumption

Not all assumptions are equal. Some are almost certainly true. Others are entirely unproven.

Here’s a simple way to rank them. For each assumption, ask: if this is wrong, does the business still exist?

The one that answers “no” most clearly is your riskiest assumption. That’s what your MVP needs to test.

Common examples:

• “People will pay for this, not just use it for free.”
• “This customer segment has this problem badly enough to change their workflow.”
• “We can acquire users at a cost that makes the math work.”
• “People will trust a new tool enough to put real data into it.”

Pick the one that scares you most. That’s your validation target.

---

Step 3: Define what counts as evidence

This is where most founders go vague. “We’ll talk to users and see what they say” isn’t a validation plan. It’s market research without a success condition.

Before you run any test, write down:

• What result would make you confident enough to build?
• What result would make you pause or pivot?

For example, if your riskiest assumption is that people will pay, you need to get to money or something very close to it. Letters of intent. Pre-orders. A pilot agreement. Someone pulling out a credit card.

“People said they’d use it” is not enough. “People said they’d pay” is not enough. Actual payment, even symbolic, is a real signal.

For some assumptions, evidence looks different. If your assumption is about a workflow problem, evidence might be watching five target users try to do the task today and seeing them fail in the same predictable way.

The format matters less than having a specific threshold in advance.

Setting a threshold before you start

Write it down literally. Something like: “We’ll consider this assumption validated if at least three of ten prospects agree to pay a deposit before we build.” That sentence forces clarity. It also makes the decision after the test much easier, because you’re not negotiating with yourself about what the results mean.

This is the part most validation processes skip. They run the test, then interpret the results in whatever direction confirmation bias pushes them. Having a written threshold prevents that.

---

Step 4: Choose the right validation method

Different assumptions need different tests. Here are the most practical ones:

Problem interviews

Talk to real potential users. Not friends, not investors. People who have the problem today.

Ask them about the past, not the hypothetical future. “Tell me about the last time you ran into this” is a better question than “Would you use something that did X?”

Aim for at least 10 conversations before drawing conclusions. Look for patterns in the pain, not just confirmation. The Mom Test by Rob Fitzpatrick is the best short resource on how to run these conversations without getting misled by people being polite.

A landing page test

Build a single-page site describing the solution, put a real CTA on it (sign up, join waitlist, pay now), then drive traffic at it. The conversion rate tells you something real about demand.

A well-structured landing page that charges $0 but requires an email is a weaker signal than one that asks for payment. Don’t lie to people. Be honest that the product is coming. But measure how many click through.

If you want help building that page properly, I have a flat-fee landing page service that’s designed exactly for this kind of validation test.

Concierge MVP

Do the thing manually before you automate it. If your product is supposed to automate a workflow, do that workflow by hand for five paying customers first. Prove you can deliver the outcome. Then build the software.

This approach sounds slow, but it’s often the fastest path to real signal. You learn exactly what’s hard, what customers actually value, and whether the economics work. Zapier famously started this way: the founders manually connected apps for early users before writing a line of automation code.

Prototype test

Build a clickable prototype in Figma, not code. Put real users in front of it. Watch where they get confused, what they skip, what they click instinctively.

This tests usability assumptions cheaply before any engineering work. If you’re scoping what to build first, a prototype walkthrough session with five users will tell you more than three weeks of internal debate.

Smoke test or pre-order page

This is a sharper version of the landing page test. Instead of collecting emails, you put an actual price on the page and ask for payment. If nobody pays, that’s data. If people pay and you have to refund them because the product isn’t ready, that’s a very strong signal.

Tools like Gumroad or Stripe make this easy to set up in a day. The bar for “validated demand” is much higher when money is actually changing hands.

---

Step 5: Set your scope before you validate

One of the less obvious uses of a validation plan: it forces you to write down what you think the MVP is before you’ve talked to anyone. Then you adjust based on what you learn.

This order matters. If you talk to users first with an open mind and no prior scope, you’ll end up with a list of 40 features and no clear core. Users tell you what they want. Your job is to figure out what they need, specifically the smallest thing that tests the assumption.

Write a rough scope first:

• What is the core action the user takes?
• What do they see before they do it?
• What happens after?
• What is explicitly not in version one?

That last line is as important as the rest. What you leave out defines the MVP as much as what you include.

The “one thing” test

Here’s a useful gut check: if your MVP does one thing really well, what is that one thing? If you can’t answer that in a single sentence, your scope is still too broad.

A payments MVP that also handles invoicing, reporting, and user permissions isn’t an MVP. A payments MVP that lets a freelancer get paid via link with one click: that’s a scope. Everything else is version two.

---

Step 6: Build a simple decision framework

After you’ve run your validation tests, you need a way to decide what to do with the results. Three paths:

Build as planned. Your riskiest assumption tested true. Evidence is strong enough to commit. You’re moving from validation to build.

Pivot the assumption. You discovered the problem is real but your proposed solution isn’t right. Redefine the core feature or the target customer before building.

Kill it. The assumption failed badly. The demand isn’t there, the problem isn’t painful enough, or the economics don’t work at any reasonable scale. This is a good outcome. You saved months.

Most founders only plan for the first path. Having all three in writing before you start makes it easier to act on what you actually find.

---

How much time should MVP validation take?

A practical MVP validation plan takes one to three weeks if you’re focused. That’s:

• Two to three days writing and ranking assumptions.
• One week running interviews or a landing page test.
• Two to three days synthesizing what you found and making a build/pivot/kill call.

If it’s taking longer, you’re probably over-engineering the research phase. The point isn’t to eliminate uncertainty, it’s to reduce the most dangerous unknowns before you spend real money.

Paul Graham made a version of this point in the early YC days: talk to users, build what they want, and do it fast. The YC application itself asks founders what they’ve learned from users, which signals how seriously they weight early validation.

---

What a good validation plan is not

A few traps worth naming:

It’s not a survey. Surveys are easy to run and nearly useless for this. People answer survey questions differently than they behave with real money or a real product in front of them.

It’s not investor validation. Someone agreeing to invest based on your pitch is not the same as a customer agreeing to pay for your product. These are different things.

It’s not “I already know my customer.” Even if you have domain expertise, the specific product assumptions still need testing. Experts are wrong about product details all the time.

It’s not a replacement for good design. Validation tells you what to build. Design tells you how to build it so people can actually use it. You need both.

---

When you’re ready to build

Once validation gives you the green light, the next question is how to scope and build the actual product. That’s a different set of decisions: tech stack, timeline, who builds it, and how you structure the work.

I cover that in what tech stack your MVP should use and in the MVP launch checklist if you want to go deeper on the pre-launch side.

If you’re at the point where you have a validated idea but aren’t sure how to scope the build, my $500 Audit + Spec service works well here. You come in with your assumptions and your rough scope, and I help you turn that into a specific, buildable spec. It’s one focused lens, and the fee credits 100% toward the build if you move forward within 30 days.

If you’re ready to go from validated idea to a real product, the Idea to MVP service covers the whole thing: design, build, and ship.

Not sure what you actually need to build first? My Audit + Spec helps you get to a clear, scoped plan for $500, credited toward the build if you move forward. Tell me where you are in the process.

---

Frequently asked questions

What is an MVP validation plan?

An MVP validation plan is a structured set of tests you run before building to confirm that a real problem exists, that people will pay to solve it, and that your proposed first version targets the right assumption. It typically involves writing down your riskiest assumptions, designing tests for each, and setting a specific evidence threshold before you start.

How long does MVP validation take?

A focused MVP validation effort takes one to three weeks. That includes writing and ranking assumptions, running interviews or a landing page test, and synthesizing results into a build or pivot decision. Spending longer than three weeks usually means you’re over-researching rather than learning.

What’s the difference between validation and market research?

Market research describes a space. Validation tests a specific assumption with a success condition attached. “People have this problem” is research. “Five people paid $50 for early access” is validation. The difference is specificity and stakes.

Do I need to build anything for validation?

Not necessarily. Many of the best validation tests use interviews, landing pages, or manual concierge delivery rather than software. Building before validating is the mistake you’re trying to avoid.

When should I stop validating and start building?

When you’ve tested your riskiest assumption and gotten evidence strong enough to commit. That usually means real payment signals, not just survey responses or verbal interest. If you’re not sure whether your evidence is strong enough, that’s a good sign to do one more test.

How does an Audit + Spec fit into an MVP validation plan?

The Audit + Spec service is most useful after validation, when you have evidence that supports building but need help turning a rough idea into a clear, scoped spec. It covers one focused lens and credits 100% toward the build within 30 days.

---

Ready to go from idea to built product?

If your validation is done and you need help scoping or building the actual product, that’s what I do. The $9,000 Idea to MVP service covers everything from scope to shipped. Or start with the $500 Audit + Spec if you want a clear plan before committing to a build.

Tell me about your project and we’ll figure out what the right next step is.