An MVP Is A Scientific Experiment Designed To Reduce Uncertainty

In the first year of my career, I worked on four software projects. Each one took three months. Each had a team of three to four people. Only one of the projects was actually used by the customers it was built for.

The other three were waste. Avoidable, expensive waste.

I can’t share details due to contract agreements, but I don’t need to. The numbers carry the point: nine months of collective engineering effort, gone. Not because anyone worked poorly. Not because the code was bad. Because nobody asked, before writing a single line, whether the thing needed to exist at all.

That is the most common and most costly mistake in software product development. Teams treat an MVP as a small product, when it should be a scientific experiment designed to reduce uncertainty.

Three concepts

A scientific experiment is a structured method to test a hypothesis and collect data that informs a decision. The critical property is that it must be falsifiable: you define what success and failure look like before you run the test. An experiment that can only succeed is not an experiment. It is a performance.

Uncertainty is the distance between what you believe about your market and what is actually true. Startups do not fail primarily because of competitors or funding. They fail because they built something nobody needed, and they built it for months before finding out.

An MVP is the minimum artifact needed to answer a specific question about your business. Not the first version of a product. Not a prototype. The instrument you build to run one test.

The experiment

Science has a clean structure: hypothesis, experiment design, data collection, conclusion.

What makes something scientific is not the equipment or the field. It is the commitment to being proven wrong. An experiment is designed to produce a result that can change your mind. If you already know the answer you want and are just generating evidence for it, you are not running an experiment.

Every assumption you make about what users want, what they will pay, and what problem they actually have is a hypothesis. Not a fact. A hypothesis. The sooner you treat it that way, the more honestly you will approach the question of how to test it.

An experiment without a pre-defined hypothesis is just noise. You will interpret whatever data you get in whatever way is most convenient. Every team I have seen do this rationalizes it the same way afterwards: “We learned a lot.” Maybe. But they did not learn what they set out to learn, because they never decided what that was.

The enemy

Uncertainty is not a problem you solve once. It is the permanent condition of any business doing something new.

Eric Ries’ The Lean Startup draws heavily from Toyota’s manufacturing philosophy, which treats waste as the primary operational enemy. In software product development, the most expensive form of waste is building something nobody needs. Not building it badly, but building it at all.

I read The Lean Startup twice. The first time, most of it passed through without leaving a mark. I understood the words but it all was too “foreign” to me. The second time, after trying to create a startup myself and failing hard, I could not get through three pages without running out of note paper. What changed was not the book, it was the context I brought to it. The book landed differently once I had experienced what the clients of those three past projects had felt, or at least, what I imagine they felt.

The goal of a startup at its earliest stage is not to grow. It is to reduce uncertainty fast and cheaply. Growth follows from knowing what is true. Everything before that is a bet.

Two types of uncertainty matter most early on. The first is desirability: do people actually want this? The second is viability: can you build and sustain it at a price they will pay? Both need to be tested. Most teams only worry about the second one.

The MVP as the instrument

An MVP is the experimental apparatus. The minimum artifact needed to test one specific assumption.

What separates an MVP from a prototype is intent. A prototype tests whether something can be built. An MVP tests whether it should be. They can look identical from the outside. The difference is in the question they were designed to answer.

The right way to design an MVP is backwards. Not “what is the smallest version of our product?” but “what is the single assumption that, if wrong, kills this business?” and then “what is the cheapest way to test that assumption?”

Sometimes the answer is a product. More often it is a landing page, a manual process, a spreadsheet, or ten conversations with potential customers. The point is not to ship something small. The point is to find out what is true as cheaply as possible.

There is a rationalization I have heard more than once, usually from developers who built something they knew going in had no real validation: “The client wanted it, I built it, it was a win-win.” It was not. The client spent money and time on something that did not work. The developer produced waste, collected payment, and everyone moved on without learning what they actually needed to learn. The world has one more failed product in it and everyone involved has told themselves a comfortable story about why that is fine.

Knowing a project will likely fail and doing it anyway for the money is a choice, not neutral. The consequences land on real people and real budgets.

Closing

Once you see an MVP as an experiment, every decision about scope becomes answerable with one question: does this help test the hypothesis faster?

Not “is this a good feature?” Not “does the client want this?”.

You stop building what you do not need to learn what you must know. That is the payoff. Not just efficiency. Honesty about what you are doing and why.

An MVP is not the first version of your product. It is a scientific experiment designed to reduce uncertainty, and the sooner you treat it that way, the less you will waste building the wrong thing.