What Minimum Really Means in Minimum Viable Product

Almost every student founder I have met has spent too long on their first version, showing up with three months of work, a polished interface, and a long list of features, only to ask why no one is using it, and the honest answer is usually that they built a product before they had a question, which means the version they shipped was not minimum at all but only an early one.

The phrase minimum viable product has lost most of its meaning over time, because founders use it to describe anything that is not finished, and articles use it to describe anything that has fewer features than the founder wishes the product had, while the original idea behind the phrase was much sharper and worth recovering.

The point of an MVP

The MVP is not a small version of your product, it is a test, and the test is whether anyone will use, pay for, or come back to something that solves a single specific problem, which means the product is only the means and the answer is what you are actually trying to buy with your time.

If you keep that frame in mind, the word minimum starts doing real work, because minimum means the least amount of building required to get a clear answer to your question, and anything beyond that, no matter how tempting it feels in the moment, is a delay rather than progress.

"The MVP is not a small version of your product, it is a test, and the test is whether anyone will use, pay for, or come back to something that solves a single specific problem"

The trouble is that building feels productive in a way that asking questions does not, and so code accumulates, designs improve, pages get added, and none of it actually answers the question you set out to test. By the time the product feels ready to show, the founder has often spent so much time on it that they can no longer hear honest feedback when it arrives, which is one of the most expensive failures available to an early team.

The first thing to define

Before you write any code or open any design tool, write down the question your MVP is trying to answer, and write it in a single sentence that names a real person, because the specificity of the question is what makes the rest of the work possible.

• A good question might be whether second year engineering students will pay five dollars a week for a study group matching app, or whether high school clubs in Lagos will use a free attendance tracker if you host it for them for a month, or whether a small business owner without a website will pay you to set one up in a weekend, since each of those examples points at a specific person and asks something specific enough to be answered.

• A weak question, by contrast, sounds like asking whether people will like your idea, whether users will find this helpful, or whether the thing will gain traction, and although these sound reasonable in the abstract, they cannot be answered with any confidence, which leads you straight back into building more features in the hope that quality will somehow produce the signal you are looking for. Quality does not produce signal at this stage. Specificity does.

What minimum really looks like

Once you have your question, the work becomes a hunt for the smallest thing that can answer it, and the answer is almost always much smaller than you expect, sometimes embarrassingly so. In many cases the smallest thing is not software at all, because a landing page can answer whether anyone is interested, a spreadsheet can answer whether your matching logic works for the first ten pairs, and a handful of one to one phone calls can answer whether the problem is even real before you build any tools to address it.

Founders who skip these lighter tests often find themselves with an app no one wanted and a wish that they had asked sooner.

If your question genuinely does need a working product to answer, then build only what the question demands and resist the urge to build anything more, because the features you do not build are as important as the ones you do, and each one you leave off the floor is a week you save, a piece of feedback you can hear clearly, and a customer conversation you can have sooner. The hardest discipline at this stage is leaving good ideas alone for now, but it is also the discipline that separates founders who learn quickly from founders who build for a year and arrive nowhere.

The viable part

The word viable is the other half of the phrase and is often skipped, which is unfortunate because it does meaningful work. Viable means the version you build has to be good enough that a real person can actually use it for its intended purpose, so a landing page is viable for testing interest, a clunky but working spreadsheet is viable for testing logic, and a half built app that crashes every other minute is not viable for testing anything except your willingness to patch it.

Viable does not mean polished, and it does not mean impressive, it only means functional for the specific test you are running. If you can answer your question with the version you have, then it is viable, and if you cannot, then it is not, no matter how much code sits behind the scenes.

"Viable does not mean polished, and it does not mean impressive, it only means functional for the specific test you are running."

Two common mistakes

1. The first mistake is building for the demo rather than the test, which happens when a founder designs their MVP around what will look good when shown to a professor or an investor, and although that produces a tidy presentation, it does not produce learning, because it tells you only whether people like a clean interface and not whether they will actually use the thing.

2. The second mistake is hiding behind the MVP label to avoid finishing anything, which happens when a founder has been calling something an MVP for six months and it still cannot answer a single question, and the problem in that case is rarely the version of the product but the absence of a question for it to answer.

What to do this week

If you are working on your first version right now, pause for an hour and try a simple exercise.

• write down the one question you most want answered about your idea,

• then write down the smallest thing that could give you an honest answer to that question,

• then look at what you are currently building and ask whether the work in front of you matches the answer to the second prompt or something larger.

• If the answer is something larger, cut features until the version on your screen matches the question, because the work that remains will move faster, and the answer you get when you finally show it to a real person will be cleaner and easier to act on.

A closing thought

The phrase minimum viable product is a discipline more than a recipe, because it asks you to spend less time building and more time learning, and founders who hold that discipline tend to ship sooner, learn more, and waste less of their early years on features that no one needed. The founders who do not hold the discipline tend to look back on a beautiful first version and wonder why it did not work, and the answer, almost always, is that they built a product before they had a question worth asking.