What Does Building an MVP Actually Mean?

Building an MVP means shipping the smallest working version of a product that tests one real assumption with real users — a concept Eric Ries defined in his 2011 book The Lean Startup. An MVP is not a rough first draft of the whole idea. It is a deliberate experiment built to answer one question: will people actually use or pay for this? You build the least you can and let evidence decide the rest.

What does building an MVP actually mean?

An MVP is the minimum you can build to learn whether a real customer problem is worth solving. "Minimum" means you strip the product to one core job; "viable" means it works well enough that someone gets real value from it. The point is validated learning, not a feature count.

Eric Ries put it plainly in The Lean Startup: the MVP is the version that lets you collect the most learning with the least effort. That effort can be code, but it can also be a landing page, a spreadsheet, or a service you run by hand.

An MVP fails its job if it tries to be a small version of everything. It succeeds when it tests one belief you are not yet sure is true.

Why do most MVPs fail before the first line of code?

Most MVPs fail because they solve a problem nobody has, not because the code was weak. CB Insights' 2021 analysis of startup failure post-mortems found 35% failed because there was no market need — the single most common reason. You cannot out-engineer a missing customer.

The trap is building on a guess. Founders fall in love with a solution, spend months coding, and launch to silence. The MVP was technically fine and commercially dead.

Skip that by treating demand as the first thing to test. If you cannot find ten people who feel the pain today, no amount of polish will create them.

How do you talk to customers before you build?

Talk to customers by asking about their past behavior, never about your idea. Rob Fitzpatrick's The Mom Test is the standard here: ask what people already do and pay for, not whether they "would" use your thing. Hypotheticals produce polite lies; history produces facts.

Good questions and bad questions look like this:

• Ask: "Walk me through the last time this problem cost you money."
• Ask: "What have you already tried to fix it, and what did that cost?"
• Avoid: "Would you use an app that did X?"
• Avoid: "Do you think this is a good idea?"

Run ten to fifteen of these conversations before you write code. You are hunting for a problem people already spend time or money on. That signal — not encouragement — is your green light.

What does building an MVP in public with AI look like?

We build MVPs at Botensten by shipping a real, narrow feature in days, then watching what actual users do with it. On our own product, we cut the first version of a coaching feature down to a single flow: one input, one AI-generated result, one place to save it. Everything else — settings, history, sharing — waited until people used the core loop.

AI changed the economics of "minimum" for us. A working MVP that once took a small team weeks now takes one operator a few days, because AI writes boilerplate, drafts UI, and generates test fixtures. That speed is a trap if you skip validation — it just lets you build the wrong thing faster.

So we keep one rule: the code is cheap, the learning is not. We shipped that coaching flow, found that people wanted to re-run results more than save them, and rebuilt the second version around re-running. Two things broke in the first pass — the save button and a state bug that lost input on reload — and both taught us the save-first assumption was wrong anyway. Owning the code meant we changed direction in an afternoon instead of filing a ticket and waiting.

Which MVP type should you choose?

Choose the lightest MVP that can still produce a real yes-or-no answer. Not every MVP is an app; the right type depends on what you need to learn and how much you can fake.

Steve Blank's customer development method argues you should get out of the building before scaling any of these. Ash Maurya's Running Lean and Testing Business Ideas push the same order: cheapest test first.

What are the steps to ship your first MVP this week?

Ship your first MVP this week by testing demand before building anything complex. The order matters more than the tooling.

1. Write down the one assumption that, if false, kills the idea.
2. Interview ten people using The Mom Test rules; log what they already do and pay for.
3. Pick the lightest MVP type from the table above that tests that assumption.
4. Build only the single core flow — no settings, no accounts, no polish.
5. Put it in front of five real users and measure one behavior, not opinions.
6. Keep, kill, or pivot based on what they did, then build the next thin slice.

If real users complete the core action, you have signal to build more. If they do not, you saved yourself months. That is the entire point of an MVP: to be wrong cheaply and early.

Related reading

• How Do You Validate a Business Idea? The Honest Playbook
• Why Is It Important to Build an MVP?
• How Long Should It Take to Build an MVP? The Honest Answer
• How Do I Start a Business? A Build-In-Public Playbook