MVP vs MMP: When to Stop Building and Start Shipping

The MVP Myth

The Minimum Viable Product was defined by Eric Ries as "the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

Notice what it doesn't say: the smallest possible product. It says maximum learning with least effort. These are different things.

Most teams interpret MVP as "ship whatever we have" — a half-finished product with obvious gaps, delivered with an apologetic "this is just v1." That's not an MVP. That's an alpha.

The other failure mode: "our MVP needs to be polished and complete before we show it to anyone." That's a 6-month delay to not learn anything faster.

What a Real MVP Looks Like

A real MVP solves one specific problem for one specific type of user, end to end, with enough quality that a user would actually use it in their real work.

The test: would a target user pay for or meaningfully engage with this, as it exists today, to solve a problem they actually have?

If yes: MVP. If no: not there yet.

This means an MVP can be:

• A landing page with a waitlist form (testing demand)
• A spreadsheet + a Typeform (testing workflow without code)
• A Figma prototype (testing usability)
• A hand-operated service that looks like software from the outside ("Wizard of Oz" MVP)
• A working product with a very narrow feature set

The MVP is about the validation goal, not the delivery format.

The MMP: Minimum Marketable Product

The MMP is where most SaaS product launches should actually target. It's the smallest product that can be successfully marketed and sold to real customers at real prices.

An MMP has:

• A complete core user journey (not just a happy path stub)
• Enough polish that users don't feel they're beta testing your product
• The minimum features required for the target customer to get value without workarounds
• A working payment flow (for paid products)

The difference from MVP: an MVP is for validation. An MMP is for acquisition. You can charge for an MMP. You can run ads to an MMP. You can ask customers for referrals after they've used an MMP.

How to Identify Your MMP

Map the minimal user journey:

1. User discovers the product (from where?)
2. User signs up (what's the minimum required?)
3. User reaches the value-delivering feature (how?)
4. User gets value from that feature (what does "value" look like?)
5. User wants to return (why?)

Every feature that isn't on this critical path is a candidate for cutting from v1. Not forever — for v1.

Then ask: what's the minimum set of supporting features that enables this journey without the user hitting a blocker and leaving?

The answer to that question is your MMP scope.

The Features That Always Seem Essential (But Often Aren't)

Notifications: Users can check manually in v1. Add notifications after you've confirmed they're coming back without them.

User management / team features: Ship single-user first. Teams come after you have individual users who want to collaborate.

Export/import: Users don't need to migrate data they don't have yet. Build this after retention proves they're accumulating data worth keeping.

Mobile app: Web-first unless mobile is the product. A responsive web app serves mobile users in v1.

Admin panel: Manage early customers manually. An admin panel becomes valuable after you have more customers than you can manage manually.

Search: Add when users have enough content to need it. Early users don't.

API: Unless B2B with API access as a core value prop, skip until v2.

When to Stop Adding Scope

The most effective forcing function: fix your launch date and work backward.

Given a launch in 8 weeks, which features can be completed with quality? That's your MMP scope. Features that don't fit move to the post-launch backlog.

This sounds arbitrary. In practice, it produces better products. Constraints force prioritization. Prioritization reveals what actually matters. What actually matters, shipped, beats what might matter, unshipped.

The Feedback Loop That Matters

The whole point of shipping early is accelerating the feedback loop. But this only works if you're talking to users.

For the first 3 months after launching, your primary engineering inputs should be user conversations, not internal intuition. Set up a mechanism to hear from users weekly — a Slack community, a monthly user call, or simply reading every support ticket yourself.

The questions that unlock the next roadmap:

• What did you try to do that you couldn't?
• What almost made you give up?
• What do you wish existed?
• Who else would benefit from this?

These answers build the backlog for v1.1 through v2, grounded in real problems rather than assumed ones.

One Principle

Build the simplest thing that creates a complete loop: user has a problem, product solves it, user is satisfied, user comes back.

Everything else is elaboration. Elaboration can wait.