A founder can walk into a meeting with a working MVP, a clean deck, a demoable AI feature, and a confident fundraising story, and still have almost no proof.
The MVP may prove the team can ship. It may prove the interface can exist. It may prove the demo looks real. But it may not prove the thing that matters: a specific customer will change behavior because of the product.
That is the job of an MVP.
TL;DR
An MVP is not a smaller version of your future product. It is the smallest product experience that tests whether one specific customer type cares enough about one painful problem to act.
To build a minimum viable product without wasting engineering time:
Pick one narrow ICP.
Define one painful job.
Write the behavior you need to observe.
Cut every feature that does not test that behavior.
Build the smallest coherent workflow.
Test it with structured users or design partners.
Decide whether to continue, narrow, reposition, or stop.
Do not build the product. Build the proof.
What is an MVP?
An MVP, or minimum viable product, is the smallest usable version of a product that helps you learn whether a core business assumption is true. A good MVP tests whether a specific customer will take a specific action to solve a specific pain.
Eric Ries helped make the term mainstream through The Lean Startup, which frames startup work around learning with less waste. The useful part for founders is the learning constraint: the MVP exists to answer a question. You can read the original Lean Startup principles here: The Lean Startup principles.
For founders, the practical definition is simpler:
An MVP is the smallest real product experience that tests whether a specific customer will take a specific action to solve a specific pain.
“Minimum” does not mean broken, ugly, or careless. It means no extra surface area.
“Viable” does not mean complete. It means the experience is good enough for the customer to attempt the core behavior.
If your MVP cannot produce a decision, it is probably too vague. A good MVP should tell you something like:
This customer cares enough to keep using it.
This customer likes the idea but will not change behavior.
The pain is real, but the buyer is different from the user.
The workflow is too narrow.
The product should stop here.
The MVP is a step toward product-market fit, not proof that you have it.
The common mistake: building a mini-product
The easiest way to waste engineering time is to build a miniature version of the final product.
A mini-product asks: “What features should version one have?”
An MVP asks: “What behavior must we prove?”
Those are different questions.
Take a B2B founder building a sales coaching tool. The first feature list can get big fast: call recording, AI transcripts, objection tagging, rep scorecards, manager dashboards, Slack alerts, CRM sync, role permissions, and analytics.
That scope looks responsible. It also hides the real test.
The core question might be:
Will a frontline sales manager use AI call feedback to change rep coaching behavior this week?
If that is the question, most of the first scope is noise. The MVP might be:
Upload one sales call.
Return three missed discovery questions.
Send one plain report to the manager.
Observe whether the manager uses it in the next 1:1.
That is not the final product. It is a behavior test.
Start with one customer, one pain, one workflow, one signal
Before you build minimum viable product scope, write these four things down. This is the fastest way to turn a vague MVP into something engineering can build and test.
Element | Question to answer | Example |
|---|---|---|
Customer | Who exactly are we learning from? | Frontline sales managers at B2B SaaS companies with a small team of reps |
Pain | What painful job are they already trying to solve? | New reps ask weak discovery questions and managers catch it too late |
Workflow | What product action will test the promise? | Upload a call and receive a coaching report before the next 1:1 |
Signal | What behavior suggests real interest? | Several managers use the report in a real 1:1 during the test period |
The narrower the customer, the easier the MVP gets.
“Sales teams” is too broad. “B2B sales managers coaching new outbound reps every week” is much better.
“Founders” is too broad. “Pre-seed B2B founders doing customer interviews every month” is better.
A broad ICP makes every feature feel necessary. A narrow ICP makes cuts obvious.
Write the MVP hypothesis before writing tickets
A strong MVP hypothesis names the customer, pain, workflow, and success signal before the team starts building.
Use this template:
If [customer] has [pain], they will [behavior] when given [workflow], and we will know because [signal].
Example hypotheses:
Sales coaching MVP: If frontline B2B sales managers struggle to coach weak discovery calls, they will upload one call and use a plain feedback report in their next rep 1:1, and we will know because several design partners use it in a real coaching meeting during the test period.
Interview notes MVP: If pre-seed B2B founders struggle to make sense of customer interviews, they will return after each interview to structure notes around hypotheses, and we will know because they process multiple interviews without being reminded.
Marketplace MVP: If startup founders need vetted landing page designers quickly, they will pay for a manually matched introduction, and we will know because qualified buyers accept a shortlist and some pay for the match.
The hypothesis protects you from building “useful” features that do not answer the main question.
Before you build, ask whether code is needed
Sometimes the best MVP is not software yet.
If the riskiest assumption is demand, you may be able to test before engineering starts. Fake door tests, concierge tests, manually matched workflows, and clickable prototypes can all reduce waste.
A fake door test is useful when you need to know whether people will click, request, apply, reserve, or start a workflow before the feature exists. For examples, see these fake door test examples.
Use this decision rule before assigning engineering time:
Question | If yes | If no |
|---|---|---|
Can demand be tested before code? | Run a fake door, landing page, sales outreach, or manual offer first. | Move to workflow testing. |
Does the customer need a working experience to reveal behavior? | Build the smallest coherent workflow. | Use a prototype, manual delivery, or interview-based validation. |
Does the workflow require repeated use or implementation context? | Recruit design partners. | Test with structured one-off users. |
Do not use this as an excuse to avoid shipping. Use it to avoid building the wrong thing.
The MVP Scope Filter
A feature is essential only if removing it breaks the test.
Use this filter before engineering starts. If a feature does not test the core value proposition or enable the first meaningful user action, it probably does not belong in the MVP.
Keep for the first test
One call upload: tests whether the manager has a real call they want reviewed.
Three missed discovery questions: tests whether the report can create coaching value.
Plain manager report: tests whether the manager can use the output in a 1:1.
Move later unless the test breaks without them
AI transcript editor: keep only if transcript cleanup blocks value.
Manager dashboard: delay until you know managers need a persistent analytics view.
CRM sync: delay unless integration is required to try the workflow.
Role permissions: delay unless multiple roles must access the MVP on day one.
Cut from the first test
Slack alerts: useful only if alerts are part of the behavior being tested.
Historical analytics: trend data can wait until repeated use exists.
Admin polish: keep only the trust and safety basics the workflow needs.
Some features are needed for trust, safety, data integrity, payment, or legal use. Keep the smallest responsible version of those.
But be honest about edge cases. Profile settings, location rules, chat preferences, rare permissions, custom exports, and admin polish can be technically easy and still wrong for MVP scope.
Rare but technically feasible is usually outside MVP scope.
The Core Value Proposition Test worksheet
Before the team builds, fill this out in plain language. Keep it lightweight: one page, one test, one decision.
ICP: Who exactly are we testing with?
Pain: What painful job do they already have?
Current workaround: How do they solve it now: spreadsheet, intern, agency, manual process, or ignoring it?
MVP action: What is the one action the user must take?
Success signal: What behavior would show they care?
Design partners: Who will test this in a real context?
Feedback cadence: How often will you collect structured feedback?
Cut list: Which requested or tempting features are outside the test?
Decision rule: What result means continue, narrow, reposition, or stop?
A weak answer sounds like:
Busy teams need better coaching, so we will build an AI dashboard and see if they like it.
A stronger answer sounds like:
Frontline sales managers at B2B SaaS companies with a small team of reps already review calls manually before 1:1s. We will let them upload one call and receive three missed discovery questions. Success means several managers use the report in a real 1:1 during the test period.
That second version is easier to build because it is easier to cut.
Use a short scope check
This is not a rule that every MVP must ship in two weeks. Some products have security, compliance, data, marketplace, hardware, or enterprise constraints.
But as a forcing function, a short scope check is useful.
Ask:
If we had to test the core behavior in weeks, what would we build?
If the answer is still a full dashboard, integrations, permissions, personalization, onboarding, analytics, and multiple user roles, you may be testing too many things at once.
A short scope check often exposes one of three problems:
The ICP is too broad.
The pain is not specific enough.
The success signal is not behavioral.
Fix those before adding engineers.
Build the smallest coherent workflow
Do not ship fragments. Ship a thin workflow that lets the customer experience the core promise.
For the sales coaching example, that workflow is:
Manager uploads one call.
Product analyzes the call.
Product returns three missed discovery questions.
Manager uses the report in a rep 1:1.
Founder follows up to learn what changed.
This can include manual work behind the scenes. The user does not need to know whether every step is automated. They need a believable experience that lets them decide whether the outcome matters.
For an AI assistant, the MVP might be one chat command that completes one painful recurring task, with manual review in the background.
For a marketplace, the MVP might be manually matching a small set of buyers with vetted sellers before building profiles, ratings, payment flows, and dispute systems.
For a healthcare admin product, the MVP might be a concierge workflow with redacted sample data and one clinic role. That does not mean skipping compliance where it matters. It means keeping the test focused on one recurring admin task.
Minimum does not excuse sloppiness. It removes everything that does not affect the learning.
Test behavior, not compliments
The most dangerous MVP feedback is polite enthusiasm.
Founders often ask:
Would you use this?
That question invites fantasy. Ask about past behavior instead:
How did you solve this last time?
What broke?
Who was involved?
What did it cost in time, money, delay, risk, or reputation?
What did you try before?
Why did the old solution fail?
What would need to happen for you to use this in your real workflow next week?
The goal of discovery is not to collect requests. It is to build a mental model of how the customer thinks about the pain, the workaround, the risk, and the decision.
That mental model is what keeps the MVP from turning into a wishlist.
Use design partners when the workflow needs context
Casual users are fine for simple tests. Design partners are better when the product touches a repeated workflow, team process, budget owner, or implementation habit.
A good design partner is not just someone who “likes the idea.” They agree to give structured feedback while trying the product in a real context.
Use design partners when:
You need repeated use, not a one-time click.
The workflow touches multiple people.
The customer has existing tools and constraints.
You need to understand why adoption fails.
You are testing willingness to pay or commit.
Do not let design partners become outsourced product managers. Their job is to expose reality, not define your roadmap.
A simple design partner agreement can include:
Item | What to define |
|---|---|
Customer context | Team size, role, current workflow |
Test period | The shortest responsible period for the workflow |
MVP workflow | The exact action they will try |
Feedback rhythm | Weekly call, async notes, or shared doc |
Success signal | Usage, payment, meeting use, workflow change, or referral |
Boundaries | What you are not building yet |
The more structured the feedback loop, the less likely you are to mistake “nice feature request” for “must-have MVP scope.”
Measure the right signal
Different MVPs need different signals. YC's MVP planning advice is a useful companion here because it focuses the team on what the first version needs to learn: How to Plan an MVP.
The signal should show behavior, not opinion.
Product type | Weak signal | Better signal |
|---|---|---|
B2B SaaS | Waitlist signup | Design partner uses it in a real workflow |
Sales tool | “Looks useful” | Manager uses output in next team meeting or 1:1 |
Marketplace | Buyer says they are interested | Buyer pays for a manually matched introduction |
Founder tool | User tries once | User returns after each interview or planning session |
AI assistant | User likes demo | User delegates the same task repeatedly |
Internal workflow tool | Employee compliments UI | Team changes process around the output |
Signups can be useful, but they are often too soft. Repeated use, payment, booked follow-ups, implementation effort, and referrals usually tell you more.
Decide what the MVP means
An MVP should end with a decision, not a vague feeling.
Use this rule:
What happened | Decision |
|---|---|
Right customers use it repeatedly and ask for a narrow set of improvements | Continue |
Some customers care deeply, but the ICP is narrower than expected | Narrow |
Pain is real, but the workflow or buyer is wrong | Reposition |
Users praise it but do not act | Stop or redesign the test |
Users ask for many unrelated features | Revisit ICP and pain |
Adoption depends on one missing trust, legal, data, or workflow requirement | Add the smallest version of that requirement |
The wrong lesson is “users asked for more features.”
The better lesson is “which missing piece blocked the behavior we were testing?”
A short checklist before engineering starts
Use this before opening tickets:
We have one ICP, not a market category.
We know the painful job they already try to solve.
We have evidence of past behavior, not only stated interest.
We have one MVP hypothesis.
We know the first meaningful user action.
We know the success signal before building.
Every kept feature is required for the test.
Rare edge cases are cut unless they block trust, safety, data integrity, payment, or legal use.
Manual work replaces automation where possible.
Feedback will come from structured users or design partners.
The MVP can produce a decision: continue, narrow, reposition, or stop.
If you cannot answer these, do not add scope. Tighten the test.
FAQ
How long should it take to build an MVP?
Long enough to test the core behavior responsibly, but not long enough to build the full product. Use a short scope check to expose bloat, then adjust for real constraints like compliance, data, or integrations.
What should I cut from an MVP?
Cut anything that does not test traction for one ICP and one important pain. If the user can still take the action you need to observe without the feature, move it later.
Do I need code for an MVP?
Not always. If you are testing demand, a fake door test, landing page, concierge workflow, manual offer, or prototype may be enough. If you are testing workflow change, you probably need a working experience.
How do I know if my MVP worked?
You have stronger evidence when the right customer takes the target action: repeats the workflow, pays, commits time, books the next step, changes a process, or refers someone else.
How polished should an MVP be?
Polished enough that the customer can trust and complete the core workflow. Not polished enough to look like a mature product.
Can an MVP have manual work behind the scenes?
Yes. If the customer cares about the outcome, you can automate later. If they do not care, automation only makes the wrong thing faster.
What is the biggest MVP mistake?
Building proof that the product can exist instead of proof that customers care.
