What an MVP Actually Is (And Isn't)

The term "Minimum Viable Product" is one of the most misunderstood concepts in the startup world. It's not a buggy beta. It's not a stripped-down version of your full vision. An MVP is a deliberately scoped experiment designed to answer one critical question: Is this worth building further?

Getting that framing right changes everything about how you build.

Before You Write a Line of Code

The most common MVP mistake is starting with technology. Start instead with assumptions. Every product idea rests on a stack of beliefs about users, problems, and solutions. Your job is to identify the most dangerous assumption — the one that, if wrong, makes everything else irrelevant.

Write it down explicitly: "We believe [user] has [problem], and will [take this action] to solve it." Your MVP's only job is to test that sentence.

The MVP Spectrum: Choosing the Right Form

Not every MVP is a software product. The right form depends on what you're testing:

  • Landing page MVP: Test demand before building anything. Measure sign-ups, clicks, or pre-orders.
  • Concierge MVP: Deliver the solution manually. Learn what users actually need before automating it.
  • Wizard of Oz MVP: The user sees a product; behind the scenes, humans are doing the work.
  • Prototype MVP: An interactive mockup (no back-end) that tests UX and flow.
  • Single-feature app: One core feature, built and shipped — no extras.

Match the form to the question you're trying to answer. If you're testing desirability, a landing page is enough. If you're testing usability, you need something interactive.

Scoping: The Art of Saying No

Scope creep kills MVPs. Every feature you add increases build time, increases complexity, and muddies the signal you get from users. Here's a practical exercise to stay tight:

  1. List every feature you think your product needs.
  2. For each one, ask: "Does this help test our core assumption?"
  3. If the answer is no, move it to a "later" backlog — not the bin, but definitely not now.
  4. Whatever's left is your MVP feature set.

Building in Public vs. Building in Private

There's a genuine strategic choice here. Building in public — sharing progress, updates, and behind-the-scenes thinking — can build an audience before launch and attract early users. Building in private lets you move faster without external pressure and keeps your direction flexible.

For most first-time makers, building in public is underrated. The accountability and early feedback loops are worth more than most people expect.

How to Measure What Matters

Define your success metric before you launch, not after. Ask: what would it take for this MVP to tell you clearly that you should keep going? Be specific:

  • Not: "People seem to like it."
  • Yes: "30 people use the core feature twice within their first week."

If you hit that threshold, you have a signal. If you don't, you have equally valuable information — and no sunk cost to justify ignoring it.

After the MVP: What Comes Next

An MVP is the beginning of a learning loop, not a checkpoint on the way to "the real product." Once you have data, you face one of three paths: persevere (your assumption was right — go deeper), pivot (you learned something unexpected — adjust the direction), or stop (the problem isn't worth solving this way).

All three are valid outcomes. The only failure is building without learning.