What Is a Minimum Viable Product and How Do You Build One

The phrase minimum viable product has been so thoroughly misused that it has almost lost its meaning.

In most conversations, MVP has come to mean "early version with rough edges." A half-built product you release early with a disclaimer. Something you apologize for while shipping.

That is not what it means. And building to that definition is why so many first products take six months to launch and still do not work.

The real definition is shorter and harder to sit with.

An MVP is the smallest thing you can build that someone will pay for.

That is it. Minimum means no unnecessary scope. Viable means it actually solves the problem. Product means someone gives you money for it.

Where the Definition Goes Wrong

The word minimum is the one people get wrong most consistently.

Minimum does not mean low quality. It means no unnecessary features. There is a significant difference.

A product with a poor user experience is not minimum viable. It is just poor. A product that solves one problem extremely well, with nothing extraneous, is minimum viable.

The minimum is a scope decision, not a quality decision.

Most people building their first product treat minimum as permission to ship something unfinished. They launch a broken experience and call it an MVP. Then they wonder why nobody comes back. The answer is that viable has been dropped from the definition. A product that does not reliably deliver its promised outcome is not viable. It is just minimum.

The Two Questions That Define Your MVP

Before you build anything, answer two questions with specific, written answers.

Who is the one person this is for? Not a demographic. A specific person with a specific role, a specific problem, and a specific context. "Marketing managers at B2B software companies with under 50 employees who are trying to build their first content operation without a content team" is a person. "Professionals" is not.

What is the one outcome this delivers? Not a list of features. One outcome. The thing that makes the person who bought it better off than they were before. Write it in a single sentence without technical language.

If you cannot write these two answers in under five minutes, you are not ready to build yet. The clarity required to answer them is the same clarity required to build the right thing. Build without it and you will almost certainly overbuild.

For Service Businesses: The MVP Is Simpler Than You Think

If you are building a service business, the MVP problem is mostly solved.

Your service is the MVP. It exists the moment you describe it and a person pays for it. There is nothing to build before that. No website required. No onboarding flow. No documentation.

We covered this in the context of validating without quitting in how to validate a business idea. The pre-sale — someone paying a deposit before you have formalized anything — is the service MVP in its purest form.

The thing you then build is not the product. It is the delivery infrastructure. The process that makes it repeatable, scalable, and consistent across clients.

Most service founders skip this stage. They deliver each engagement entirely from scratch, reinventing the process every time. This keeps quality inconsistent and prevents the business from scaling. The real MVP work for a service business is building the repeatable delivery system, not the service concept itself.

For Product Businesses: The Scope Problem

If you are building a software product, a digital tool, or a structured information product, the scope problem is real and almost universal.

Here is how it typically unfolds.

You define the one problem the product solves. Then you add a feature that would make it more useful for some users. Then another that would help with onboarding. Then an analytics dashboard because clients will want to track their results. Then a reporting feature. Then an integration that makes it work better with another tool.

Six weeks later you are building what you initially estimated would take two.

Every feature addition felt justified. The product does need to help users onboard. Clients do want to track results. But each addition delays the test that actually matters: will someone pay for the core thing?

The discipline is brutal but the logic is sound. Before any feature addition, ask one question. Does this help the target customer get the core outcome faster or more reliably?

If yes, it might belong in the MVP. If it serves any other goal — making the product look more complete, appealing to a wider audience, preparing for future scale — it does not belong yet.

The Concierge Test

There is a technique for finding the true minimum that strips away every assumption about what needs to be built.

Before writing any code or designing any interface, ask: could I deliver this outcome to one person manually?

Not at scale. Not efficiently. Just for one person, doing every part of it by hand.

If the answer is yes, do that first. Deliver the outcome manually. Charge for it. See whether the person values the result. See what they actually use and what they ignore.

The manual process reveals what is essential and what is assumption. The parts they use become the features you build. The parts they never touch get cut before a single line of code is written.

Airbnb ran on spreadsheets and emails before their platform existed. Zapier's founders manually connected apps for their first users before building any automation. The Stripe founders personally processed the first transactions by hand.

This is not a workaround. It is a methodology. The constraint of doing it manually forces ruthless prioritization and produces better product decisions than any planning session.

When You Have Built Enough

There is a specific moment when an MVP is done. People often miss it because they are looking for completion rather than viability.

You have built enough when your target customer can get the outcome you promised without you explaining how.

Not when it looks finished. Not when it has every feature on the roadmap. When the person it was built for can use it and get what they paid for.

Ship at that point. The remaining features are not making the product viable. They are making it better. Better is something you build after you have proven the product is wanted. Not before.

The market will tell you what to build next. Assumptions built before shipping are expensive guesses. Customer behavior after shipping is evidence.

Once you have something shippable, the next question is how to put it in front of people who will pay. How to make your first sale online picks up exactly there.