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

Introduction: Testing Before Building

Every startup begins with a vision: a product that will solve a problem, delight customers, and build a sustainable business. The temptation is to build that vision fully — to spend months or years crafting a complete, polished product before showing it to the world. This approach feels responsible, even professional. But it contains a dangerous hidden assumption: that the founder already knows what customers want. In reality, that assumption is almost always wrong to some degree, and the longer a startup builds before testing it, the more expensive those wrong assumptions become to correct.

The minimum viable product (MVP) is the antidote to this trap. Coined by entrepreneur Frank Robinson and popularized by Eric Ries in The Lean Startup, an MVP is the smallest experiment that can test a startup's most critical assumption about its product, market, or business model with actual users. It is not a prototype, not a beta version, not a reduced-feature product — it is a deliberately minimal tool for generating validated learning about customers before committing full development resources.

Building an MVP requires discipline, humility, and a willingness to hear that your initial idea needs revision. It is also one of the highest-return activities an early-stage founder can undertake. The founders who build MVPs and iterate based on customer feedback consistently outperform those who build fully-featured products in stealth — because they spend their limited time and capital on things customers actually want rather than things founders think customers want.

What an MVP Actually Is (and Isn't)

The concept of the MVP is frequently misunderstood. Many founders interpret it as "ship a buggy version" or "release a half-finished product." This is wrong in ways that are harmful both to the startup's credibility and to the integrity of the learning process. An MVP is not defined by being low quality; it is defined by being sufficient to test a specific, critical hypothesis.

The right question to ask when defining an MVP is: "What is the minimum we need to build (or do) to answer our most important open question?" That open question is usually a hypothesis about customer behavior: Will people sign up? Will they pay? Will they use the feature enough to return? Will they recommend it to friends? The MVP is designed to answer that specific question — and only that question — as quickly and cheaply as possible. Everything that doesn't contribute to answering the question is out of scope for the MVP.

The MVP is also not necessarily a product in the traditional sense. Some of the most famous MVPs were services, landing pages, videos, or manual processes. What makes something an MVP is not its form but its function: it is the vehicle for testing a hypothesis with real users in a real context. The Concierge MVP is a common form in which the startup provides the service manually (by hand, by humans) that will eventually be automated — not to pretend to be more scalable than it is, but to learn whether customers actually want the service before automating it.

Types of MVPs

Different business models and hypotheses call for different MVP forms. The landing page MVP tests demand before building anything. The startup creates a simple page describing the product, its value proposition, and a call to action (sign up for early access, enter your email, pre-order now). By measuring how many people take the action and examining where traffic drops off, the founders can gauge whether a significant audience exists for their idea without writing a line of product code. This was famously used by Buffer, Dropbox, and many others to validate market interest before committing to development.

The explainer video MVP, exemplified by Dropbox's original launch, uses a video to demonstrate a product that may not yet fully exist. Dropbox's three-minute demonstration video showed exactly what the service would do, linked to a sign-up page, and generated overnight validation of extraordinary demand. This approach works when the product's value is visually demonstrable and the primary uncertainty is whether customers want it — not whether it can be built. The video eliminates the engineering uncertainty from the equation, isolating the market hypothesis.

The Wizard of Oz MVP creates the illusion of a fully automated product while manually performing the underlying operations. The user-facing experience appears complete and functional; behind the scenes, humans are doing what the software will eventually do. This is appropriate when building the automation is expensive but the service itself can be provided manually at small scale. Zappos, before building inventory management systems, manually fulfilled orders purchased through its website by buying from local shoe stores. This validated willingness to pay and retention before a single fulfillment system was built.

The Concierge MVP takes this further by not hiding the manual nature of the service: the startup explicitly works closely with a small number of customers to deliver the result by hand, learning intimately what those customers need before building product. IMVU's founders, building a 3D avatar chat product, personally walked early users through features one-on-one, taking extensive notes on confusion and feature requests. This approach generates deep qualitative learning about user needs that automated tests cannot capture.

Identifying Your Riskiest Assumption

The discipline of MVP thinking requires identifying, before any building, the single most dangerous assumption underlying your business. This is the assumption whose invalidation would most threaten the entire venture — the hypothesis that, if false, renders everything else moot. Only by identifying this riskiest assumption can you design an MVP that provides maximum learning for minimum investment.

Common riskiest assumptions include: customers have the problem you think they have (the problem hypothesis); customers want a solution to that problem badly enough to change their behavior (the demand hypothesis); your proposed solution addresses the problem effectively (the solution hypothesis); customers will pay the price you intend to charge (the willingness-to-pay hypothesis); customers can be reached through the channels you plan to use (the channel hypothesis); and the unit economics work at scale (the business model hypothesis). For most early-stage startups, the problem and demand hypotheses are most critical — it is more common to build the wrong solution than to have the right solution but fail on distribution or pricing.

A useful framework for identifying riskiest assumptions is the pre-mortem: imagine it is two years from now and your startup has failed. What is the most likely reason? Work backward from that failure mode to the assumption whose falsification caused it, and that is your riskiest assumption. Design your first MVP to test that assumption above all others. Every subsequent MVP can test the next-most-critical assumption in turn, progressively reducing the uncertainty space that surrounds your business model.

Common MVP Mistakes

Founders make several recurring mistakes with MVPs. The most common is building too much: scope-creeping the MVP until it becomes a full-featured product launch. This defeats the entire purpose. The second most common mistake is testing the wrong hypothesis: building an MVP that validates something easy ("does my product work technically?") instead of something critical ("do customers want this product enough to pay for it?"). Technical feasibility is rarely the most critical uncertainty for a software startup.

A third mistake is choosing the wrong users to test with. Friendly users — friends, family, people who like you — are unlikely to give honest critical feedback, especially about whether they would actually pay for the product. Truly informative MVP testing requires users who match the target customer profile, have the problem you are solving, and have no social obligation to be kind to you. Finding these users is harder than testing with friends, but the learning is far more valuable.

Measuring vanity metrics is another common failure mode. If your MVP's success is measured in total sign-ups or total page views, you can easily optimize for impressive numbers that tell you nothing about whether people actually want or use your product. Define success metrics before building: what user behavior will indicate that your hypothesis is validated? What threshold will trigger a go/no-go decision? Setting these criteria in advance prevents post-hoc rationalization of mediocre results.

Building and Iterating

Having defined the riskiest assumption and chosen an MVP form, execution involves four steps: building the MVP, deploying it to the right users, measuring their behavior against predefined success criteria, and synthesizing the learning to decide on the next step. The build phase should be time-boxed — set a deadline (one week, two weeks, one month) for the MVP and do not let scope expand beyond what is needed to test the target hypothesis. Speed is protective; every week spent building is a week of market learning deferred.

Deployment requires getting the MVP to users who match your target profile. Early distribution is a major challenge for most startups: it requires proactive outreach, leveraging personal networks, posting in relevant online communities, cold outreach to potential users, or partnerships with organizations that serve the target segment. The number of users needed for an MVP is smaller than most founders expect: for qualitative learning about user behavior, 5 to 10 users is often enough to identify the most important patterns; for quantitative conversion testing, a few hundred visitors may be sufficient depending on the expected conversion rate.

Analysis is the most underinvested phase of the MVP cycle. Founders who are eager to build often shortchange the measurement and learning stages, moving too quickly to the next build cycle without fully understanding what the previous experiment taught. Force a structured learning review: write down what you expected to happen, what actually happened, why you think the results diverged from expectations, and what the implications are for your strategy. This disciplined reflection is what converts raw data into actionable intelligence — and it is the intellectual foundation on which every subsequent decision in the startup will rest.