MVP (Minimum Viable Product)

Definition: The smallest version of a product that lets a team test their core idea with real users while investing minimal time and resources.

How It Works

Defining the Core Hypothesis

Before building anything, a team writes down the specific belief they’re testing — for example, “busy parents will pay for a weekly meal plan tailored to what’s already in their fridge”
The MVP is designed to test that one hypothesis as cheaply and quickly as possible, not to be a smaller version of the eventual full product
A good hypothesis is falsifiable: the team defines in advance what result would count as validation and what would count as a clear signal to change direction
Founders often mistake “the smallest thing we could build” for “the smallest thing that tests our riskiest assumption” — the two are frequently very different products
The riskiest assumption is usually not a technical one (“can we build this?”) but a demand one (“does anyone actually want this, enough to pay or change behavior for it?”)

The Build-Measure-Learn Loop

Build: create the smallest testable version of the idea, cutting anything not required to test the hypothesis
Measure: ship it to real users and collect data on how they actually behave, not how they say they’d behave in a survey
Learn: decide whether the data validates the hypothesis, invalidates it, or points toward a different hypothesis worth testing next
Each loop should be fast — days or weeks, not months — so a team can run several hypotheses before running out of runway (see Runway and Burn Rate)
The loop only creates value if the team is genuinely willing to change direction based on what they learn; running the loop while ignoring bad news defeats its purpose entirely

Choosing What to Cut

Cut every feature that isn’t required to test the core hypothesis, even features that feel important, polished, or “obviously necessary”
Manual and unscalable processes (a founder personally doing what software will eventually automate) are often the fastest, cheapest way to test demand before writing code
Polish and scalability are deliberately sacrificed early — an MVP that looks rough but proves demand is more valuable than a polished product that proves nothing
Scope creep is the most common way MVPs quietly turn into six-month build cycles; a fixed, short deadline forces genuinely minimal scope
What gets cut should be revisited explicitly once a hypothesis is validated — the point isn’t to ship an unfinished product forever, only to defer investment until it’s justified by evidence

Types of MVPs

Concierge MVP: the founder personally delivers the service by hand, fully manually, to a small number of users — no software automation at all yet
Wizard of Oz MVP: users interact with what looks like a real, automated product, but a human is secretly doing the work behind the scenes
Landing Page MVP: a page describing the product and its value proposition, measuring signups or pre-orders before a single line of the actual product is built
Single-Feature MVP: the full product experience is built, but narrowed to just one feature that tests the core hypothesis, with everything else deliberately absent
Piecemeal MVP: existing third-party tools are stitched together (a form tool, a spreadsheet, an email automation service) to simulate the experience without custom-building anything
Prototype / clickable mockup: a non-functional but visually real interface used to gather qualitative reactions before any working software exists
Piecemeal-plus-waitlist MVP: a landing page collects intent while a manual or semi-automated process serves the first handful of committed users behind the scenes, blending demand testing with real delivery
Single-customer pilot MVP: especially common in enterprise software, where one committed customer agrees to use (and sometimes pay for) a barebones version in exchange for heavy influence over what gets built next

How Long Each MVP Type Typically Takes

MVP type	Typical time to first test	Best for
Landing page	Days	Testing raw interest before building anything
Concierge	Days to one week	Testing willingness to pay for a service-heavy idea
Wizard of Oz	One to two weeks	Testing a product experience without automating the backend
Piecemeal (stitched tools)	Days to one week	Testing a workflow using existing off-the-shelf tools
Single-feature build	Two to six weeks	Testing a hypothesis that requires real, working software
Single-customer pilot	Two to eight weeks	Testing enterprise or B2B demand with one committed partner

MVP vs. Prototype vs. Proof of Concept vs. Full Product

	Prototype	Proof of Concept	MVP	Full Product
Purpose	Show what it could look like	Show it’s technically possible	Show people actually want it	Deliver the complete intended experience
Audience	Internal team, investors	Internal team, technical stakeholders	Real external users	The broad target market
Functionality	Often non-functional or mocked	Functional but narrow, not user-ready	Minimally functional, real usage	Fully functional and polished
Primary risk it addresses	Design and communication risk	Technical feasibility risk	Market demand risk	Execution and scale risk
Typical build time	Days	Days to weeks	Weeks	Months to years

Why It Matters

