How to Build a Minimum Viable Product (MVP)
This skill teaches you how to design and ship the smallest functional version of a product that tests your riskiest business assumption with real customers, so you learn what works before investing in full-scale development.
Start by identifying your riskiest assumption, then build the smallest possible product that tests that assumption with real customers. Strip every feature that does not directly serve the test. Launch to a small audience, measure their behavior against a pre-defined success metric, and use the data to decide whether to iterate, pivot, or scale.
Outcome: You produce a working, deployable product version that tests one core assumption, collect real customer behavior data, and generate a clear go/no-go signal for your next development cycle.
Prerequisites
- A clearly articulated business hypothesis you want to test (see formulating-testable-hypotheses)
- Basic understanding of your target customer segment and the problem you aim to solve
- Familiarity with the Lean Startup build-measure-learn loop
- Access to a small group of potential customers willing to try an early product
- Enough technical or design capability to build or assemble a functional prototype
Overview
Building a minimum viable product is the central execution skill in the Lean Startup methodology. Where hypothesis formulation asks "what do we believe?" and experiment design asks "how will we test it?", building the MVP asks "what is the smallest thing we can ship to get a real answer?" The output of this skill is not a prototype sitting in a demo environment. It is a live product, however rough, that real customers interact with under real conditions. The data those interactions produce is what makes every subsequent decision, from feature investment to full pivot, grounded in evidence rather than intuition.
The specific artifact you produce is a scoped, functional product paired with a measurement plan. The product has a defined feature set (usually one to three capabilities), a clear user flow, and enough polish that the target customer can complete the core task without hand-holding. The measurement plan specifies the success metric, the sample size, and the decision threshold. Together, these two artifacts let you run a valid test. Without the measurement plan, you have a demo. Without the scoped product, you have a spec.
The hardest part of this skill is not the building. It is the scoping. Teams consistently over-build MVPs because they conflate "minimum" with "embarrassing" and then add features to avoid embarrassment. A well-scoped MVP feels uncomfortable to ship. It should make you nervous that customers will complain about missing features, because that nervousness is a signal that you have actually cut to the bone. The goal is not to impress customers. The goal is to learn whether the core value proposition works. Everything else is noise at this stage.
This skill connects directly to several sibling skills in the Lean Startup workflow. You need a testable hypothesis before you start building. You need to have selected the right MVP type so you are not building a landing page when you need a concierge test, or vice versa. Once the MVP is live, you move into running build-measure-learn cycles and tracking innovation accounting metrics to interpret the results. The MVP is the hinge between planning and evidence.
How It Works
The core logic behind building an MVP is that uncertainty, not engineering capacity, is the binding constraint in early-stage product work. You do not know whether customers want what you plan to build. You do not know whether they will pay for it. You do not know whether they will use it the way you expect. Every week you spend building features before testing these unknowns is a week of compounding risk. The MVP inverts that dynamic by shipping the cheapest possible test and letting customer behavior resolve the uncertainty.
The mental model is a funnel of assumptions ranked by risk. At the top sits the assumption that, if wrong, kills the entire product. For a marketplace, that assumption might be "sellers will list inventory without guaranteed buyers." For a SaaS tool, it might be "managers will enter data weekly without being forced to." The MVP targets that top assumption and ignores everything below it. This is counterintuitive because teams naturally want to build a "complete" experience. But completeness is irrelevant if the foundational assumption fails. You would not furnish a house before confirming the foundation holds weight.
The Lean Startup framework frames this as maximizing validated learning per unit of time and money spent. An MVP that costs two weeks and answers your riskiest question is more valuable than a polished beta that costs three months and answers the same question, even if the beta produces a better Net Promoter Score. The metric that matters is information gained, not customer satisfaction. Customer satisfaction becomes the focus after you have confirmed you are building the right thing.
The skill works because human behavior is unpredictable in specific, discoverable ways. Surveys and interviews capture what people say they will do. MVPs capture what people actually do. The gap between stated and revealed preference is where most product failures hide. A landing page MVP might show that 40% of visitors click "Sign Up" but only 3% complete onboarding. That gap is invisible without a real product. It tells you the value proposition resonates but the activation flow fails, which is a fundamentally different problem than "nobody wants this."
One important nuance: the MVP is not a throwaway. The code or design might be disposable, but the learning is permanent. Structure the MVP so that the data it produces is clean and unambiguous. If your success metric is "percentage of users who complete the core task," make sure the core task is clearly defined, instrumented, and reachable without confusion. Ambiguous data from a poorly structured MVP is worse than no data, because it creates false confidence. You will make a decision either way. The question is whether the decision is informed or not.
Step-by-Step
Step 1: Identify your riskiest assumption
Review the hypotheses you formulated during the hypothesis stage and rank them by two dimensions: how critical the assumption is to the business model, and how uncertain you are about it. The assumption that scores highest on both dimensions is your MVP target. " If you have multiple high-risk assumptions, pick only one. Testing two assumptions simultaneously with one MVP muddies the data because you cannot attribute outcomes to either assumption cleanly.
Document the assumption, the metric that will confirm or refute it, and the threshold that constitutes success or failure.
Tip: If your team cannot agree on the riskiest assumption, that disagreement is itself valuable data. Have each person write their top assumption independently, then compare. Misalignment here means you need more customer discovery before building anything.
Step 2: Define the core user flow
Map the minimum sequence of actions a user must take to encounter the value your assumption promises. This is not a full user journey. It is the shortest path from entry point to the moment the assumption is tested. For example, if your assumption is about willingness to pay, the flow might be: land on page, view pricing, enter payment info.
If your assumption is about engagement, the flow might be: sign up, complete onboarding task, return within 48 hours. Write each step in the flow as a concrete screen or interaction. If a step does not directly serve the assumption test, remove it. Every extra step adds friction and reduces your signal quality because users who drop off at irrelevant steps never reach the test point.
Tip: Draw the flow on paper or a whiteboard before opening any design tool. If the flow has more than five steps, you are almost certainly including steps that do not serve the test.
Step 3: Set a feature boundary and enforce it
List every feature you think the MVP needs. " Be ruthless. A feature is required only if removing it would make the core user flow impossible to complete or would invalidate the test results. Everything tagged "nice to have" gets cut.
Write the final feature list in a shared document and get explicit sign-off from every stakeholder. This sign-off matters because scope creep during build is the most common reason MVPs take three times longer than planned. When someone suggests adding a feature mid-build, point to the signed list and ask: does this feature change whether we can test the assumption? If the answer is no, it waits.
Tip: A useful forcing function is to set a hard time constraint, such as "this ships in two weeks no matter what." The constraint forces trade-offs that pure prioritization discussions often avoid.
Step 4: Choose the build approach
Decide how you will construct the MVP based on the complexity of the core user flow and the fidelity needed to test your assumption. Options range from no-code tools like Webflow or Bubble, to manual concierge service behind a simple interface, to a lightweight coded application. The right choice depends on what your assumption demands. If you are testing willingness to pay, a landing page with a payment form and a Zapier integration may be sufficient.
If you are testing whether users will repeatedly engage with a workflow, you likely need a functional tool, even if the backend is held together with spreadsheets. Match the build approach to the minimum fidelity required for the data to be valid. Over-engineering the build is a waste. Under-engineering it to the point where users cannot complete the flow is also a waste.
Tip: Concierge and Wizard of Oz MVPs, where a human performs the work behind the scenes, are underused. They let you test complex value propositions without writing a line of backend code. See the sibling skill on selecting MVP types for detailed guidance.
Step 5: Build and instrument the MVP
Execute the build according to your feature boundary and build approach. As you build, add analytics instrumentation at every step of the core user flow. You need to track each transition: how many users enter the flow, how many complete each step, and how many reach the test point. Use a simple analytics tool like Mixpanel, Amplitude, PostHog, or even Google Analytics event tracking.
The key is that every step is instrumented before launch, not after. Retrofitting analytics after launch means you lose data from your earliest and most informative users. Also set up a way to collect qualitative feedback, such as a short in-app survey, a feedback email triggered after the core action, or scheduled calls with early users. Quantitative data tells you what happened.
Qualitative data tells you why.
Tip: Create a simple tracking spreadsheet that maps each flow step to an analytics event name. Before you call the build complete, verify that every event fires correctly by walking through the flow yourself at least three times.
Step 6: Recruit your test audience
Identify a small group of real potential customers to use the MVP. The ideal test audience is 30-100 people who match your target customer profile and have the problem your product addresses. Sources include email lists from customer discovery interviews, social media communities, Product Hunt, relevant Slack or Discord groups, or paid acquisition through a small ad spend. Do not recruit friends, family, or colleagues unless they genuinely match the target profile, because polite feedback from non-customers will mislead you.
Frame the invitation honestly: you are building something new, it is rough, and you want their candid experience. Set expectations that the product is incomplete. Users who opt in under these conditions are the right testers because they are motivated by the problem, not by polish.
Tip: If you conducted customer discovery interviews earlier, those interviewees are your best first testers. They already articulated the problem and are curious whether you can solve it.
Step 7: Launch to the test audience and observe
Release the MVP to your test audience and resist the urge to intervene. Do not send follow-up emails explaining how to use the product unless those emails are part of the designed flow. Do not offer live walkthroughs unless the MVP is a concierge model. The point is to observe what real users do when left to their own judgment, because that is what will happen at scale.
Monitor your analytics daily but do not make changes to the product during the test period unless you discover a critical bug that prevents flow completion. Changing the product mid-test contaminates your data because early users experienced a different product than late users. Set a test period duration in advance, typically one to three weeks depending on the behavior you are measuring. If you are measuring a one-time action like signup, a week may suffice.
If you are measuring repeat engagement, you need at least two to three weeks.
Tip: Keep a daily log of what you observe, including surprises, patterns, and questions that arise. This log becomes invaluable when interpreting results because memory is unreliable and you will forget the nuances by the time the test ends.
Step 8: Collect and analyze results against your success threshold
At the end of the test period, pull your quantitative data and compare it to the success threshold you defined in Step 1. Be honest about the numbers. If your threshold was 20% trial conversion and you achieved 12%, that is a miss, even if 12% feels encouraging. Compare the funnel at each step to identify where users dropped off.
Combine the quantitative data with qualitative feedback to build a complete picture. For example, if conversion was low but qualitative feedback was enthusiastic, the problem may be in the flow design rather than the value proposition. If conversion met the threshold but users expressed confusion about what the product does, you may have a positioning problem that will worsen at scale. Document the results in a structured format: assumption tested, metric observed, threshold, actual result, qualitative themes, and recommended next action.
Tip: Share raw data with your team before sharing your interpretation. Let others form their own conclusions independently. This reduces confirmation bias, which is the tendency to interpret ambiguous data as supporting what you hoped to find.
Step 9: Decide and communicate next steps
Based on the results, make one of three decisions: iterate on the current MVP to improve the metric, pivot to a different assumption or approach, or proceed to the next build-measure-learn cycle with expanded scope. This decision should be made in a structured meeting where the data is reviewed, not in a hallway conversation. If iterating, define the specific change you will make and the new test period. If pivoting, document what you learned and why the original assumption failed.
If proceeding, define which assumption you will test next and what the next MVP increment looks like. Communicate the decision and its rationale to all stakeholders in writing. This creates an institutional record of learning that prevents the team from re-testing assumptions that have already been resolved.
Tip: The most common failure at this step is the "soft pivot," where the team informally shifts direction without explicitly acknowledging the original assumption failed. Name the decision clearly. If you are pivoting, say so. Ambiguity here leads to months of drift.
Examples
Example: B2B SaaS for Invoice Automation (Small Team, 3 People)
A three-person team believes that freelance consultants waste significant time creating and sending invoices manually. Their riskiest assumption is that consultants will enter their client details and billing rates into a new tool rather than continuing to use spreadsheet templates they already have. They have a two-week build window and a $500 budget for recruiting testers.
" They build a Bubble-based MVP with three screens: a signup form, a client/rate entry form, and a one-click invoice generator that emails a PDF. There is no dashboard, no recurring invoice feature, and no payment integration. They recruit 60 freelance consultants from two relevant Slack communities by offering early access. After two weeks, 54 people sign up.
Of those, 22 (41%) create and send at least one invoice. Qualitative feedback reveals that the top request is recurring invoices, but the core assumption, willingness to enter data and use the tool, is validated above threshold. The team decides to proceed with a second cycle testing willingness to pay, adding a $9/month gate after the third invoice.
Example: Consumer Fitness App (Larger Team, 8 People)
A product team at a mid-size health company hypothesizes that casual gym-goers will follow AI-generated workout plans if the plans adapt weekly based on logged workouts. The riskiest assumption is not whether AI can generate plans, but whether users will actually log their workouts consistently enough for the AI to have useful data. The team has four weeks and access to a 2,000-person email list of gym members from a partnership.
" They build a React Native MVP with three features: receive a weekly plan via push notification, log a workout with one tap per exercise (sets and reps only), and view next week's adjusted plan. There is no social feed, no progress photos, and no integration with wearables. The AI adaptation is handled manually by a trainer reviewing logs each Sunday and adjusting plans in a spreadsheet that feeds the app. They email 2,000 gym members and get 310 signups.
After three weeks, 58 users (19%) logged workouts three or more times per week for two consecutive weeks, falling short of the 25% threshold. Qualitative interviews reveal that users forgot to log because they do not carry their phone on the gym floor. The team decides to iterate, not pivot. The next MVP adds an Apple Watch companion for one-tap logging, and the team reruns the test with fresh users.
Example: B2B Marketplace for Corporate Event Venues (Solo Founder)
A solo founder believes corporate event planners struggle to find and compare venue options because information is scattered across venue websites, broker emails, and outdated directories. The riskiest assumption is that event planners will submit their event requirements through an online form rather than continuing to email their existing network of venue contacts. The founder has no engineering skills, a one-week build window, and access to 15 event planners from previous networking.
" She builds a Carrd landing page describing the service, with a Typeform embedded for venue requests (event date, guest count, budget, location preference, and style). When a form is submitted, she manually searches venues, calls them, and emails the planner a curated list of three options within 48 hours. This is a classic concierge MVP. She emails her 15 contacts and asks each to share with one colleague, reaching approximately 30 planners.
Over two weeks, 28 people visit the page and 14 submit the form (50%), exceeding the 40% threshold. However, qualitative follow-up reveals that only 3 of the 14 found the curated list useful, because most wanted venues in cities the founder did not have contacts in. The founder identifies geographic coverage as the next assumption to test and begins recruiting venue partners in the five most-requested cities before building any technology.
Example: B2C Meal Planning Subscription (Small Team, Pre-Seed Startup)
A four-person startup believes busy parents will pay for a weekly meal plan customized to their family's dietary restrictions and grocery store preferences. The riskiest assumption is willingness to pay, since free meal planning content is abundant online. They have a three-week window and a $1,000 ad budget for testing.
- Upon payment, customers receive a questionnaire via email, and a team member manually creates a PDF meal plan within 24 hours. They spend $1,000 on Instagram ads targeting parents in three metro areas, driving 1,200 visitors over three weeks. 6% of visitors, 37% of quiz completers).
6% visitor conversion falls below the 5% threshold, but the 37% quiz-to-payment rate is strong. 99 felt expensive for a single week without seeing a sample. The team iterates by adding a free sample plan on the landing page and retesting, rather than pivoting away from the concept entirely.
Best Practices
Set your success metric and threshold before building, not after launching. Pre-commitment to a number prevents post-hoc rationalization, where teams unconsciously adjust their criteria to match whatever the data shows. Write it down, share it with the team, and refer back to it when results come in.
Limit the MVP to one core assumption per test cycle. Testing multiple assumptions simultaneously makes it impossible to attribute outcomes. If signup conversion is low, you cannot tell whether the problem is the value proposition, the pricing, or the onboarding flow. Isolate one variable and resolve it before moving to the next.
Use time-boxing as a scoping tool. Set a hard ship date, such as ten business days from kickoff, and cut features to fit the constraint. Teams that scope by feature list almost always over-build because each individual feature feels essential in isolation. A time constraint forces relative prioritization.
Instrument analytics before launch, not after. The first cohort of users provides the cleanest signal because they have no prior exposure and no word-of-mouth expectations. Losing that data because tracking was not set up means your highest-value cohort is invisible.
Recruit testers who match your actual target customer profile, not people who are convenient. Testing with the wrong audience produces misleading signals. A product for enterprise procurement managers will get very different feedback from startup founders, even if both groups are technically "professionals."
Separate the roles of builder and evaluator. The person who built the MVP will unconsciously interpret ambiguous data favorably. Have someone who was not involved in the build review the results independently and compare interpretations before making decisions.
Document every MVP cycle's results in a persistent, searchable format. Teams that rely on memory or Slack conversations lose institutional knowledge within weeks. A simple shared document with assumption, metric, result, and decision is sufficient. This record prevents re-testing resolved questions and accelerates onboarding of new team members.
Resist the urge to fix cosmetic issues during the test period. If users can complete the core flow, cosmetic roughness is acceptable. Polishing the MVP mid-test wastes time and changes the product between cohorts, contaminating your data.
Common Mistakes
Building a Version 1 product and calling it an MVP
Correction
The most common mistake is building a fully functional first version with multiple features, complete UI polish, and edge case handling, then labeling it an "MVP" because it lacks a few planned features. This happens because teams feel uncomfortable shipping something genuinely minimal. The signal to watch for is a build timeline longer than two to four weeks or a feature list longer than three items. A real MVP tests one assumption.
If your "MVP" tests five, it is a V1 product with a fashionable label. Go back to Step 1 and identify the single riskiest assumption.
No pre-defined success metric or threshold
Correction
Teams launch an MVP, collect data, and then decide what the data means after the fact. This leads to confirmation bias because any result can be interpreted as "promising" if you adjust the criteria retroactively. " instead of a clear pass/fail comparison. Define the metric and threshold in writing before building.
Share it with at least one person outside the team to create accountability.
Testing with the wrong audience
Correction
Teams recruit testers from their personal network, from Twitter followers, or from a general mailing list rather than from the specific customer segment the product targets. This happens because recruiting the right audience is harder and slower than recruiting whoever is available. The diagnostic sign is feedback that is uniformly positive but vague, such as "looks cool" or "I would definitely use this," without specific task-level engagement. Invest the extra effort to find testers who have the actual problem.
Their behavior will be dramatically different from casual observers.
Changing the MVP during the test period
Correction
A team launches, sees early drop-off at a particular step, and immediately pushes a fix. This feels productive but it splits the test into two different products, making the aggregate data meaningless. Users who encountered the original version had a different experience than users who encountered the patched version, and you cannot cleanly separate the two cohorts without significant instrumentation. Unless you discover a bug that completely blocks the core flow, log the issue and wait until the test period ends.
Then address it in the next iteration with a clean test.
Skipping qualitative feedback and relying solely on analytics
Correction
Quantitative data tells you what users did but not why. A 15% trial conversion rate is meaningless without context. Did the other 85% leave because they did not understand the product, because the price was wrong, or because they were not the right audience? Teams skip qualitative feedback because it requires effort, such as scheduling calls, reading survey responses, or reviewing session recordings.
Build a lightweight qualitative channel into the MVP from the start. ", provides context that transforms raw numbers into actionable insight.
Treating the MVP as a one-time event instead of a cycle
Correction
Some teams build one MVP, review the results, and then jump straight to full product development regardless of the outcome. The MVP is meant to be the first iteration in a series of build-measure-learn cycles. If the first test produces ambiguous results, the correct response is a refined second MVP, not a leap to scale. Watch for language like "we tested the MVP, now let's build the real product." That framing suggests the team views the MVP as a checkbox rather than a learning instrument.
Other Skills in This Method
Tracking Innovation Accounting Metrics
How to define and measure actionable metrics—rather than vanity metrics—to accurately assess startup progress and learning velocity.
Formulating Testable Business Hypotheses
How to translate business assumptions into clearly defined, falsifiable hypotheses with specific success metrics and timeframes.
Selecting the Right MVP Type for Your Idea
How to choose among MVP formats—landing page MVP, concierge MVP, Wizard of Oz MVP, single-feature MVP, and piecemeal MVP—based on your risk profile and resources.
Making Pivot-or-Persevere Decisions
How to use experiment data and innovation accounting to decide whether to pivot your strategy or persevere with the current direction.
Designing Validated Learning Experiments
How to structure low-cost experiments—such as landing page tests, concierge MVPs, and Wizard of Oz tests—to generate validated learning about customer behavior.
Running Build-Measure-Learn Cycles
How to execute rapid iterations through the Build-Measure-Learn feedback loop to systematically validate or invalidate product hypotheses.
Conducting Customer Discovery Interviews
How to plan and run structured customer interviews that uncover real pain points and validate problem-solution fit without leading the respondent.
Frequently Asked Questions
How do I decide when my MVP is 'minimum enough' to ship?
Apply a simple test: can a user complete the core flow end-to-end without help from you? If yes, ship it. If a feature removal would make the core flow impossible, keep the feature. If removing it merely makes the experience less polished, cut it. The discomfort you feel about shipping something rough is normal and usually a good sign that you have genuinely stripped to the minimum. If you feel proud of the MVP, you probably waited too long.
How long should an MVP test run before I evaluate results?
It depends on the behavior you are measuring. For one-time actions like signup or purchase, one to two weeks is usually sufficient if you have at least 50-100 users entering the funnel. For repeated behaviors like weekly engagement or retention, you need at least two to three complete cycles, so two to three weeks minimum. Set the duration before launch and do not extend it because the numbers look ambiguous. Ambiguous results after a fair test period are a result, not a reason to keep testing.
Should I build an MVP before or after conducting customer discovery interviews?
After. Customer discovery interviews help you identify the problem and form hypotheses about solutions. The MVP tests whether your proposed solution actually works. Building an MVP before talking to customers is like writing an answer before reading the question. You might get lucky, but the odds are poor. See the sibling skill on [conducting customer discovery interviews](/skills/conducting-customer-discovery-interviews) for guidance on the pre-MVP research phase.
How many users do I need for an MVP test to be meaningful?
For most early-stage MVPs, 30-100 users entering the core flow provides enough signal to make a directional decision. You are not running a statistically rigorous A/B test. You are looking for a strong signal: does the conversion rate clearly exceed your threshold, clearly miss it, or land in an ambiguous zone? With 50 users and a 20% threshold, if 2 people convert (4%) or 18 convert (36%), the signal is clear. If 9 convert (18%), you are in the ambiguous zone and may need a second test.
What if my MVP results are inconclusive and the data is ambiguous?
Ambiguous results usually mean one of three things: your sample size was too small, your success metric was poorly defined, or the product experience confused users enough that behavior did not reflect true intent. Start by reviewing qualitative feedback to diagnose which factor is most likely. If the sample was too small, recruit more testers and extend the test. If the metric was unclear, redefine it and retest. If the UX was confusing, fix the specific confusion point and retest. Do not interpret ambiguous data as positive confirmation to proceed.
Can I use a landing page as an MVP, or do I need a working product?
A landing page MVP is valid when your riskiest assumption is about demand or willingness to pay, not about product usage. ", a landing page with a signup form or payment button is sufficient. ", a landing page cannot answer it because users never experience the product. Match the MVP format to the assumption. See [selecting the right MVP type](/skills/selecting-mvp-types-and-formats) for a detailed breakdown of when each format applies.
Why does my MVP scope keep growing during the build phase?
Scope creep during MVP builds almost always stems from insufficient pre-build alignment on the single assumption being tested. " The fix is to return to Step 1 and write a sharper assumption statement. Then review each proposed feature against the question: does removing this feature make the assumption untestable? If the answer is no, the feature is out. Time-boxing the build to a fixed deadline also helps, because a hard constraint forces the team to prioritize rather than accumulate.