What a Good MVP Actually Looks Like (and What's Just Waste)

A good MVP is the smallest thing you can ship that lets a real person do a real job, and tells you whether they'll pay for it. That's it. Not the smallest thing you're comfortable showing people. Not a prototype with a waitlist bolted on. Not a feature-complete product with the pricing page stripped out. The job of an MVP is to answer one question as cheaply as possible: does this problem exist in the way I think it does, and will someone hand over money to have it solved?

The definition most founders are quietly using is wrong

When I talk to founders who are about to start building, they almost always describe their MVP as a reduced version of their full product. Features get cut, yes, but the shape of the thing is still the full vision, just with some bits deferred. That framing is the root cause of most MVP failures I see.

An MVP isn't a smaller version of your product. It's a different kind of thing entirely: a question with a form factor. The question is specific (can I get a paying customer for this?). The form factor is whatever makes that question answerable with the least build. Sometimes that's software. Sometimes it's a spreadsheet running behind a clean interface. Sometimes it's you doing the work manually while you figure out what to automate.

The moment you start making decisions based on how the thing should work at scale, rather than what you need to learn right now, you've stopped building an MVP and started building a product for a customer base you don't yet have.

What actually belongs in an MVP

There's a useful mental filter I use when scoping with founders: does this feature help the user complete the core job, or does it help the founder feel more comfortable launching? Most of what gets added in the second and third week of scoping is the latter. Onboarding flows, email sequences, admin dashboards, settings pages, multi-user permissions. All of that is comfort-building, not learning.

What belongs in an MVP is exactly this: the shortest path from a user having a problem to a user solving it with your thing. Everything else is a distraction with a plausible-sounding justification.

• The core action: the single thing the user came to do. If your product is a booking tool, it's making a booking. If it's a reporting tool, it's seeing a report. That action must work, end to end, without manual intervention from you.
• Enough context to make the action meaningful: the user needs to understand what they're doing and why it matters. That doesn't require polished copy; it requires clarity.
• A way to pay, or a clear commitment signal: if you're not collecting money, you're not validating willingness to pay. A waitlist signup is not validation. A pre-order or a paid pilot is.
• A feedback loop: you need to know what happened after the user did the thing. That might be a follow-up email you send manually. It doesn't need to be built.

What's just waste

The list of things that don't belong in an MVP is longer, and more expensive, than most founders expect when they're deep in the excitement of a new idea.

The strongest counterargument: "but quality matters for first impressions"

The pushback I hear most often, and it's a real one, is that a rough MVP damages trust. That early users form impressions fast, and a buggy, minimal product sends a signal that the whole venture is amateur. If you burn your first wave of potential customers with a half-finished experience, you don't get a second shot.

This is true, and I don't want to dismiss it. But there's a distinction being blurred here: the difference between quality and completeness. A good MVP is not a rough MVP. It's a narrow MVP. The core flow should be genuinely well-made. It should work reliably. The copy should be clear. The design doesn't need to be beautiful, but it should be coherent.

What it doesn't need is breadth. The impression a user forms is shaped almost entirely by whether the thing they came to do actually worked. A product that does one thing well and nothing else will be forgiven for its gaps by users who care about that one thing. A product that tries to do six things and does all of them shakily earns the "amateur" label far more reliably.

The quality argument is frequently invoked as a reason to add features, when the real fix it's pointing at is better execution of fewer things. Those are not the same prescription.

Where MVP scope decisions go wrong in practice

In my experience working with founders on early builds, scope creep rarely comes from carelessness. It comes from anxiety. Specifically, three flavours of it:

1. Fear of looking unfinished. Founders add features not because users need them but because they imagine a hypothetical sophisticated user who will dismiss the product if X isn't there. That user almost never exists in your first cohort.
2. Premature thinking about edge cases. "What if a user wants to do Y?" is a fine question for week six. In week one, the answer is: they email you, and you handle it manually. Build the exception handler when the exception actually happens.
3. Confusing the roadmap with the MVP. Features that definitely belong in v2 start drifting into v1 because the distinction between "this will be needed" and "this is needed now" isn't held firmly. A written scope document with an explicit "not in MVP" list, reviewed weekly, is the most underrated tool I know for keeping this in check.

A different way to think about minimum viable

The word "minimum" in minimum viable product does a lot of work, and most of it gets ignored. Viable means it actually works. Minimum means you've stripped out everything that isn't required for viability. The hard part is that minimum is not a fixed number; it's relative to your specific question.

If your question is "will freelancers pay for a tool that automates their invoice chasing?", your MVP might be an email template sequence you send manually on their behalf, with a £20/month direct debit set up via a payment link. That's it. No software at all. You've answered the question and collected revenue without writing a line of code.

If your question is "will e-commerce brands pay for better returns analytics?", you probably do need some software, because the manual version isn't credible in that context. But the scope is still narrow: one dashboard, one data source, one user, one invoice.

The point is to let the question drive the scope, not the other way around. Once you know exactly what you're trying to learn, the required surface area becomes much more obvious, and the things that seemed essential start looking optional.

The honest summary

A good MVP is narrow, honest, and built to answer one question. It does the core job well, collects a real signal of willingness to pay, and defers everything else. Most things founders call MVPs are actually v1 products with the roadmap compressed: broader than they need to be, built for customers they haven't yet found, and expensive in both time and money as a result. The fix isn't to build less carelessly. It's to be ruthlessly clear about what question you're trying to answer before you write a single line of code.