# What Does Building an MVP Actually Mean?

> Source: [https://botensten.com/articles/what-does-building-an-mvp-mean](https://botensten.com/articles/what-does-building-an-mvp-mean) (canonical)
> Author: Botensten — Botensten, https://botensten.com
> Published: 2026-08-21

## TL;DR

Building an MVP means creating the smallest working version of a product that tests one specific assumption with real users, a term Eric Ries coined in The Lean Startup (2011). It is not a rough draft of your full idea. It is an experiment designed to answer one question: will people actually use or pay for this? You build the least you can, put it in front of real people, and let their behavior decide what to build next.

## 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](https://theleanstartup.com/principles)*: 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](https://www.momtestbook.com/)* 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.

| MVP type | What you build | Best for testing |
|---|---|---|
| Landing page | A page describing the offer plus a signup or pre-order | Demand and messaging |
| Concierge | The service done manually, by you | Whether the outcome has value |
| Wizard of Oz | A real front end, humans faking the backend | The full experience, cheaply |
| Single-feature app | One working core flow, coded | Whether people use the core loop |

Steve Blank's [customer development method](https://steveblank.com/) 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](/articles/how-to-validate-a-business-idea-2)
- [Why Is It Important to Build an MVP?](/articles/why-build-an-mvp)
- [How Long Should It Take to Build an MVP? The Honest Answer](/articles/how-long-to-build-an-mvp)
- [How Do I Start a Business? A Build-In-Public Playbook](/articles/how-to-start-a-business-startup-bootstrapping-playbook)

## Frequently asked questions

**What does building an MVP mean?**

It means building the smallest working version of a product that tests one specific assumption with real users. The goal is validated learning about whether people will use or pay for it, not a small version of the finished product.

**What does MVP stand for?**

MVP stands for Minimum Viable Product, a term popularized by Eric Ries in The Lean Startup (2011). It is the least you can build that still delivers real value and teaches you something true about demand.

**How long should it take to build an MVP?**

Days to a few weeks, not months. If a version takes months, you are building a product, not testing an assumption; narrow the scope to one core flow.

**Does an MVP have to be code?**

No. A landing page, a concierge service you run by hand, or a Wizard of Oz setup with humans behind the scenes can all validate demand before you write any code.

**What is the most common reason MVPs fail?**

No market need. CB Insights' 2021 analysis of startup failure post-mortems found 35% failed for this reason, more than any other, which is why you validate demand first.

**How many customer interviews do I need before building?**

Aim for ten to fifteen conversations focused on past behavior, following The Mom Test rules. You are looking for a problem people already spend time or money on.

**Is an MVP the same as a prototype?**

No. A prototype demonstrates how something could work; an MVP is put in front of real users to measure actual behavior and test a business assumption.