What Is a Minimum Viable Product (MVP) and How to Build One

The Core Idea Behind an MVP

A Minimum Viable Product (MVP) is the simplest version of a product that allows a team to collect the maximum amount of validated learning about customers with the least effort. The concept was popularized by Eric Ries in The Lean Startup (2011) and has become foundational vocabulary in startup culture.

The key insight is that most startups fail not because they could not build their product, but because they built something nobody wanted. An MVP tests the riskiest assumptions about a business idea — primarily, whether a real problem exists, whether customers will pay to have it solved, and whether your solution solves it acceptably — before committing to full-scale development.

What an MVP Is Not

Common misconceptions undermine MVP effectiveness. An MVP is:

• Not a prototype — a prototype tests technical feasibility; an MVP tests market desirability and business viability with real users.
• Not a beta — a beta is a near-complete product tested for bugs. An MVP may not be a product at all.
• Not as minimal as possible — removing the wrong features creates a product that cannot demonstrate its core value proposition. The word "viable" matters as much as "minimum."
• Not a permanent state — an MVP is a learning vehicle, not the final product. You iterate based on what you learn.

Types of MVPs

MVPs come in many forms, ranging from no-code experiments to manual processes to pared-down software:

• Concierge MVP — manually deliver the service that would eventually be automated. Before building software, do the work by hand to confirm the problem and test your service model. Zappos founder Nick Swinmurn photographed shoes from local stores and posted them online before building any inventory or fulfillment system.
• Wizard of Oz MVP — the front-end looks like an automated product but humans operate it manually behind the scenes. Customers experience the product; the team learns what they want.
• Landing page MVP — describe the product and its value proposition on a simple website. Measure signups or pre-orders before writing a line of product code. Dropbox famously launched a video demo before any functional product existed and collected 75,000 email addresses overnight.
• Single-feature MVP — build only the one feature that delivers the core value proposition, with everything else removed. Instagram launched as a photo-sharing app with filters; messaging, stories, and reels came later.
• Piecemeal MVP — assemble existing tools and services (Shopify + Zapier + a spreadsheet) to deliver your service manually before investing in custom development.

How to Define Your MVP

The hardest part of MVP development is deciding what to cut. A useful framework:

1. Write down your riskiest assumption — the one belief, if wrong, that kills the business. Usually it is some version of: "customers have this problem badly enough to pay for a solution."
2. Design the smallest test that validates or invalidates that assumption — you do not need a full product to test whether people will buy; a conversation, a landing page, or a manual service often suffices.
3. Define success criteria before you build — how many signups, what conversion rate, what NPS score constitutes confirmation? Vague metrics lead to motivated reasoning.
4. Build only what the test requires — everything that does not serve the test is scope creep.

Building Your First MVP: Practical Steps

Once you have defined the minimal scope, the build process follows a disciplined sequence:

• Identify your target user precisely — "small business owners" is too broad. "Solopreneur freelance designers billing under $200K/year" is testable. The narrower the initial audience, the faster and cheaper the test.
• Recruit real users — ideally 5–10 target users who have the problem you are solving. Cold outreach, community forums, LinkedIn, and your own network are all valid channels.
• Use no-code or low-code tools — for most MVPs, building in Webflow, Bubble, Airtable, Notion, or even Google Forms is faster and cheaper than custom code. Save engineering cycles for features that provide genuine competitive moats.
• Launch faster than feels comfortable — most first-time founders wait too long. If you are not embarrassed by your MVP, you launched too late (a paraphrase often attributed to Reid Hoffman).

Measuring and Learning From Your MVP

The MVP itself is not the goal — the learning is. Define metrics tied to your riskiest assumption before launch:

• Activation rate: what percentage of signups complete a meaningful action (the aha moment)?
• Retention rate: do users come back? Retention is the most reliable signal that a product creates real value.
• Willingness to pay: will people give you a credit card, even in a limited beta?
• Net Promoter Score (NPS): would users recommend this to a friend?

Combine quantitative metrics with qualitative interviews. Numbers tell you what is happening; user interviews tell you why.

When to Pivot vs. Persevere

After your MVP tests, you face the most important strategic decision: pivot or persevere? Persevere means doubling down on the current approach with new learning. Pivot means changing a fundamental element of the strategy — the customer segment, the problem focus, the solution, or the business model.

Data points that suggest a pivot: low retention despite high acquisition; users love you but will not pay; the problem you are solving matters less than a related problem users keep raising. Data points that support perseverance: meaningful retention among a small cohort, even if acquisition is slow; customers paying despite a rough product; unsolicited word-of-mouth.

Summary

An MVP is not a shortcut to shipping a bad product; it is a disciplined methodology for learning what to build before fully committing. Define your riskiest assumption, design the smallest test, launch to real users, measure rigorously, and use the findings to make an informed decision about whether and how to proceed. Most successful companies today were built iteratively from experiments that started far smaller than the finished product.