Minimum Viable Product

What is Minimum Viable Product?

A minimum viable product is the smallest version of a product that lets you test real demand and learn from actual users, rather than a stripped-down product for its own sake.

The origin is contested in a minor way. Frank Robinson, co-founder of SyncDev, says he coined the term in 2001, defining it as "that unique product that maximizes return on risk for both the vendor and the customer," big enough to drive adoption without becoming bloated and risky. Eric Ries gave the term the definition most founders use today: "the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort," published on his Startup Lessons Learned blog in 2009 and later expanded in The Lean Startup. Produck uses Ries's framing: an MVP exists to produce learning, not to ship a smaller version of your eventual roadmap.

Ries also flags a common misreading worth repeating here: MVP does not mean minimal. It means the version that teaches you the most per unit of effort, and sometimes that requires more polish than a "minimal" build would suggest, because a broken or confusing experience teaches you nothing useful.

Why it matters for product-market fit

An MVP is only valuable if you actually use what it teaches you. That is the part most teams skip. They ship the MVP, watch a few signups trickle in, and call it validated without ever systematically capturing what users actually did or said.

This is where Produck's loop comes in. Listen means the MVP is instrumented from day one: feedback and dropped sessions land somewhere durable instead of scattering across Slack threads and someone's memory. Diagnose means you group that raw signal into patterns: is this one loud user or a trend across your early adopters? Decide means you turn the diagnosis into an actual call on what to build next, not just a longer backlog. Ship closes the loop by shipping the change and watching whether the original complaint disappears.

An MVP without this loop is just a smaller product that eventually accumulates the same feedback chaos as a mature one. We wrote more on why this matters in what PMF actually is and why it matters for startups. The MVP is the vehicle. Product-market fit is the destination, and you only get there by treating the MVP as the first lap of product discovery, not a launch event.

When it works, and when it doesn't

It works when

• You have a specific, falsifiable hypothesis about what users want, and the MVP is built to test that hypothesis rather than to impress anyone
• You have a plan and the tooling to capture what happens after launch, so the test actually produces learning instead of just traffic
• You are early enough that the cost of being wrong is still small
• You are willing to change or kill the product based on what you learn, not just tweak the messaging around it

It falls short when

• The team treats "MVP" as a permission slip to ship something broken and calls confusion "user feedback"
• There is no system for capturing what users actually experience, so the learning that MVPs exist to produce never gets collected
• The market is mature enough that a bare-bones product gets compared against polished incumbents and loses on that basis alone, not on the hypothesis being tested
• Leadership treats the MVP's first version as the final answer instead of an input to the next decision

How to apply it

1. Write down the one thing you're trying to learn before you write any code. If you can't state it as a testable claim, you don't have an MVP yet, you have a guess.
2. Cut the feature list to whatever is required to test that specific claim, not whatever is required to look like a finished product.
3. Decide, before launch, exactly how you'll capture user behavior and feedback. Set up the intake now, not after the first complaint arrives.
4. Ship to a small, real audience rather than a broad one. Early adopters give you denser, more honest signal than a wide cold launch.
5. Route everything you hear back into one place you actually review, instead of leaving it in inboxes and screenshots.
6. Set a date to sit down and decide what the signal means. Turn the answer into a specific next build, then ship it and watch what changes.

minimum viable product vs prototype

A prototype and an MVP answer different questions. A prototype tests whether something can be built or whether an idea makes sense internally. It is usually shown to teammates or investors rather than real customers, and it is not expected to survive contact with a real market. An MVP tests whether real customers will actually adopt and pay for something. It goes into the hands of genuine users under real conditions, and its output is validated learning about demand rather than a proof of concept.