10 Minimum Viable Product Examples and MVP Types

A minimum viable product is not simply the smallest product a team can ship. Eric Ries defines an MVP as the version of a new product that enables the most validated learning about customers with the least effort; his explanation is preserved by Lean Startup Co..

That definition has two tests:

1. The version must expose an important customer or business hypothesis.
2. The evidence must be capable of changing the team's decision.

This guide uses illustrative MVP examples rather than unsupported origin stories about famous companies. Each example names the customer, hypothesis, real behavior, and next decision.

MVP examples at a glance

An MVP is distinct from a prototype. The MVP vs prototype guide explains when the artifact is for interaction learning versus real customer-value learning.

1. Concierge MVP

The founder manually delivers the result with a simple customer-facing process.

Illustrative example: Independent retailers upload a sales export. The founder cleans it, flags stock risks, and returns a replenishment worksheet within 48 hours.

• Hypothesis: Retail managers will use a prioritized risk list before placing an order.
• Real behavior: Submit data, review the result, make a buying decision, and repeat next cycle.
• Measure: Paid starts, time to first result, actions taken, repeat use, and manual minutes.
• Failure mode: Customers value the founder's consulting judgment but do not want a repeatable product workflow.
• Next step: Automate one stable data step while preserving human review.

See concierge MVP examples for more manual-delivery patterns.

2. Wizard of Oz MVP

Customers use an interface that appears product-like while people perform some operations behind it. The founder must not make deceptive automation or capability claims.

Illustrative example: A customer submits a travel constraint through a form and receives three options in a portal; a specialist assembles the options manually.

• Hypothesis: Customers understand the request flow and value the structured choice.
• Measure: Valid submissions, completion, option selected, response time, paid repeat use.
• Failure mode: The team proves demand for high-touch service but assumes software can reproduce expert judgment.
• Next step: Map every manual step and automate only stable rules.

3. Paid B2B pilot

A paid pilot tests a bounded organizational outcome, decision path, and implementation workflow.

Illustrative example: A security startup reviews one application environment for one team and delivers a prioritized remediation record in three weeks.

• Hypothesis: The target buyer will fund the outcome and provide the required access.
• Measure: Signed scope, implementation time, stakeholder participation, accepted result, renewal or expansion.
• Failure mode: Every pilot needs different integrations, stakeholders, and outcomes.
• Next step: Standardize the repeated use case and decline unrelated scope.

The paid-pilot examples guide covers scope and evidence in more detail.

4. Single-feature software MVP

The product completes one narrow job end to end.

Illustrative example: An agency owner imports an approved scope and receives a capacity-conflict list for the next four weeks.

• Hypothesis: Owners will repeatedly run this workflow before project kickoff.
• Measure: Eligible projects, valid imports, conflict list viewed, action completed, next-project reuse.
• Failure mode: The feature is technically narrow but requires a complex suite to create value.
• Next step: Improve the completion path before adding adjacent features.

“Single feature” does not mean one button. It means one complete customer result.

5. Landing-page demand test

A landing page tests whether a specific customer responds to a clear promise and next action. It is usually a demand experiment, not a full MVP, because no product value may be delivered.

Illustrative example: A page offers a fixed-scope supplier-quote comparison for small manufacturers. The call to action requests a fit call and a sample data file.

• Hypothesis: The target segment recognizes the problem and will enter a real evaluation.
• Measure: Qualified visits, fit calls, real inputs, accepted pilot offers.
• Failure mode: Broad low-intent traffic creates cheap signups with no buying evidence.
• Next step: Deliver a manual paid pilot to qualified respondents.

Use the landing-page MVP examples for traffic, CTA, and evidence design.

6. Preorder MVP

A preorder asks a buyer to pay before the product is available under clearly disclosed terms.

Illustrative example: A specialist hardware accessory is offered to a narrow professional group with a prototype demonstration, delivery window, limitations, and refund terms.

