The phrase "minimum viable product" has been so thoroughly mangled by conference talks and startup lore that most PMs use it without knowing what it actually means. When someone says "we're building an MVP," what they usually mean is "we're building something cheap and fast." That is a budget decision, not a product definition. And if you make product decisions dressed up as budget constraints, you will ship something that validates nothing, attracts no one, and leaves you with data that cannot inform the next step.
The real definition is older and more precise than the startup ecosystem's version: an MVP is the minimum set of functionality that lets you test a specific hypothesis with real users and get data that actually informs the next decision. The key words are "test," "hypothesis," and "real users." Ship the wrong thing to the wrong audience and call it an MVP, and you have spent eight weeks learning nothing.
Why Most MVPs Fail to Be Viable
There are two failure modes that show up in almost every failed MVP post-mortem. They look different on the surface but share the same root cause: the team confused "minimum scope" with "minimum value."
1. The scope is minimum, the value is zero
You ship something so stripped-down that it does not actually solve the problem you claim to solve. Users land, look around, and leave because the product does not deliver enough value for them to care. You have an MVP in name — it exists and it was cheap to build — but it is not viable. "Viable" does not mean "technically works." It means "delivers enough value that a real user in your target segment will actually use it and come back."
A CRM MVP that stores contacts but cannot do anything with them is not viable. A reporting tool MVP that generates a PDF but requires manual data entry is not viable. You are measuring the wrong thing when you measure only how cheap and fast the build was.
2. The value is there, but the hypothesis is wrong
You build something that users love — but you built it to test the wrong assumption. You assumed users would pay for automated reports, so you built a beautiful report automation system. What you actually proved was that users will use a manual reporting tool if it is well-designed. The data is real, but it does not answer the question you thought you were asking. This is a hypothesis design problem, not a product quality problem.
The Hypothesis-First MVP Definition Process
The fix for both failure modes is the same: put your hypothesis before your scope. Here is the process that prevents you from building the wrong thing cheaply.
Step 1: Write the hypothesis before you open a design tool
Every MVP starts with a written hypothesis. Not a feature list. Not a problem statement. A specific, testable claim about what will happen when real users interact with your product. The format: "We believe [user type] will [do this action] when we [build this capability] because [this observation]."
Good hypothesis: "We believe sales managers at Series A SaaS companies will use automated call summaries instead of manually reviewing call recordings because they save 45 minutes per week per rep and currently have no structured summary process."
Bad hypothesis: "We believe users want a better way to manage their sales calls."
The good hypothesis tells you exactly what to build and exactly how to measure success. The bad hypothesis could justify building anything. Write the hypothesis first, and the scope discussion becomes much simpler — you are no longer debating "what should we include" but "what proves this hypothesis."
The Hypothesis Test
Ask yourself: if this hypothesis is true, what must be true about the user's behavior? In the sales manager example: (1) they currently manually review call recordings, (2) they would save time with automated summaries, (3) they would act on those summaries in their workflow. If any of those three things is not true, the hypothesis fails even if the product is well-built. Build what tests all three, not just one.
Step 2: Define the minimum complete user journey
Once you have a hypothesis, identify the shortest user journey that proves it. A user journey has a beginning, a middle, and an end. If your hypothesis is about automated summaries, the journey is: user records a call → system produces a summary → user acts on the summary → user saves time. If you cannot complete that journey in your MVP, you cannot test your hypothesis.
For the hypothesis to be testable, it needs to produce a binary outcome you can measure: did the user do the thing or not? "Users will use automated call summaries" is not a testable hypothesis. "At least 40% of users who record a call will open the summary within 24 hours" is.
Drawing a complete journey also surfaces what actually belongs in scope. If the journey requires the user to be able to record, transcribe, summarize, share, and revisit the summary — all five steps are in scope for the MVP, because removing any one of them breaks the hypothesis test. "Minimum" in minimum viable product means the minimum required to complete the journey — not the minimum you feel comfortable spending.
Step 3: Separate must-have from nice-to-have using the hypothesis lens
Most feature debates happen because the team is asking the wrong question. "Should we include team permissions in the MVP?" is only answerable if you know what the MVP is testing. If the hypothesis is about individual user behavior with automated summaries, team permissions are a nice-to-have. If the hypothesis is about team collaboration around call insights, team permissions are a must-have.
The decision filter is simple: does this feature or capability directly affect the user's ability to complete the core journey and produce the testable outcome? If yes, it is in scope. If no, it is out. When in doubt, leave it out — a focused MVP that tests one hypothesis well is more valuable than a broad MVP that tests several hypotheses poorly.
The Four MVP Archetypes
Not all MVPs look the same. The right archetype depends on what you are testing and what resources you have available. Here are the four most common, with the hypothesis each one is designed to test.
Concierge MVP
You manually deliver the service before you automate it. The hypothesis: "users will value this outcome if we can deliver it manually, so it is worth building the product." A concierge MVP for a B2B scheduling tool might be an assistant who manually coordinates meeting times on behalf of users before building any software. If no one signs up for the manual service, do not build the software. If people do, the manual operation becomes a forcing function for the product spec — you know exactly what the software needs to do because you have been doing it manually.
Wizard of Oz MVP
The user interacts with what looks like a full product, but the backend work is done by humans. The hypothesis: "users will value the experience enough to pay, even if we have not built the automation yet." Dropbox famously used this — the product looked full-featured, but the actual sync was manual behind the scenes. The wizard of Oz works when you need to test whether users care about the outcome, not the process of getting there.
Single-Feature MVP
You build one feature, fully polished, and ship nothing else. The hypothesis: "this one feature alone delivers enough value to acquire and retain users." This is the most common SaaS MVP pattern. The discipline is resisting the urge to add "just one more" feature in the same release. If the single feature does not work, you learn that the feature is not compelling — not that the product is incomplete.
Landing Page MVP
You describe the product before you build it and measure whether people sign up or express interest. The hypothesis: "enough people in our target segment will want this to justify building it." This is a low-investment test that works for consumer products and features where you can communicate the value proposition in a single page. A landing page that gets 500 signups in a week tells you something. A landing page that gets five signups in two months tells you something else. The key is directing real traffic — your colleagues do not count.
The archetype mistake: Picking an MVP archetype based on what is fastest to build, not on which one best tests your hypothesis. A landing page tests whether people want the idea. It does not test whether they will use it, pay for it, or stick with it. If your hypothesis involves ongoing usage or revenue, you need an MVP archetype that produces those behaviors — not just intent signals.
Defining MVP Scope: The Three Criteria
When you are in a scope debate and the hypothesis lens is not resolving it, apply these three criteria to every candidate feature. All three must be yes to include it in the MVP.
1. Does it enable the core journey?
If removing this capability breaks the complete user journey that tests your hypothesis, it stays in scope. If it makes the product nicer but the journey still works without it, it does not belong in the MVP.
2. Does it produce data for the hypothesis test?
If the feature will not help you evaluate whether your hypothesis is true, it is not helping you learn. Learning is the point of an MVP — not shipping a product that looks finished.
3. Can a user complete the journey without external tools?
If your MVP requires the user to use a spreadsheet, a third-party tool, or a manual workaround to complete the core journey, you have not built an MVP — you have built a feature that needs a product around it. The MVP must be self-contained enough that a user can test your hypothesis without cobbling together multiple tools.
Evaluating an MVP: Setting Success Criteria Before You Build
The most common reason teams learn nothing from their MVP is that they did not define success before they built. You cannot evaluate a result you did not define in advance — you can only describe it, which is not the same thing.
Define success criteria when you write the hypothesis. If your hypothesis is "40% of recording users open the summary within 24 hours," you have a measurable success threshold. When the MVP launches, you either hit 40% or you do not — and the next decision is clear either way.
If your hypothesis involves revenue, set a revenue threshold. If it involves engagement, set an engagement threshold. If it involves retention, define how many sessions or days count as "retained." Do not leave success to interpretation. The moment you catch yourself saying "we will know it when we see it," you have already lost — because you will always see something, and you will always be able to interpret it as success.
Set a decision point at the same time you set the success criteria. "If we hit 40% summary open rate within 30 days of launch with at least 100 active users, we invest in building out the collaboration features. If we do not, we revisit the core value proposition and potentially deprioritize the project." Clear decisions, not ambiguous next steps.
What to Do When an MVP Fails
An MVP that does not hit success criteria is not a failure — it is data. The failure is continuing to iterate on the same hypothesis after you have enough evidence to conclude it is wrong.
When an MVP misses its targets, the first question is not "how do we fix this MVP" — it is "what does this data tell us about our hypothesis?" If the open rate is low, it could mean users do not trust automated summaries, do not see the value in 24 hours, or do not have a workflow that fits automated summaries. Each of those interpretations points to a different next step. Guessing at which one is right without data is where teams waste months.
Run a follow-on user interview with the users who tried the MVP. The 20% of users who opened the summary every time have something to teach you that the 80% who never opened it can also teach you. The engaged users will tell you what they value. The disengaged users will tell you what they expected that they did not get. Both are valuable. Both inform the next version.
Connecting MVP to the Broader PM Workflow
MVP building does not happen in isolation. It is one step in a continuous cycle that starts with product discovery and ends with the next round of learning.
Before you define an MVP, run a discovery process to validate that you are solving a real problem for a real user in a segment worth pursuing. Discovery is where you develop the hypothesis in the first place — it is not a separate exercise from MVP definition but the input that makes the definition credible. See our product discovery process guide for how to validate before you build.
After the MVP, when you have validated or invalidated the hypothesis, you move into a product launch process. An MVP that hits success criteria still needs to be launched correctly — and that means preparing for the full market, not just the early adopters who found you through a beta waitlist. See our product launch guide for how to take a validated MVP and introduce it to the broader market.
ChiefProduct helps you maintain the feedback loop between what you ship and what your users actually do with it. While you are iterating on the MVP-to-market cycle, ChiefProduct continuously synthesizes your product metrics and customer feedback — surfacing signals that might indicate your hypothesis needs updating before you have enough data to notice it yourself.