What is an MVP? How to build your first product without overbuilding

What an MVP is, and what it is not

A minimum viable product, or MVP, is the simplest version of a product that real people can use to solve a real problem. It includes only what is needed for one core job, and nothing else. The idea was popularised by the Lean Startup movement, but it applies just as well to a new internal tool, a mobile app or a SaaS platform inside an established company.

Two words in the name matter. Minimum means you leave out everything that is not essential. Viable means what remains still has to work well enough that people actually use it. An MVP that crashes or confuses users teaches you nothing, except that people do not like broken software.

An MVP is also not the same as a prototype. A prototype, such as a clickable design, tests whether an idea makes sense. An MVP tests whether people will really use it, and sometimes whether they will pay for it. Put simply, an MVP is not a smaller product. It is a faster way to learn.

Why start small

• You learn sooner. Real usage answers questions that planning meetings cannot.
• You spend less before you know. Budget goes into what users prove they need, not into guesses.
• You avoid dead features. Many features in finished products are rarely used. Starting small keeps them out.
• You can change direction. A small codebase is far easier to adapt than a large one built on wrong assumptions.
• You get to market. Early users, feedback and sometimes revenue arrive months earlier.

Deciding what goes in

Start with the problem, not the feature list. Write down who the product is for and the one job they need to get done. Then describe the shortest path through the product that completes that job, from sign-up to result.

Next, list every feature you have in mind and sort them into four groups, a method often called MoSCoW:

• Must have: without it, the core job cannot be done.
• Should have: important, but the job can be done without it for now.
• Could have: nice to have.
• Will not have (yet): deliberately left for later.

Only the first group goes into the MVP. A simple test helps: if users can still complete the core job without a feature, it can wait.

Types of MVP

Not every MVP needs to be fully built software. Depending on what you need to learn, lighter options can answer the question faster:

• Landing page MVP: a page that describes the product and asks people to sign up or pre-order. It tests demand before anything is built.
• Concierge MVP: you deliver the service manually to a few customers, learning exactly what they need before automating it.
• Wizard of Oz MVP: the product looks automated to the user, but people do the work behind the scenes.
• Single-feature MVP: a real product that does one thing very well, often the best choice for software and SaaS.

Building it well

Minimum does not mean careless. Put quality where it matters most:

• The core flow: the path to the main result should be fast, clear and reliable.
• Security and data: user accounts, payments and personal data need to be handled properly from day one.
• Analytics: track the key actions from launch, or you will not be able to learn from real usage.
• Proven tools: use established frameworks, services and, where sensible, no-code tools, so your effort goes into what makes the product different.
• Room to grow: keep the code clean and simple enough that the next version can build on it rather than replace it.

Measuring what you learn

Before launch, write down what success looks like. Useful signals include:

• Activation: how many new users complete the core job for the first time.
• Retention: how many come back and use it again.
• Willingness to pay: pre-orders, paid plans or signed pilots.
• Qualitative feedback: short conversations with real users about what worked and what did not.

Then make a decision: keep going and build the next most important feature, change direction based on what you learned, or stop before spending more. All three are good outcomes, because each one is based on evidence.

Common mistakes

• Too many features. The most common mistake. Every extra feature delays learning.
• Polishing too early. Perfect animations on a flow nobody uses are wasted effort.
• No clear question. If you do not know what you are testing, you cannot tell whether it worked.
• Not viable enough. A product that is too rough gets abandoned for the wrong reasons.
• Ignoring the results. Collecting feedback and then building the original plan anyway defeats the purpose.

Frequently asked questions