An MVP is a question, not a small product

"Let's start with an MVP" has become a default phrase in product conversations. Too often, it means "the full product, with fewer features and less polish". That version is expensive, slow, and usually teaches very little.

Start with the riskiest assumption

Every new product rests on assumptions: that a problem is painful enough, that a specific group of people will pay to solve it, that they will change how they work, that the solution is technically feasible. An MVP should target the one assumption that would kill the idea if it were wrong.

Some examples of what an MVP can be, depending on that assumption:

Is the problem real? Twenty structured interviews and a clickable prototype.
Will people pay? A landing page with pricing and a way to pre-order or book a demo.
Will they change their workflow? A narrow working tool for one team, used for real for a month.
Is it feasible? A technical spike on the hardest part, with no interface at all.

Build the smallest thing that can prove you wrong.

Viable still means usable

Minimum is not an excuse for a poor experience. If the product is used for real work, it must be reliable and clear enough that people's feedback is about the value — not about bugs and confusion. We would rather ship one workflow done properly than five done halfway.

Define success before launch

An MVP without success criteria becomes a permanent beta. Before building, we agree on what we expect to see — usage, retention after a few weeks, willingness to pay, time saved — and what we will do if we don't see it. That turns the launch into a decision point instead of a hopeful wait.

Common MVP mistakes we see

Most failed MVPs don't fail because the team was slow. They fail because the experiment was poorly designed. The patterns repeat:

Building for everyone. An MVP aimed at "small businesses" learns little; one aimed at "independent opticians with one shop" learns fast.
Measuring vanity. Sign-ups and page views feel good. Repeated use, time saved and willingness to pay tell you something.
Hiding the price. If paying is a core assumption, test it early — even with a simple pre-order or pilot agreement.
Polishing the wrong thing. Weeks spent on onboarding animations while the core workflow is still unproven.
No end date. Without a fixed learning period, an MVP drifts into a half-finished product nobody wants to stop.

A good MVP is uncomfortable in the best way: it forces a clear hypothesis, a clear audience and a clear moment of truth.

Then iterate, or stop

The outcome of an MVP is a decision: double down, change direction, or stop. All three are good outcomes if they come early and cheaply. The only bad outcome is spending a year building something before discovering what a month of learning could have told you.