Lets founders learn and iterate before over-investing in a direction that might not work, preserving scarce Runway and Burn Rate for ideas that actually have traction
Provides real evidence of Product-Market Fit — or the lack of it — far earlier than a fully built product would, when the cost of being wrong is still low
Forces early clarity on the Business Model Canvas, since testing a real hypothesis requires knowing exactly who the customer is and what value is being promised to them
Generates real usage data that’s far more persuasive to investors in a Pitch Deck than a polished but unvalidated product vision
Surfaces early Unit Economics signals — what it actually costs to acquire and serve a user — before those costs are baked into a much larger, harder-to-change system
Keeps teams honest about assumptions; it’s easy to convince yourself a product is good in the abstract, much harder to ignore users who don’t come back
Reduces the emotional and financial cost of being wrong — pivoting away from a landing page test is trivial compared to pivoting away from a year of engineering investment
Builds organizational muscle for rapid experimentation that continues to pay off well past the MVP stage, into how the company approaches every future feature

Common Pitfalls

Building a “minimum” product that’s actually a small full product: including polish, edge-case handling, or nice-to-have features turns a two-week test into a two-month build that still doesn’t answer the real question
Testing the wrong hypothesis: validating that people like the idea in a survey isn’t the same as validating that they’ll actually use or pay for it — talk is cheap, behavior is not
Confusing “no one complained” with validation: silence or polite interest is not the same signal as users returning, paying, or actively recommending the product to others
Refusing to kill or pivot a failed MVP: sunk-cost thinking keeps some founders iterating on a hypothesis the data has already invalidated, rather than moving on to a better one
Skipping the manual, unscalable version: jumping straight to building automated software before testing demand manually wastes the cheapest, fastest validation method available
Measuring vanity metrics: signups, downloads, or page views can look encouraging while retention and real usage — the metrics that actually predict a viable business — tell a very different story
Under-communicating that it’s an MVP: early users who don’t understand they’re testing a rough, evolving product can churn out of frustration rather than giving useful, forgiving feedback
Optimizing for investor optics over learning: building extra polish specifically to impress investors, rather than to test the hypothesis faster, defeats the purpose of the exercise and burns time better spent learning

Measuring MVP Success

Retention, not just acquisition: do the same users come back a second and third time, or does the entire cohort disappear after one use?
Willingness to pay: even a small amount of real money (a pre-order, a deposit, a paid pilot) is a dramatically stronger signal than a “yes, I’d probably use that” in conversation
Qualitative depth: a handful of in-depth user interviews often reveal more about why something is or isn’t working than a dashboard of aggregate numbers alone
Behavioral proxies for value: actions like referring a friend, upgrading a plan, or using the product daily rather than weekly indicate real, not polite, enthusiasm
A pre-defined kill criterion: deciding in advance what result means “stop and pivot” prevents founders from moving the goalposts after a disappointing result comes in
Comparing against the specific hypothesis, not general excitement: the only question that matters is whether the original, narrow hypothesis was validated — everything else is a distraction

MVPs in Constrained or Regulated Industries

Hardware: a true minimum product might be a manually assembled prototype tested with a handful of users, since manufacturing at scale is far too costly to justify before demand is proven
Healthcare and fintech: regulatory requirements (data privacy, licensing, compliance) mean some “minimum” scope is non-negotiable regardless of what a pure demand test would otherwise require
Marketplaces: an MVP often has to fake or manually manage one side of the market (supply or demand) to test whether the other side will engage at all, since a real two-sided marketplace is hard to bootstrap organically
Enterprise software: a single, hand-held pilot customer with a manual or semi-automated version of the product can validate demand long before a self-serve product exists
Consumer hardware and physical goods: crowdfunding campaigns and pre-order pages often serve as a demand-testing MVP before any unit is manufactured
In all of these cases, the underlying principle is unchanged even though the tactics differ: test the riskiest, most expensive-to-be-wrong-about assumption as cheaply as the constraints of the industry allow

From MVP to Product-Market Fit

A validated MVP is the beginning of a company’s journey, not the end — the next step is usually deepening the single validated use case rather than immediately broadening scope
Teams often make the mistake of adding many new features right after a promising MVP result, when doubling down on the one thing that worked would create more value
Repeated MVP cycles — test, learn, refine, test again — gradually build toward durable Product-Market Fit, rather than a single MVP delivering it in one shot
Once retention and willingness-to-pay signals are strong and consistent across cohorts, it’s usually the right time to invest in scalability, polish, and the features that were deliberately cut earlier
Metrics worth tracking as an MVP matures include cohort retention curves, expansion revenue, and organic referral rates — signals that go well beyond the initial validation test
Some teams formalize this transition with a lightweight OKRs (Objectives and Key Results)-style goal, shifting the team’s focus from “validate the hypothesis” to a concrete growth or retention target for the next quarter

The Cost of Skipping an MVP

