What is an MVP (and what it is not)

The term minimum viable product is used so often that it has lost its meaning. People use it to mean "cheap first version" or "the product but smaller," and both readings lead teams in the wrong direction. Getting the definition right is the first real decision of your launch, because it shapes everything you build next.

The definition that actually helps

An MVP is the smallest thing you can build that still teaches you something real about your product. The useful version of the idea: it is the smallest experiment that tests the riskiest assumption in your business.

Every product depends on a few assumptions. People have this problem. They want it solved. They will use, or pay for, your solution. You can actually build it. One of those assumptions is riskier than the rest, because if it is wrong, nothing else matters. Your MVP should test that assumption first and ignore almost everything else. That framing is the whole reason MVPs work: they let you find out you were wrong while it is still cheap to be wrong.

What "minimum" really means

Minimum does not mean cheap, ugly, or broken. It means the least you can build and still learn. If a user cannot get through the core action because it is too unfinished, you have not built a minimum product, you have built a non-product, and it teaches you nothing.

So minimum is a scope decision, not a quality decision. You cut many features. You do not cut the quality of the features you keep. A login flow that half works does not prove people want your product. It proves you released a broken login flow. This is why we urge founders to scope tightly but build well, which is the balance in move fast without breaking the product.

What "viable" really means

Viable is the word most teams skip, and it is the one that matters most. Viable means a real user can get real value from the product as it is. Not "value once we add the next three features." Value now.

If the thing is not viable, the feedback you collect is worthless, because users are reacting to something that does not work rather than to your idea. A viable MVP produces honest evidence. A non-viable one produces random results you might mistake for evidence, which is worse than no data at all.

What an MVP is not

There are two common mistakes, one on each side of a good MVP.

The first mistake is the too-small MVP: a broken prototype that no real user would tolerate. It is cheap, it is fast to release, and it teaches you nothing because nobody can actually use it. Teams make this mistake when they confuse minimum with careless.

The second mistake is the too-big MVP: a full product with a slightly shorter feature list. It takes months, costs a lot, and by the time it is released you have risked everything before learning anything. Teams make this mistake when they scope around their whole roadmap instead of one question. If you find yourself unable to cut features because each one feels essential, you are making this mistake. The fix is in how to prioritize features and how to scope an MVP.

The mindset that makes it work

The goal of an MVP is to learn, not to impress. That is a hard change for a proud founder, because the first version will feel embarrassingly small next to the vision in your head. That is correct. If you are not slightly embarrassed by your MVP, you probably waited too long and built too much.

The teams that launch well stay committed to the vision and stay flexible about the first version. They know the MVP is a question, not an answer, and they are genuinely curious how customers will respond. As we put it in knowing what to build, being right about what to build is the hard part, and an MVP is how you find out cheaply. Once you have this framing, the rest of this guide, starting from the main guide, is about executing it well.