• Hypothesis: Customers will commit money under the stated delivery conditions.
• Measure: Qualified paid orders, refunds, support questions, and delivery feasibility.
• Failure mode: The team treats payments as proof it can manufacture, certify, ship, or support the product.
• Next step: Validate the riskiest production and compliance assumptions before scaling sales.

Consumer protection, payments, tax, product safety, and refund rules vary. Get qualified advice and never advertise capabilities or delivery certainty without support.

7. Manual marketplace MVP

The team manually recruits, qualifies, matches, and supports both sides before building marketplace infrastructure.

Illustrative example: A founder matches three vetted clinical-research writers with small biotech teams, handles the brief, and observes whether a useful engagement completes.

• Hypothesis: A concentrated buyer group and supplier group can complete a transaction under a repeatable rule.
• Measure: Qualified supply, qualified demand, match rate, time to match, completed transactions, repeat rate, contribution per transaction.
• Failure mode: The founder's personal judgment and relationships cannot be standardized or economically sustained.
• Next step: Automate search, qualification, or coordination only after repeated matches reveal stable rules.

8. Service-backed software MVP

Software handles part of the workflow while humans review exceptions or produce the highest-judgment output.

Illustrative example: A tool normalizes weekly exports and flags anomalies; an analyst reviews exceptions before delivery.

• Hypothesis: Automation reduces delivery effort without reducing trust or outcome quality.
• Measure: Human minutes per result, exception rate, correction rate, customer action, gross margin, repeat use.
• Failure mode: The business reports software economics while hiding substantial service labor.
• Next step: Separate current labor from target-state assumptions and automate repeated exceptions selectively.

9. Live cohort or content MVP

A live format tests whether a defined group will pay to complete a learning or implementation outcome before a large recorded library is built.

Illustrative example: First-time managers join a three-session role-clarity workshop and leave with a team operating agreement.

• Hypothesis: The participant values the completed operating artifact, not only the information.
• Measure: Paid enrollment, attendance, artifact completion, behavior change, referral or repeat demand.
• Failure mode: High engagement reflects the founder's live energy but not a repeatable result.
• Next step: Standardize exercises and measure outcomes before recording a self-serve course.

10. Integration MVP

The product delivers one result inside a tool the customer already uses.

Illustrative example: A support-team integration tags one defined cancellation reason and posts a weekly evidence summary to the team's existing workspace.

• Hypothesis: Embedding the result in the current workflow reduces adoption friction.
• Measure: Successful connections, first value, weekly use, actions taken, disconnects, support burden.
• Failure mode: Platform approval, permissions, or data quality become the product's real constraint.
• Next step: Prove one integration and one job before adding an ecosystem.

Choose the right MVP type

Start with the assumption:

Use customer validation to rank evidence. A waitlist, completed workflow, payment, renewal, and referral do not prove the same thing.

Write an MVP test card

Before building, record:

• Customer and trigger.
• Hypothesis.
• Riskiest assumption.
• MVP format and why it exposes that assumption.
• Customer input and completed result.
• Acquisition source.
• Price or commitment.
• Evidence and definitions.
• Time and cash limit.
• Safety, legal, privacy, and quality guardrails.
• Continue, revise, pivot, or stop rule.

No universal conversion threshold belongs here. Write a decision rule suited to the market, sample, and cost before seeing the result.

Common MVP mistakes

Minimum feature set with no learning goal

If the team cannot name the hypothesis, the release is merely small.

Prototype presented as a live product

A clickable design can produce interaction feedback but cannot prove real delivery, retention, or economics.

Free use treated as willingness to pay

Free participation may help test workflow. It does not prove a commercial decision.

Manual work hidden

Manual delivery is valid when disclosed and measured. It becomes misleading when customers or investors are led to believe the capability is automated.

Building for many segments

Different customers create different triggers, value events, and evidence. Start narrow enough to interpret the result.

Scaling before repeat value

Acquisition can magnify a broken activation or delivery flow. Prove the core job at its natural interval first.

The best MVP example is not the most famous company story. It is the format that lets your customer complete a real job while exposing the assumption most likely to invalidate your plan.