Most MVPs do not fail because the product was wrong.
They fail before the product ever reaches a user.
The mistake is almost always the same. The founder treats the MVP as a smaller version of the eventual product instead of as a learning instrument. They build the same product, just with fewer features. They aim for "v1 minus some things" instead of asking what they actually need to learn before building v1 at all.
The result is predictable. The MVP takes three times as long as planned. By the time it ships, the founder is exhausted, the budget is gone, and the product still has to find users who care about it. Most projects do not survive that.
Here is the mistake in detail, why it happens, and how to avoid it.
The Mistake: Treating the MVP Like a Mini Product
A founder has an idea for, say, a project management tool for creative agencies. The full vision has thirty features. They sit down to plan the MVP and ask, "what is the minimum we need to launch?"
They cut some features. They keep the core ones: task management, time tracking, client billing, team chat, project templates, dashboards. The list gets to ten features. It feels lean.
They build for four months. The product launches. It works.
Nobody uses it.
The MVP was built to be a product, not to test a hypothesis. Nothing about the build process taught the founder whether agencies actually want a new PM tool, what specifically they would pay for, or what would make them switch from their existing setup. The MVP confirmed that the founder could build a working product. It confirmed nothing about whether anyone wanted it.
This is the mistake. Building an MVP as a smaller product instead of building it as a learning instrument.
Why This Mistake Happens
Three reasons.
First, founders find it easier to think about building than about validating. Building has a clear path. Code these screens. Wire up these APIs. Ship to production. Validation is fuzzy. Talk to users. Hear contradictory things. Make judgement calls. Founders default to what feels concrete.
Second, the standard MVP advice is unclear. "Build the minimum viable product." Minimum compared to what? Viable for what purpose? The phrase is interpreted as "smallest working version" when it should be interpreted as "smallest thing that teaches you whether to keep going."
Third, founders confuse motion with progress. Building feels productive. Shipping code feels like progress. Talking to ten potential users on Zoom does not feel like progress, even though it produces more useful information per hour than a month of building.
The combined effect is that founders build instead of validate, end up with a product nobody wants, and run out of money or motivation before they figure out what would have actually mattered.
What an MVP Actually Is
An MVP is the smallest thing you can build that lets you answer a specific question about your business.
The question is not "does the product work." The question is closer to "will the target customer pay for a product that does X."
If your idea is the agency PM tool, the question might be: "Will creative agencies switch from their current PM tool if a new one solves [specific pain point] better?" The MVP is whatever is needed to answer that question. Often it is much less than a working product.
It might be a landing page describing the proposed solution and a calendar link to book a paid pilot. If five agencies book a paid pilot from cold outreach to that page, you have evidence. If none do, you do not have a product idea, you have a guess.
It might be a manually-operated version. You sign up three agencies. You manually run their PM workflow for two weeks using spreadsheets and check-ins. You learn what agencies actually want from a PM tool when someone is doing the work for them. Then you build software that automates the parts they valued.
It might be a working prototype with one or two features, not ten. The features are the ones most directly tied to the hypothesis. Everything else is excluded, not because it does not matter, but because it does not help answer the question yet.
The Right Way to Scope an MVP
Three questions before any feature is added.
Question 1: What hypothesis does this MVP test?
Write the hypothesis as a single sentence. "[Target customer] will [specific action, with money] to get [specific outcome] from a product that does [specific thing]."
If you cannot write that sentence, you do not have an MVP, you have a project. Stop and figure out the hypothesis first.
Question 2: What is the smallest thing that would test the hypothesis?
For most hypotheses, the answer is much smaller than the founder initially thinks. A landing page. A spreadsheet. A manual service. A prototype with two features. Almost never a full product.
The discipline is to keep cutting until the answer is genuinely the smallest. If the answer is still "ten features," you have not cut enough.
Question 3: What does success and failure look like?
Define both up front, with numbers. "Success is five paying pilots within six weeks. Failure is fewer than three."
Without this, you will rationalise whatever happens. With it, the MVP gives you a clear answer to keep going, pivot, or stop.
What an MVP Looks Like When Done Right
A founder we worked with last year wanted to build a SaaS for B2B sales teams. Full vision: lead enrichment, sequencing, calling, reporting, CRM integration.
Original plan: four-month build, $80K budget, then start selling.
After scoping, the actual MVP was a landing page describing the product, plus a manually-operated service. He emailed thirty target sales leaders, ran a discovery call with each, and offered to do their outbound for them at $2K/month for a six-week trial.
Twelve booked the trial. He ran their outbound himself for six weeks using existing tools. He learned exactly what the workflow needed, what was painful, what was easy, and what they cared most about.
Total cost of the MVP: two months of his time, no engineering budget.
After six weeks, eight of the twelve renewed. He had revenue, validated demand, and a detailed product spec based on real workflow data, not assumptions. Then we built the software in three months, with confidence about what would matter.
Compare that to the alternative: four months of building, then launching to no users, then learning everything from scratch.
The difference was not better engineering. It was a better understanding of what the MVP was for.
The Three MVP Categories Most Founders Get Wrong
The "land in app stores" MVP. Founder wants to build a consumer app. The MVP plan is the smallest app that can launch in app stores. This is usually wrong. Consumer demand can be tested with a waitlist, a landing page, a community, or a Substack before a single line of native code is written.
The "platform" MVP. Founder wants to build a marketplace or platform. The MVP plan is a small version of the platform. This is usually wrong. Marketplaces require both sides to show up at once, which is the actual hard problem. Test that with a concierge service before building software.
The "complete workflow" MVP. Founder wants to build a tool that replaces a customer's existing workflow. The MVP plan is a tool that handles the full workflow. This is usually wrong. Replace one step of the workflow first. Get evidence that customers want that step done differently. Then expand.
In each case, the temptation is to build the smallest version of the full vision. The right move is to build the smallest thing that tests whether the vision is worth pursuing.
What This Means for How You Plan Your MVP
If you are about to start building an MVP, run these five checks first.
One. Can you write the hypothesis in one sentence? If no, stop.
Two. Have you talked to at least ten people in your target customer segment about the problem before deciding on the solution? If no, stop.
Three. Could the hypothesis be tested without building software? If yes, do that first.
Four. If software is genuinely required, can you scope to one or two features instead of five to ten? If no, go back and cut more.
Five. Do you have success and failure criteria written down with numbers? If no, write them now.
These five questions will save you more time and money than any tool, framework, or methodology. Most founders skip them because they feel like delay. They are the opposite of delay. They are the difference between an MVP that teaches you something and an MVP that empties your bank account.
The Honest Reality
Most founders who get this wrong do not realise they got it wrong until the MVP launches and nobody cares. By then, the money and time are gone.
The founders who get it right look slower for the first six weeks. They talk to users. They sketch landing pages. They run manual experiments. They look like they are not building.
Then around week eight, they overtake the other group. They start building with confidence about what to build. By month three, they have shipped something users actually want. By month six, they have revenue.
The other group, by month six, is rebuilding the MVP with the lessons they should have learned in week two.
The MVP is not the smallest version of your product. It is the smallest thing that tells you whether to build your product at all. Treat it that way and most of the rest takes care of itself.