Building the full, polished version of an idea before testing it means every wrong assumption gets baked into months of engineering work instead of days of manual testing
Teams that skip MVP validation often discover product-market misalignment only after a meaningful chunk of Runway and Burn Rate is already gone, with far less room left to pivot
Skipping validation also means skipping the qualitative learning that comes from watching real users struggle — learning that a spec document or an internal debate can’t replicate
Investors evaluating a Pitch Deck tend to discount a large, unvalidated build far more heavily than a scrappy MVP with real usage data behind it
The opportunity cost compounds: months spent building an unvalidated full product are months not spent testing several smaller, cheaper hypotheses that might have worked instead
Not every idea needs a full MVP process — some risks are cheap enough to just build and see — but treating that as the default for every decision is what leads teams into expensive, avoidable dead ends

MVP Team Composition and Timeline

At the earliest stage, an MVP is often built and run by one or two founders directly, with no dedicated engineering team at all
Concierge and Wizard of Oz MVPs deliberately require little to no software engineering, which is exactly why they’re usually the fastest path to a first real signal
Once a hypothesis clears initial validation, a small cross-functional group — one engineer, one designer, one person talking to users — typically takes over building the next iteration
Setting a hard deadline (two weeks, not “whenever it’s ready”) for each MVP cycle keeps scope honest and prevents quiet feature creep from turning a test into a build
Founders should personally stay close to early user feedback during this phase — delegating it away too early loses the qualitative signal that raw usage data alone won’t capture
As the team scales past the earliest MVP cycles, the same build-measure-learn discipline typically evolves into a broader experimentation practice, similar to what a dedicated Growth Hacking team runs later

Communicating MVP Status to Early Users

Setting expectations upfront — “this is an early test, and it’s going to be rough in places” — makes early users far more forgiving of bugs and missing features
Framing early users as collaborators rather than customers (“help us figure out if this is worth building”) tends to produce more honest, detailed feedback than a polished sales pitch would
Being transparent about what’s manual versus automated behind the scenes (in a Wizard of Oz MVP, this usually comes later, once the concept is validated) avoids feeling deceptive once revealed
Close, personal contact with early users — a direct email thread, a shared chat channel — surfaces far richer feedback than an anonymous in-app survey
Thanking and closing the loop with users who churn or opt out is worth the effort too; their reasons for leaving are often the most valuable data of all
Setting a clear, communicated end date for a manual or unscalable MVP process avoids the awkward situation of quietly abandoning early users without explanation

Talking to Investors About Your MVP

Investors generally care far more about what an MVP proved than how impressive it looks — a scrappy PDF-based test with strong retention outperforms a slick app with no usage data
Framing MVP results around the original hypothesis (“we believed X; here’s what we found”) reads as far more credible than vague enthusiasm about early traction
Being candid about what the MVP didn’t validate, alongside what it did, builds more investor trust than only showcasing favorable numbers
Early cohort retention and willingness-to-pay data from an MVP are often the single strongest pieces of evidence a pre-seed or seed-stage Pitch Deck can include
Investors will often ask what’s manual versus automated in an MVP-stage product; founders should be upfront rather than letting a demo imply more automation exists than actually does
A clear roadmap from “what we tested” to “what we’re building next and why” reassures investors the team knows how to translate a validated MVP into a scalable product

Example

A founder wants to test whether busy parents would value a personalized weekly meal-planning service. Rather than spending months building an app with recipe databases, grocery integrations, and account management, she starts with a Concierge MVP: she manually creates a weekly PDF meal plan for twenty families, based on a short intake form about dietary preferences and what’s already in their pantry, and emails it to them every Sunday night for $15 a month.

Within three weeks, fourteen of the twenty families are still opening and using the plan, and eleven have paid for a second month without being asked — a strong retention and willingness-to-pay signal that a landing page or a survey alone could never have produced. A few families drop off immediately, and interviews reveal the plans aren’t accounting for one family member’s allergy, a detail the manual process makes trivially easy to fix on the next cycle.

Only after two more manual cycles confirm the pattern holds with a larger group does the founder invest in building actual software — starting with the single highest-leverage piece, an intake form that auto-generates a draft plan for her to review, rather than the full automated grocery-delivery integration she’d originally imagined building first. The manual process that looked unscalable on day one ended up being the fastest, cheapest way to learn exactly which features were worth automating at all.

Six months later, when she raises a pre-seed round, the Pitch Deck leads not with a product demo but with the cohort retention curve from those first manual weeks — the evidence that mattered most to investors evaluating whether the idea had real legs behind it.

Referenced by

Dig deeper

Spot an error in this note?