How to Build an MVP That Actually Tests What You Think It Tests

Here is the most common mistake I see with first-time founders building their MVP: they build the thing they want to build, then look for validation that they should have built it.

The MVP isn't a small version of your final product. It's an experiment. Specifically, it's the cheapest possible experiment that can tell you whether your core assumption is right or wrong.

The product you build is almost irrelevant. The assumption you're testing is everything.

Start with the assumption, not the product

Before writing a line of code, write down the single most important assumption your business depends on. Not a list — the one assumption that, if it's wrong, the whole thing falls apart.

For most startups, this is one of three types:

The problem assumption: people actually have this problem and it bothers them enough to change their behavior to solve it.

The solution assumption: your specific approach is meaningfully better than what exists.

The willingness-to-pay assumption: people will actually pay for this, at a price that makes the unit economics work.

Most MVP builds test none of them. They test whether the founders can build a functional product — which is not a market signal.

The minimum in MVP

The word "minimum" means minimum scope. The narrowest set of functionality that can generate signal about your core assumption.

A few real examples of what this looks like in practice:

A manual process before software. Before building the automated recommendation engine, do the recommendations manually over email. If users engage and come back, you have signal that the value proposition is real. Now you know what to automate.

A landing page with a waitlist. Before building anything, describe what you're building and why it solves the problem. Drive a small amount of relevant traffic. Measure signups and — more importantly — the quality of conversations you have with people who signed up.

A Frankenstein product. Cobble together existing tools — Typeform, Notion, WhatsApp, spreadsheets — into something that delivers the experience manually. If users value it enough to keep using it despite the friction, that's stronger signal than a polished product with mediocre retention.

The consistent principle: deploy human effort before deploying engineering effort. Engineering is expensive, slow, and hard to reverse. Human effort is cheap, fast, and teaches you things.

What your MVP should look like by business type

SaaS/B2B tools: A working prototype that does the core workflow and nothing else. No settings, no customization, no edge cases. Sell it to 5 customers manually before automating anything.

Marketplace: Start with one side. Aggregate supply manually (scrape, partner, curate) and build a clean discovery experience for demand. Or vice versa — get demand committed first before building supply.

Consumer apps: Focus on the exact moment of magic — the specific instant when the user first understands the value. Build backward from that moment. The MVP only needs to deliver that moment.

Deep tech: The MVP might not be a product at all. It might be a proof of concept that demonstrates technical capability to design partners who've committed to paying once it works.

The two things every MVP must have

1. Real users who aren't your friends. Your friends will use it to support you. Strangers will use it because it's valuable. Only strangers give you real signal. This is uncomfortable because they don't soften feedback. That's exactly why their behavior matters.

2. A way to measure the right thing. Define what "working" looks like before you launch. Not "people used it." The specific behavior that would indicate your core assumption is right. Retention rate after 7 days. Conversion from free to paid. NPS from people who used it more than once. If you don't define this before launch, you'll rationalize whatever result you get.

When to stop iterating and start building

The test: can you describe 5 users who are using your product, why they use it, and what they'd do if you took it away? If yes, and the behaviors are consistent, you have enough signal to build with more conviction.

If the answer is "some people are using it but I'm not sure why" — you're not done learning. Don't scale something you don't understand yet.