Minimum Viable Product Development: What It Is Not

Half the arguments founders have about their MVP are really arguments about what the term means. One person is picturing a rough prototype, another a stripped-down but polished product, a third a public launch with a waitlist. Until everyone is working from the same definition, scope discussions go in circles.

The fastest way to get aligned is often to clear away the wrong definitions first. Here are six things minimum viable product development is not.

1. It Is Not a Low-Quality Product

The “minimum” in MVP describes scope, not craftsmanship. An MVP does fewer things than the eventual product. The things it does, it should do reliably.

If your MVP handles payments, the payment flow needs to work every time, handle failures gracefully, and not lose money. If it stores customer data, that data needs to be reasonably secure. Cutting corners on the features you did choose to include does not make the product more minimal — it makes it untrustworthy, and untrustworthy products produce unreliable evidence.

The right mental model: build a narrow slice of the product to a real standard, not the whole product to a poor one.

2. It Is Not a Prototype

A prototype exists to explore or communicate an idea. It might be clickable screens with no backend, or a rough build that falls over if you use it wrong. That is fine, because its job is to answer “does this design make sense” or “can we show this to a stakeholder.”

An MVP exists to generate evidence from real usage. Real people complete real tasks and their behaviour tells you whether the assumption holds. That only works if the product actually functions. A prototype and an MVP answer different questions, and building one when you needed the other wastes weeks.

3. It Is Not a Public Launch

You do not need a launch announcement, a Product Hunt post, or a marketing site to have an MVP. You need users — but that can be five target customers in a closed pilot.

In fact, a quiet pilot is often better for early validation. A small, relevant group gives you deep feedback and forgives rough edges. A public launch spreads your attention thin, invites users who are not your target, and turns every bug into a reputation problem before you have learned anything.

Launch loudly later, once the evidence says the product is worth launching.

4. It Is Not “Version 1 of the Real Product”

An MVP is an experiment. Some of what you build will survive into the real product. Some of it should be thrown away once you have learned what you needed to learn.

Treating the MVP as the permanent foundation leads to over-engineering — building for scale you do not have, adding configuration for use cases you are guessing at, choosing architecture for a product you have not validated. Build the MVP to be correct and safe, not to be the final architecture. You can scale a validated MVP without over-engineering the unvalidated one.

5. It Is Not Fully Automated

Behind the customer-facing experience, an MVP can run on manual work. If your product will eventually match freelancers to projects with an algorithm, the MVP can do that matching by hand. If it will generate reports automatically, a person can compile the first ones.

This is not cheating. It lets you test whether people want the outcome before you invest in building the machinery that produces it. The rule is that the customer’s experience should feel real and reliable; what happens backstage can be a spreadsheet and a human.

6. It Is Not a Fixed Feature List You Committed to Months Ago

The feature list you wrote at the start of MVP development is a hypothesis about what is needed to test your assumption. As you build and show early versions to users, that hypothesis should update.

Founders who freeze the feature list on day one often ship things nobody uses and miss things everyone asks for. The discipline is not “never change scope” — it is “change scope based on evidence, not on the last conversation you had.” Prioritise for the fastest possible learning, and revisit the list every sprint.

So What Is It?

Minimum viable product development is	It is not
A narrow product built to a real standard	A full product built poorly
A working system real users can use	A clickable prototype
Often a small closed pilot	Necessarily a public launch
An experiment, partly disposable	The permanent architecture
Manual behind the scenes where possible	Fully automated from day one
A hypothesis that updates with evidence	A frozen feature list

Put simply: minimum viable product development is building the smallest reliable product that lets real people complete one meaningful task, so you can learn whether the idea works before spending on the full build.

For a fuller walkthrough of the process itself, see our minimum viable product development founder’s guide, and Atlassian’s MVP guide covers the underlying build-measure-learn loop.

Frequently Asked Questions

Is an MVP just a cheaper, lower-quality version of the product?

No. An MVP is a smaller product, not a worse one. The features it includes should work reliably and safely. What makes it minimum is the number of problems it solves, not the standard to which it solves them.

Does building an MVP mean I have to launch it publicly?

Not necessarily. An MVP needs real users to generate real evidence, but that can be a small closed pilot with a handful of target customers rather than a public launch. The point is learning from actual usage, not press coverage.

Is a prototype the same as an MVP?

No. A prototype demonstrates how something could work and is often not built on real infrastructure. An MVP is a working product that real people use to complete a real task, which is what makes its evidence trustworthy.

Can an MVP be a manual process instead of software?

Partly. The customer-facing experience usually needs to be real software, but the work behind it can be manual during early validation — a human doing what an algorithm will eventually do. This is a legitimate way to test demand before building automation.