Marcelo Pastorino, Software Developer

Minimum Viable Product

The smallest version of a product that delivers real value and produces validated learning about customers.

A minimum viable product (MVP) is the smallest version of a product that lets a team learn the most about whether customers want it, with the least effort. The point is not to ship a stripped-down product for its own sake; it is to turn an assumption into evidence as cheaply as possible.

Why it matters

Building the full vision before knowing whether anyone wants it is the most expensive way to be wrong. An MVP front-loads the riskiest question, will the right people use and pay for this, so the team spends its budget on learning instead of on features no one needed. It is the bridge between validating a SaaS idea and a fully scoped product.

Minimum and viable

The tension lives in both words:

  • Minimum, cut everything not required to test the core hypothesis. Defer settings, integrations, edge cases, and polish that do not change what you learn.
  • Viable, it must still deliver the core value well enough that a real user gets a real result. A broken or trivial product teaches nothing; the failure cannot be distinguished from a bad idea.

A useful test: if removing a feature does not change what you learn from the experiment, it does not belong in the MVP.

Common forms

An MVP does not have to be production software:

  • Concierge, deliver the outcome manually for a few users behind a simple interface, learning the real workflow before automating it.
  • Wizard of Oz, the interface looks automated while a human does the work behind the scenes.
  • Landing page or pre-sale, measure whether people commit (sign up, pay, sign a letter of intent) before building.
  • Single-feature product, one workflow done well, with everything else deferred.

The first three overlap with the demand-testing tactics in validating a SaaS idea; the MVP is where those tests turn into something users can actually adopt.

What to measure

An MVP is an experiment, so define the success threshold before launch:

  • Activation, do new users reach the core value (the “aha” moment)?
  • Retention, do they come back, or use it once and leave?
  • Willingness to pay, do they convert, or commit money? Tie this to pricing.
  • Qualitative signal, what do engaged users ask for, and what do they ignore?

Vanity metrics (signups, page views) feel good but rarely answer whether the product works. Weight behavior over stated intent.

Trade-offs

  • Too minimal and it is not viable: users cannot reach value, and a real idea looks like a dead one.
  • Too broad and it stops being an MVP: the team over-invests before learning, which is the cost it was meant to avoid.
  • An MVP measures a first reaction, not durable demand; validation continues after launch as you track retention and move toward product-market fit.

See also

  • Validating a SaaS Idea, Gathering evidence that a problem is worth solving before investing months building the wrong product.
  • Pricing Your First Product, Choosing a model and a price point for a SaaS product when you have little data.
  • B2B (Business-to-Business), How companies sell to other companies, and the buyers, models, sales motions, and metrics that make business products work.
  • B2C (Business-to-Consumer), How companies sell directly to individual people, and the models, metrics, and motions that make consumer products work.

On Wikipedia