← Go Back

Minimum Viable Product (MVP)

What is a Minimum Viable Product?

A Minimum Viable Product (MVP) is the smallest version of a product that delivers real value to users and gives you enough feedback to learn what to build next. It’s “minimum” to reduce waste; “viable” so it’s actually used.

Use it when: you have a hypothesis about a user need or business model and want to test it with real use and real feedback instead of building everything upfront.

Copy/paste template

  • Core hypothesis: We believe [user segment] will [behaviour / outcome] if we [deliver this value].
  • One thing we’re testing: [e.g. willingness to pay, retention, usage of one flow]
  • Minimum scope: [short list of must-haves; everything else is out]
  • Success signal: We’ll know it’s working when [metric / behaviour] within [time].
  • What we’re explicitly not building yet: [list]

Why MVPs matter

  • Reduces cost and risk by learning before overbuilding.
  • Gets you to market faster so you can validate with real users.
  • Focuses the team on one or two key questions instead of a long feature list.
  • Creates a foundation for iteration rather than a one-off launch.

What a good MVP includes

Checklist

  • [ ] A clear hypothesis (what you’re testing and why).
  • [ ] One primary value delivered well, not many half-done features.
  • [ ] A defined success signal and time window.
  • [ ] Real users (not just internal testing).
  • [ ] A path to iterate based on what you learn.

Common formats

  • Concierge MVP: you deliver the value manually to learn the workflow before automating.
  • Single-feature MVP: one core feature done well to test demand or behaviour.
  • Landing page / smoke test: test interest or positioning before building the product.

Examples

Example (the realistic one)

A team believes freelancers will pay for a simple tool that turns time logs into invoices. MVP: a single flow (log time, add rate, download PDF). No accounts, no templates, no integrations. Success = 50 people download an invoice in the first month. They’re not building reminders, multi-currency, or branding yet.

Common pitfalls

  • “Minimum” without “viable”: the product is so bare that no one uses it. → Do this instead: ensure the one thing you offer works and is desirable enough to get real use.
  • Calling a prototype an MVP: prototypes simulate; an MVP is a real product people use. → Do this instead: if it’s not in users’ hands for real use, call it a prototype.
  • No clear hypothesis: you’re “just shipping something”. → Do this instead: write what you’re testing and what would change your mind.
  • Scope creep before launch: “one more feature” delays learning. → Do this instead: lock scope; learn from what you ship, then iterate.
  • MVP vs prototype: a prototype explores or communicates an idea; an MVP is a live product used by real users to learn. Different goals.
  • MVP vs beta: beta usually implies a fuller product in testing; MVP is deliberately minimal to validate one thing.
  • MVP vs MLP (Minimum Lovable Product): MLP emphasises delight and polish; MVP emphasises learning. Choose based on whether you’re testing demand or experience.
  • Problem statement – define the problem before you decide MVP scope.
  • Lean canvas – structure for turning an idea into testable assumptions; MVP is the build step.
  • Prototype – use when you’re not yet ready to put a real product in users’ hands.
  • User research – to form and refine the hypothesis your MVP tests.
  • Iterative design – MVP is the first iteration; then you learn and improve.
  • A/B testing – one way to improve after MVP; test changes with evidence.
  • Value proposition – the promise your MVP should deliver on.

Next step

Write your core hypothesis and one success signal using the template above. If you haven’t yet framed the problem, read Problem statement first.

Related Terms