Minimum Viable Product: The 'Product' Is the Part You Build Last

A minimum viable product is supposed to help you learn fast and cheap. Most are neither, because people build a small product when they should test a promise. Here is the version that actually works.

The phrase did real damage, and almost nobody noticed.

"Minimum viable product" was meant to be a tool for learning quickly and cheaply. Build the smallest thing, put it in front of real people, learn, repeat. Somewhere along the way it got hijacked. It became permission to build, just with the word "minimum" attached to make the building feel disciplined. So founders spend three months on their "minimum" product, ship it, and discover the same thing they would have discovered in a week if they had tested the idea instead of building a smaller version of it.

The problem is the middle word. We hear "product" and we start building. But in a real minimum viable product, the product is the last thing you should make, not the first.

What is a minimum viable product?

A minimum viable product is the smallest, cheapest thing you can put in front of real people to learn whether they actually want what you are offering. The key word is not "product." It is "learn." The entire purpose is to buy the maximum amount of validated learning for the minimum amount of effort, and very often the fastest way to learn whether people want something is not to build a small version of it at all. It is to make them a clear promise and see if they commit. The product, the thing you actually build, comes after the market has told you it is worth building. Treating the MVP as "a small product to ship" gets the order exactly backwards.

To see why building first is so costly, look at what happens to most of what gets built.

Why most MVPs are still too big

Because "minimum" is doing no work. The instinct is still to build, and that instinct buries you in features nobody asked for.

Here is the uncomfortable evidence. When Pendo analyzed product usage across the software industry, it found that 80 percent of features in the average product are rarely or never used, and that around 12 percent of features drive most of the actual usage. Read that again. Even fully funded, mature products waste the overwhelming majority of what they build. Now picture a solo founder trying to guess, before launch, which features matter. The odds are terrible. Most of what goes into a first "minimum viable product" is destined to be the 80 percent that never gets touched.

So the typical MVP is not minimum at all. It is a pile of guesses, most of them wrong, dressed up as discipline. You spend your scarcest resource, time, building the features you imagine people want, when the entire point was supposed to be finding out what they actually want before you build.

Sell the promise before you build the product

The fastest MVP is usually not software. It is an offer.

Before you build anything, make a clear promise: here is the outcome I will deliver, here is who it is for, here is what it costs. Then put that promise in front of real people and watch what they do. If they commit, money, a deposit, a signed yes, you have learned the one thing that matters, and you have not built a line of anything yet. If they do not commit, you just saved yourself the three months.

Once people say yes, deliver the outcome by hand for the first few. Do the work manually, behind the scenes, however unglamorous. This does two things at once. It proves the demand is real, because people are paying, and it shows you exactly which parts are worth automating, because you feel the pain of doing them yourself. Only then do you build, and now you are building the 12 percent that matters instead of guessing at the 80 percent that does not.

Call it a minimum sellable promise. It is viable the moment it produces a real commitment, and it almost always beats a minimum viable product to the only answer that counts.

What 'viable' actually means

Viable does not mean functional. It means it generates a real signal.

A common mistake is to judge an MVP by whether it works. Wrong test. The question is whether it produces a clear yes or no from the market. A landing page that does not do anything except take pre-orders is more viable, by this definition, than a fully working app that nobody has agreed to pay for, because the landing page gives you a real answer and the app gives you only your own hope reflected back.

So before you build, ask: what is the smallest thing I can put in front of real buyers that will force an honest yes or no? Build that. Everything else is premature.

So where does Noli come in?

The real reason people over-build is that the alternative, running a scrappy test, talking to buyers, delivering the first orders by hand, is itself a pile of work, and doing it alone is exhausting. So it feels easier to just build the product and hope. Building is lonely but straightforward. Testing is messy and takes hands you do not have.

That is the gap Noli fills. Treat your MVP as a tight project with a hypothesis and a deadline, and hand the legwork to a team. Noli's project manager structures and paces the test, the marketer builds the offer and the landing page, and the business-development side works the people who respond, all from one shared memory of your business. You decide what promise to test and read the market's answer. The team handles the execution that usually pushes founders back toward just building something. You can see how the team works here.

Because the goal was never to build a smaller product. It was to learn, before you build, that there is a market worth building for.

What to do this week

Take whatever you are itching to build and do not build it. Instead, write the promise it makes in one clear sentence, attach a price, and put it in front of real potential buyers this week with a way to commit.

Count the commitments. If they come, build, and build only what those first customers actually need. If they do not, you just dodged the most common and most expensive mistake in business, and it cost you a week instead of a season.

The minimum viable product was always supposed to be about learning the fastest, cheapest way possible. The product is the reward you earn after the market says yes. Build it last, not first.

Sources

About 80% of features in the average software product are rarely or never used, with roughly 12% of features driving most usage: Pendo, "The 2019 Feature Adoption Report." https://www.pendo.io/resources/the-2019-feature-adoption-report/

FAQ

What is a minimum viable product (MVP)?

A minimum viable product is the smallest, cheapest thing you can put in front of real people to learn whether they actually want what you are offering. The key word is learn, not product. Often the fastest way to learn is not building a small version of the product at all, but making a clear promise and seeing if people commit to it.

Why do most MVPs fail to teach anything?

Because they are still too big. Pendo found that 80 percent of features in the average software product are rarely or never used, while around 12 percent drive most usage. A typical MVP is a pile of guesses about which features matter, most of them wrong, so founders spend months building what a one-week test of the promise would have answered.

Should I build my product before selling it?

No. Make a clear promise first: the outcome you will deliver, who it is for, and what it costs, then put it in front of real people. If they commit money or a signed yes, deliver the outcome by hand for the first few customers. That proves demand is real and shows you exactly which parts are worth automating before you build anything.

What does viable actually mean in an MVP?

Viable does not mean functional; it means the test generates a real signal. A landing page that only takes pre-orders is more viable than a fully working app nobody has agreed to pay for, because the page forces an honest yes or no from the market while the app only reflects your own hope back at you.

How do I test a product idea in one week?

Write the promise your product makes in one clear sentence, attach a price, and put it in front of real potential buyers with a way to commit. Count only the commitments. If they come, build only what those first customers actually need. If they do not, you dodged the most expensive mistake in business and it cost a week instead of a season.