Minimum Viable Product (MVP)

Building a full product on an untested idea is the most expensive way to find out it was wrong. An MVP puts something real in front of customers within weeks, so their behaviour replaces guesses.

The signal is different too. Customers who pay are a far stronger sign than customers who say they like it, because paying costs them something. A small number of paying users also tells you where the product is actually used, which is often not where you expected.

An MVP keeps the decision cheap. If the evidence says stop, you have spent weeks, not a year. If it says continue, you know which part of the product to build next.

• Write the one problem and one customer the product serves.
• List every feature, then cut anything that is not needed to solve that problem once.
• Charge from the start, even a small amount.
• Release to a handful of real customers, watch how they use it and talk to them.
• Decide the evidence that means "continue", "change" or "stop" before launching.
• Add features only when customer use asks for them. Use a feature flag to try additions with a few users first.

An MVP does one job well enough that someone will use it, and nothing else. The word "minimum" means features are cut to the core. The word "viable" means what remains must still solve the customer's problem. A product that is only half working is not an MVP, it is a broken product.

The idea was popularised by Eric Ries in The Lean Startup. The point is learning, not launching small. Every MVP exists to answer a question such as "will this audience pay for it" or "does this save them real time".

An MVP is not the same as a prototype, which is a model built to look at or discuss and is rarely used for real work. It is also bigger than a minimum viable test, which can be as simple as a page describing the product.

Reading "minimum" as an excuse for poor quality. Adding features while waiting for a launch. Measuring signups instead of use or payment. Letting scope creep turn it into the full product.