A Minimum Viable Product is the smallest version of a product that delivers core value to early users and enables validated learning. It's not about building the minimum product—it's about maximum learning with minimum effort.

The Core Concept

Not MVP: Stripped-down version of your ultimate vision with minimum features

Actually MVP: Simplest thing you can build to test your riskiest assumptions

The goal: Learn whether your core idea solves a real problem before investing heavily.

Eric Ries Definition

"The MVP 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."

Key words: Maximum learning. Minimum effort. Not: minimum features.

What "Minimum" Really Means

Minimum = Smallest test that validates or invalidates hypothesis

Testing "Do people want food delivery?" doesn't require building an app, logistics network, and payment system. MVP could be:

• Landing page describing service
• Manual fulfillment (you pick up food yourself)
• Text message ordering
• Limited to one restaurant

You're testing demand, not building final solution.

What "Viable" Really Means

Viable = Delivers enough value that people actually use it

Not "technically works" but "solves problem well enough that people choose to use it despite limitations."

If users try it once and never return, it's not viable even if it technically functions.

Types of MVPs

Smoke test: Landing page describing product, measure signups before building anything. Tests demand.

Concierge: Manual service delivered by humans, no product yet. Validates problem and solution.

Wizard of Oz: Appears automated but you're doing everything manually behind scenes. Tests user experience.

Single feature: One core capability done well. Tests specific value proposition.

Prototype: Clickable design or demo. Tests usability and concept.

Piecemeal: Combine existing tools to deliver service. Tests workflow without building.

Different tests for different hypotheses.

Common MVP Mistakes

Too much scope: Building for months instead of weeks. MVP takes 2-6 weeks, not 6 months.

Too little value: So minimal that users can't tell if it solves their problem. Not enough to validate anything.

Wrong assumptions: Testing secondary features before validating core value proposition.

Building instead of learning: Treating MVP as first product release instead of learning tool.

No hypothesis: Building MVP without clear question you're trying to answer. Random exploration.

No metrics: Launching MVP without defining what success looks like.

Perfection: Polishing MVP like it's final product. MVP should be rough but functional.

What to Include in MVP

Must include:

• Core value proposition (the one thing that solves the problem)
• Minimum functionality for users to experience value
• Feedback mechanism (how will you learn?)
• Way to measure success/failure

Can usually exclude:

• Edge cases and optional workflows
• Polish and visual design (functional is enough)
• Scalability (handle 10 users, not 10,000)
• Most features on your roadmap
• Marketing site and full onboarding

Depends on hypothesis:

• If testing "will people pay?" → need payment
• If testing "will people use it?" → payment can wait
• If testing "is manual process viable?" → no automation needed yet

MVP Success Criteria

Before building, define:

• What hypothesis are we testing?
• What would validate it? (specific metrics)
• What would invalidate it?
• How long will we test?
• Who are we testing with?

Example:

• Hypothesis: "Product managers want AI to prioritize feedback"
• Success: 40% of testers use it weekly, 60% say they'd pay
• Failure: <20% weekly usage
• Timeline: 4 weeks with 20 users
• Users: Product managers at seed-stage startups

Clear criteria prevent endless tweaking without learning.

After MVP: What Next?

If successful: Iterate toward product-market fit. Add features based on what you learned. Double down.

If failed: Pivot or kill. Did wrong customer segment respond? Different solution needed? Problem not painful enough?

If unclear: Run another test. Different customer segment? Different positioning? Different feature set?

MVP isn't the end—it's the start of learning cycle.

MVP ≠ Beta

MVP: Learning tool to test assumptions. Usually very rough. Small user base. Short timeframe.

Beta: Pre-launch version of real product. More polished. Broader user base. Longer testing.

MVP validates whether to build. Beta validates that you built it right.

Real-World MVP Examples

Dropbox: Demo video showing concept. Validated demand before building complex sync technology.

Airbnb: Founders photographed their own apartment, manually processed bookings. Validated marketplace before building platform.

Zappos: Founder photographed shoes at local stores, listed online, bought and shipped manually when orders came. Validated demand before inventory.

Buffer: Landing page with pricing, "learn more" clicked through to "we're building this, sign up for beta." Validated willingness to pay before coding.

Each tested riskiest assumption with minimum investment.

MVP for Different Product Types

SaaS product: Core workflow in simplest form. Manual backend. Limited features.

Marketplace: Single market, manual matching, constrained supply. Test liquidity.

Consumer app: One core feature, one platform (iOS or web, not both). Test engagement.

Developer tool: Basic API, limited functionality, good docs. Test integration and value.

AI/ML product: Fake it with humans initially. Test if outputs are valuable before automating.

When to Move Beyond MVP

Signs it's time to evolve:

• Strong product-market fit signals (high engagement, low churn, users asking for more)
• Validated core hypothesis
• Technical limitations blocking growth
• Can't onboard more users without better foundation
• Manual processes don't scale
• Early adopters frustrated by limitations

Premature scaling signals:

• Still iterating on core value prop
• High churn, low engagement
• Haven't validated business model
• Building features before validating basics

MVP to real product is gradual, not switch flip.

MVP Mindset

The hardest part of MVP isn't building—it's having discipline to build less.

Natural tendency: "Just one more feature, then it'll be really valuable"

MVP discipline: "What's the absolute minimum to test this assumption?"

Great product people fight the urge to over-build. Ship something embarrassingly simple but functional. Learn. Iterate.