What an MVP Actually Is (and What It Is Not)

The phrase minimum viable product gets used so loosely that it has almost stopped meaning anything. Some people use it to describe a polished first version. Others use it as an excuse to ship something broken. Neither is right, and the confusion costs founders months of work.

An MVP is the smallest thing you can put in front of real users that lets you learn whether your core assumption is true. The key word is learn. If a feature does not help you test the assumption, it does not belong in the MVP, no matter how obvious or easy it seems.

Start with the assumption, not the feature list

Every product rests on one risky belief. For a scheduling tool it might be that small clinics will let software send reminders on their behalf. For a marketplace it might be that sellers will list without being paid to. Write that belief down in one sentence before you open a code editor. Everything you build should point at that sentence.

Once the assumption is explicit, the feature list shrinks on its own. You do not need user roles, billing tiers, or a settings page to find out whether clinics will trust automated reminders. You need one clinic, one reminder, and a way to see what happened.

What an MVP is not

• It is not a prototype. A prototype is for you. An MVP is for users, and users have to be able to do the real job with it.
• It is not a beta of the full product. If you are building every planned feature at lower quality, you are not building an MVP, you are building a worse version of the final thing.
• It is not an excuse for a bad experience. The slice you ship should be small, but the slice itself should work well end to end.

How to know when it is done

You are done when a stranger can complete the core job without your help, and you have a way to observe whether they come back. That observation might be a database table, an analytics event, or simply a follow-up email you send by hand. Instrumentation does not have to be fancy, but it has to exist, or you will ship and learn nothing.

A useful test is to describe the product in one sentence that includes a verb. If the sentence needs a comma and the word also, you have two products. Pick one.

What happens after

If the assumption holds, you add the next riskiest thing. If it fails, you have saved yourself from building a complete product that nobody wanted. Both outcomes are wins. The only losing move is spending six months on something you could have tested in six days.