Types of MVP: How to Select the Right Format for Your Idea
This skill teaches you how to evaluate different types of MVP and select the format that best matches your riskiest assumption, available resources, and learning goal so you build the smallest thing that answers the most important question.
Start by identifying your riskiest assumption: demand, usability, or feasibility. Then match it to an MVP type. Landing page MVPs test demand. Concierge and Wizard of Oz MVPs test usability and workflow. Single-feature MVPs test feasibility. Piecemeal MVPs test integration. Choose the format that answers your biggest question with the least build effort.
Outcome: You produce a documented MVP selection decision that names the chosen format, the specific assumption it tests, the success metric, and a rough scope boundary, giving your team a clear starting point for building.
Prerequisites
- A clearly articulated product idea or problem hypothesis
- Familiarity with the Lean Startup build-measure-learn cycle
- At least one testable business hypothesis formulated for the idea
- A rough understanding of your team's technical and non-technical capabilities
Overview
Choosing among the many types of MVP is one of the most consequential decisions in early-stage product work, yet teams routinely skip it. They default to whatever format feels familiar, building a full app when a landing page would suffice, or running a concierge experiment when the real risk is technical feasibility. This skill sits squarely inside the Lean Startup build-measure-learn loop, right after you have formulated a testable hypothesis and right before you begin building your MVP. Getting the format wrong does not just waste time. It produces learning that answers a question nobody asked, leaving the riskiest assumption untested.
The five core types of MVP are the landing page MVP, the concierge MVP, the Wizard of Oz MVP, the single-feature MVP, and the piecemeal MVP. Each one is optimized for a different category of risk. A landing page MVP tests whether anyone cares enough to sign up. A concierge MVP tests whether your proposed workflow actually solves the problem when delivered by hand. A Wizard of Oz MVP tests the user experience of an automated product without building the automation. A single-feature MVP tests whether one core capability is strong enough to retain users. A piecemeal MVP tests whether existing tools can be stitched together to deliver the value proposition before you write custom code. The choice depends on three inputs: the riskiest assumption you need to test, the resources you have available, and how much fidelity the customer needs to give you honest feedback.
The concrete artifact produced by this skill is a one-page MVP selection document. It names the chosen format, the hypothesis it tests, the success criteria, the resources required, and the explicit scope boundary that defines what is not included. This document becomes the contract between the product person and the team, preventing scope creep and anchoring every subsequent decision back to the learning goal. Without it, MVPs tend to grow into full products, defeating the purpose of the experiment entirely.
How It Works
The core mental model behind MVP type selection is risk-to-fidelity matching. Every product idea carries multiple risks: demand risk (will anyone want this?), problem-solution fit risk (does this workflow actually solve the problem?), usability risk (can people figure out how to use it?), feasibility risk (can we build the technology?), and viability risk (can we deliver it profitably?). The types of MVP differ primarily in which risk category they address and how much fidelity they require to generate trustworthy signal.
Fidelity matters because different risks require different levels of realism to test honestly. Demand risk is the least fidelity-dependent. A landing page with a clear value proposition and a signup button is enough, because you are only measuring whether the promise resonates. Problem-solution fit risk requires moderate fidelity. The customer needs to experience the actual workflow, even if a human is executing it behind the scenes, which is why the concierge MVP exists. Feasibility risk demands high fidelity, because the question is whether the technology works, and you cannot answer that without building real technology, which points to a single-feature MVP.
The Lean Startup framework teaches that you should always test the riskiest assumption first, because if that assumption is wrong, nothing else matters. This principle directly drives MVP format selection. If your riskiest assumption is demand, pick the lowest-fidelity format. If your riskiest assumption is feasibility, pick the highest-fidelity format that isolates just the technical question. If your riskiest assumption is the end-to-end experience, pick a middle-fidelity format like the Wizard of Oz.
The decision also depends on your resource constraints. A solo founder with no engineering skills cannot build a single-feature MVP, but they can run a concierge experiment or assemble a piecemeal MVP from existing tools. A funded team with three engineers might skip the landing page and jump straight to a single-feature MVP, because the opportunity cost of not testing feasibility early is higher than the cost of building. Resource constraints are not obstacles to work around. They are inputs that shape which format produces the best learning per dollar spent.
Finally, understand that MVP types are not a strict hierarchy. You do not have to start with a landing page and progress through each type. You can run a landing page MVP and a Wizard of Oz MVP simultaneously if they test different assumptions. You can skip types entirely if the risk they address has already been validated through customer discovery. The framework is a decision tool, not a checklist.
Step-by-Step
Step 1: List Your Riskiest Assumptions
Pull out the testable hypotheses you formulated during earlier work. If you completed the formulating testable hypotheses skill, use that output directly. If not, write down every assumption your product idea depends on: people have this problem, they will pay to solve it, the proposed solution actually solves it, the technology is buildable, and you can deliver it profitably. Rank these assumptions from riskiest to least risky.
Riskiest means the assumption that, if wrong, makes everything else irrelevant. Be honest. Teams often rank demand risk low because they have talked to a few friends who said the idea sounds cool. That is not validation.
Write down the evidence you have for each assumption and assess its strength.
Tip: If you cannot agree on the riskiest assumption, have each team member rank independently and then compare. Disagreement usually reveals that someone has customer evidence others have not seen. Surface it before choosing a format.
Step 2: Categorize the Top Risk
Take your riskiest assumption and categorize it into one of five buckets: demand risk, problem-solution fit risk, usability risk, feasibility risk, or viability risk. Demand risk means you are unsure whether anyone wants this at all. Problem-solution fit risk means you believe people want it but are unsure your specific approach solves the problem. Usability risk means the solution might work but people may not be able to use it.
Feasibility risk means the core technology might not be buildable within your constraints. Viability risk means you can build it and people want it, but you are unsure whether you can deliver it at a sustainable cost. Write one sentence naming the risk category and the specific assumption within it.
Tip: Viability risk is rarely the riskiest assumption for a brand-new product. If you find yourself categorizing it there, double-check that you are not skipping demand or problem-solution fit testing because those feel uncomfortable.
Step 3: Map Risk Category to MVP Type
Use this mapping to narrow your options. For demand risk, use a landing page MVP: a page describing the product with a signup form or payment button. For problem-solution fit risk, use a concierge MVP: deliver the service manually to a small number of customers and observe whether the workflow solves their problem. For usability risk, use a Wizard of Oz MVP: present a product interface that looks automated but is operated by humans behind the scenes.
For feasibility risk, use a single-feature MVP: build only the core technical capability and ship it with minimal surrounding product. For viability risk or integration risk, use a piecemeal MVP: stitch together existing tools (Zapier, Airtable, Stripe, Calendly) to simulate the product experience. This mapping is a starting point. Write down the one or two MVP types your risk category suggests.
Tip: If your risk spans two categories, lean toward the format that tests the harder-to-reverse risk first. Technical feasibility is harder to reverse than demand uncertainty, because you can always run a landing page later, but discovering an architecture problem after building a full product is expensive.
Step 4: Evaluate Resource Fit
For each candidate MVP type from Step 3, assess whether your team can actually execute it within your timeline and budget. A landing page MVP requires copywriting, basic web design, and a traffic source. A concierge MVP requires someone with enough domain expertise to manually deliver the service and enough time to serve 5-15 customers individually. A Wizard of Oz MVP requires a functional front end and a human operator who can respond in near real-time.
A single-feature MVP requires engineering capability to build production-quality code for one feature. A piecemeal MVP requires familiarity with no-code tools and the patience to duct-tape integrations together. If your top choice from Step 3 exceeds your resources, move to the next-best format. Write down the chosen format and why.
Tip: Be realistic about timeline. If you estimate two weeks for a single-feature MVP, triple it. If that makes the timeline unacceptable, switch to a lower-fidelity format. An imperfect test completed this month beats a perfect test completed in three months.
Step 5: Define the Success Metric
Every MVP needs a single primary metric that tells you whether the riskiest assumption was validated. For a landing page MVP, this is typically signup conversion rate, with a threshold like 5% of visitors sign up. For a concierge MVP, this might be retention across three manual service deliveries, or willingness to pay after the second session. For a Wizard of Oz MVP, this could be task completion rate or Net Promoter Score after the first interaction.
For a single-feature MVP, this might be weekly active usage after week two. For a piecemeal MVP, this is typically whether customers complete the full workflow end-to-end without needing to leave the tool chain. Write down one metric, one threshold, and one timeframe.
Tip: Resist the urge to define multiple success metrics. A single metric forces clarity. If you feel you need three metrics, you are probably testing three assumptions, which means you need to go back to Step 1 and pick one.
Step 6: Draw the Scope Boundary
Write an explicit list of what the MVP will not include. This is the most important part of the selection document because it prevents scope creep. For a landing page MVP, you are not building any product. For a concierge MVP, you are not automating anything.
For a Wizard of Oz MVP, you are not building backend infrastructure. For a single-feature MVP, list every feature you are deliberately omitting, including authentication, payment, onboarding, and analytics unless they are essential for the test. For a piecemeal MVP, list the limitations of the tool chain that you will accept. The scope boundary should feel uncomfortable.
If it does not, you are probably building too much.
Tip: Share the scope boundary with stakeholders before you start building. Anyone who will later say 'but we should also add X' needs to see this document now. Scope creep during an MVP experiment invalidates the experiment.
Step 7: Estimate Learning Timeline
Determine how long the experiment needs to run to produce a statistically or qualitatively meaningful result. A landing page MVP needs enough traffic to reach your conversion threshold, so estimate traffic volume and calculate days needed. A concierge MVP needs enough manual interactions to identify patterns, usually 5-15 customers over 2-4 weeks. A Wizard of Oz MVP needs enough usage sessions to measure the usability metric, typically 10-20 users over 1-3 weeks.
A single-feature MVP needs enough usage to measure retention, usually 2-4 weeks of active use. A piecemeal MVP needs enough end-to-end completions to assess workflow viability, usually 10-20 completions. Write down the estimated run time and the minimum sample size.
Tip: If your estimated learning timeline exceeds 6 weeks, consider whether a lower-fidelity MVP type could answer a related question faster. Speed of learning is the primary advantage of the Lean Startup approach. Slow experiments erode it.
Step 8: Assemble the MVP Selection Document
Compile your decisions into a one-page document with six sections: the riskiest assumption (from Step 1-2), the chosen MVP type and rationale (from Step 3-4), the success metric and threshold (from Step 5), the scope boundary (from Step 6), the learning timeline (from Step 7), and the team assignments. This document is the input for the building a minimum viable product skill. Share it with the full team and any stakeholders who will be involved in the build or the decision that follows the experiment. Get explicit agreement before proceeding.
If someone disagrees with the format choice, resolve it now. Disagreement during the build leads to scope creep.
Tip: Keep this document in a shared location everyone can reference during the build. When someone suggests adding a feature, point to the scope boundary. When someone questions the timeline, point to the learning timeline. This document is a shield against drift.
Examples
Example: Solo founder testing a B2C meal planning app idea
A solo non-technical founder believes busy parents would pay $10/month for personalized weekly meal plans that account for dietary restrictions, grocery budget, and cooking skill level. She has no engineering skills, $500 in budget, and wants to validate demand within two weeks.
The riskiest assumption is demand: will busy parents actually pay for meal plans when free recipes are everywhere? The risk category is demand, so the mapping points to a landing page MVP. Resource fit is perfect because a landing page requires only copywriting and a basic web builder, both within the founder's skills and budget. She builds a one-page site on Carrd ($19/year) with a clear headline ('Personalized Weekly Meal Plans for Busy Families, $10/month'), three bullet points explaining the service, and a Stripe checkout button.
She defines her success metric as 20 paid signups within 14 days, with a kill criterion of fewer than 5 signups. She spends $400 on Facebook ads targeting parents aged 28-42 in her metro area. The scope boundary explicitly excludes building any meal planning functionality. 2% conversion rate, validating demand.
She refunds all charges with a thank-you note and moves to a concierge MVP to test whether she can actually deliver personalized plans that parents use.
Example: B2B SaaS team testing an AI document review tool
A three-person team (two engineers, one domain expert) wants to build an AI-powered contract review tool for mid-market legal teams. They have a working prototype of the NLP model but are unsure whether legal teams will trust AI-generated annotations enough to change their workflow. Budget is $15,000 for the first three months. Timeline pressure is moderate.
The riskiest assumption is not feasibility (the prototype already works) but problem-solution fit: will legal teams actually use AI annotations in their existing review process? The risk category is problem-solution fit, pointing to a concierge MVP. However, the team realizes that the real question is whether lawyers will trust the annotations when they appear to come from software, not a human. This shifts the risk to usability of an automated experience, pointing to a Wizard of Oz MVP.
They build a simple web interface where lawyers upload contracts and receive annotated documents within 2 hours. Behind the scenes, the NLP model generates annotations and the domain expert reviews and corrects them before delivery. The success metric is whether 8 of 10 pilot lawyers accept at least 70% of annotations without modification after three documents each. The scope boundary excludes real-time processing, user accounts, billing, and integrations with legal software.
Over four weeks, they onboard 12 lawyers from three firms. Seven of twelve accept 75%+ of annotations. The five who do not cite specific annotation categories where trust is low. This produces a clear roadmap for which annotation types to prioritize in the single-feature MVP that follows.
Example: Small agency testing a productized service offering
A five-person digital marketing agency wants to launch a productized SEO audit service at $299/audit, targeting e-commerce stores with 500-5,000 SKUs. They currently do custom SEO work but believe a standardized offering could scale. They have deep SEO expertise, an existing client base to draw from, and want to validate the concept within three weeks with minimal new tooling.
The riskiest assumption is viability: can they deliver a standardized audit at a fixed price without spending more in labor than the $299 price covers? Demand is moderate-confidence because existing clients frequently ask for audits, but the team has never timed the workflow for a standardized version. The risk category points to a piecemeal MVP. They assemble the audit workflow from existing tools: Screaming Frog for crawl data, Ahrefs for backlink analysis, Google Sheets for the standardized report template, Calendly for booking, Stripe for payment, and Zapier to connect them.
The success metric is completing 10 audits within the three-week window, with an average labor time under 4 hours per audit (which makes the $299 price viable at their internal cost rate). The scope boundary excludes building any custom software, creating a dedicated website, or hiring additional staff. They email 50 existing contacts offering the service. Fourteen express interest, and 10 purchase.
5 hours, well above the 4-hour target. But they identify two steps that account for 60% of the time and can be templated. 2 hours. They validate both demand and near-viability, with a clear optimization path before scaling.
Example: Large team choosing between MVP types for an internal tool
A product team of eight at a mid-size company (400 employees) has been asked to build an internal tool that helps sales reps find the right case study to share with prospects based on industry, company size, and deal stage. Engineering capacity is available but the VP of Sales is skeptical the team understands the workflow well enough to build the right thing. Timeline is six weeks to demonstrate value.
The riskiest assumption is problem-solution fit: does the team understand the sales rep workflow well enough to build a tool that reps will actually use instead of their current habit of asking colleagues in Slack? The VP's skepticism makes this the clear top risk. The risk category points to a concierge MVP. A product manager volunteers to manually serve as the 'case study finder' for 15 sales reps over two weeks.
When a rep needs a case study, they message the PM in Slack with the prospect details, and the PM searches the existing library and responds within 30 minutes. The success metric is whether reps use the service at least three times per week and whether the case studies the PM finds are used in prospect communications. The scope boundary excludes any engineering work, any new tools, and any changes to the existing case study library. 1 requests per week.
The PM documents every search pattern, noting that 80% of requests can be served by filtering on just three attributes: industry, deal size, and use case. This learning shapes the single-feature MVP that engineering builds in the remaining four weeks, resulting in a search tool that the VP of Sales champions because the workflow was validated with real usage data before a line of code was written.
Best Practices
Test demand before testing usability or feasibility. If nobody wants the product, it does not matter whether the technology works or the interface is elegant. A landing page MVP is almost always the right first step unless you have strong demand evidence from customer discovery interviews. Skipping demand validation because it feels too simple is one of the most common reasons teams waste months building something nobody uses.
Choose the lowest-fidelity MVP type that can produce a trustworthy answer. Higher fidelity always costs more time and money. If you can learn what you need from a landing page, do not build a Wizard of Oz. If a concierge test works, do not write code.
The team that ships the cheapest experiment wins the most learning per dollar. Teams that default to high fidelity often do so because building feels more productive than experimenting, but feeling productive and being productive are different things.
Write the scope boundary before you write a single line of code or a single word of copy. Scope boundaries written after work begins are retrospective justifications, not constraints. Written beforehand, they are contracts that prevent the MVP from silently growing into a full product. Teams that skip this step typically ship something 3-5x larger than necessary.
Run one MVP type per riskiest assumption. Combining multiple types to test multiple assumptions in parallel sounds efficient but produces muddy results. You end up unsure which format generated which learning. Sequential experiments with clean separation produce clearer signals, even if they take longer calendar time.
Include a kill criterion alongside the success criterion. Define upfront what result would cause you to abandon or pivot the idea. If fewer than 2% of landing page visitors sign up, you will pivot the value proposition before testing anything else. Without a kill criterion, teams tend to reinterpret failed experiments as partial successes, which delays the honest reckoning that drives progress.
Use the piecemeal MVP more often than you think you should. Most teams underestimate how much you can simulate with existing tools. Zapier, Airtable, Typeform, Stripe, and Calendly can approximate remarkably complex workflows. The piecemeal approach is especially powerful when you are uncertain about the right workflow, because you can reconfigure tools in hours instead of rewriting code in weeks.
Revisit MVP type selection if your first experiment produces ambiguous results. Ambiguous outcomes often mean the format was wrong, not the idea. A landing page that gets moderate signups but no enthusiasm might need a concierge test to understand whether the problem is the value proposition or the presentation. Switching formats is not failure. It is part of the iterative learning process.
Common Mistakes
Defaulting to a single-feature MVP regardless of the risk being tested
Correction
This happens because building feels like progress, and engineers on the team want to write code. The signal to watch for is a team that jumps to technical architecture discussions before identifying the riskiest assumption. A single-feature MVP is only appropriate when the core risk is technical feasibility. If the risk is demand or problem-solution fit, you are building an answer to a question you have not asked.
Go back to Step 2 and categorize the risk honestly. If it is demand risk, use a landing page. If it is workflow risk, use a concierge test.
Testing demand with a landing page but using the wrong traffic source
Correction
A landing page MVP requires traffic to produce meaningful results. Teams often launch a landing page and then share it with friends, family, and their existing social network. This audience is biased toward encouragement and does not represent real market demand. The signal is high signup rates from low volumes of known contacts.
Use paid ads targeting your actual customer segment, post in communities where your target audience already gathers, or use cold outreach to people who match your persona. The traffic source must reflect the real acquisition channel you would use at scale.
Running a concierge MVP without tracking the manual effort required
Correction
The purpose of a concierge MVP is not just to validate the workflow. It is also to understand the operational cost of delivering the service, which informs whether the business is viable and what needs automation. Teams get so focused on customer satisfaction that they forget to log how many hours each customer interaction takes, what steps require specialized expertise, and where the process breaks down. Without this data, you validate the solution but have no basis for scoping the real product.
Keep a simple time log for every manual delivery session.
Confusing Wizard of Oz with concierge and picking the wrong one
Correction
The distinction matters. In a concierge MVP, the customer knows a human is doing the work. In a Wizard of Oz MVP, the customer believes they are interacting with an automated product. The Wizard of Oz tests whether the automated experience would satisfy users.
The concierge tests whether the underlying service solves the problem. If you use concierge when you should use Wizard of Oz, you learn whether the service works but not whether the product experience works. Watch for this confusion when the team says 'let us just do it manually' without specifying whether the customer knows it is manual.
Letting the MVP grow past its scope boundary during the build phase
Correction
This is the most common and most damaging mistake. ' Each addition feels small, but collectively they transform a two-week experiment into a two-month product build. The signal is any task that is not directly required by the success metric defined in Step 5. ' If the answer is no, it goes on the post-MVP list.
Enforce the scope boundary from Step 6 ruthlessly.
Selecting an MVP type based on what competitors have built rather than what you need to learn
Correction
Teams research competitors and see polished products, then feel pressure to match that fidelity. But a competitor's current product is the result of years of iteration, not their first experiment. Your MVP is not a competitor. It is a learning tool.
' Redirect the conversation to your riskiest assumption. What do you need to learn? That question, not competitor benchmarking, should drive the format choice.
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.
Building a Minimum Viable Product (MVP)
How to design and build the smallest possible version of your product that allows you to test core assumptions with real customers.
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 choose the right type of MVP when multiple risks feel equally important?
Force-rank by asking: 'If this assumption is wrong, does anything else matter?' Demand risk almost always outranks other risks, because a perfectly built product that nobody wants is worthless. If two risks genuinely feel tied, test the cheaper one first. The goal is to eliminate risks sequentially, not to find the one perfect experiment that resolves everything. Run the faster, cheaper test, learn from it, and then address the next risk with a follow-up MVP.
Can I combine multiple types of MVP into one experiment?
You can run separate MVP experiments in parallel if they test different assumptions, but do not merge two types into a single experiment. For example, you could run a landing page MVP to test demand while simultaneously running a concierge test with a different group to validate the workflow. The key rule is that each experiment should have one success metric and test one assumption. Hybrid experiments produce ambiguous results because you cannot attribute the outcome to either format.
How long should MVP type selection take before I start building?
The selection process described in this skill should take 1-2 hours for a small team and up to half a day if you need to align stakeholders. If you are spending days debating the format, you are likely disagreeing about the riskiest assumption, not the MVP type. Resolve the assumption disagreement first by reviewing customer evidence together. Once the riskiest assumption is clear, the format usually follows obviously from the risk-to-type mapping.
Should I select the MVP type before or after conducting customer discovery interviews?
After. Customer discovery interviews, covered in [conducting customer discovery interviews](/skills/conducting-customer-discovery-interviews), provide the evidence you need to identify and rank your riskiest assumptions. Without that evidence, MVP type selection becomes a guessing game. If you have not done customer discovery yet, your first step is not an MVP. It is a conversation with potential customers. The exception is if you have strong demand signals from other sources, like existing waitlists, inbound requests, or market data.
Why does my MVP keep growing beyond its original scope?
Scope creep in MVPs usually happens for one of three reasons. First, the scope boundary was not written down explicitly before the build started, so there is no shared reference to point to when someone suggests an addition. Second, the team is emotionally attached to the idea and unconsciously inflates the MVP to match their vision of the final product. Third, early feedback from test users introduces new feature requests that feel urgent. The fix is structural: write the scope boundary in Step 6, share it with all stakeholders, and enforce a rule that any proposed addition requires removing something of equal effort. This creates a real cost for scope expansion.
When is a piecemeal MVP a better choice than a concierge MVP?
Use a piecemeal MVP when you want to test the end-to-end customer experience at moderate scale without dedicating a person to manual delivery. A concierge MVP requires a human to serve each customer individually, which limits you to 5-15 customers and produces qualitative insight. A piecemeal MVP built from tools like Zapier, Airtable, and Stripe can serve 50-100 customers with minimal ongoing effort, producing quantitative data on conversion and retention. Choose concierge when you need deep qualitative understanding of the workflow. Choose piecemeal when you need broader quantitative validation.
How do types of MVP relate to the build-measure-learn cycle?
MVP type selection is the critical decision that determines the shape of the entire build-measure-learn cycle. The type you choose dictates what you build (a landing page, a manual service, a front-end shell, a coded feature, or a tool integration), what you measure (conversion, satisfaction, completion, retention, or cost), and what you learn (whether people want it, whether it works, or whether you can deliver it). Every cycle through the loop in the [Lean Startup](/methods/lean-startup) framework should begin with a conscious choice about MVP type, because the same idea may need different formats at different stages of validation.