Minimum Viable Product: What to Build First and What to Skip

A team spends six weeks building an AI assistant.

It has onboarding, settings, a workflow builder, a half-finished evaluation layer, and a Product Hunt launch plan. It looks like an MVP.

But nobody has proved that one specific buyer has the workflow problem, will send real inputs, will stop using the old process, or will pay for the result.

The MVP was not too big because it had too many features. It was too big because it tested the wrong thing.

TL;DR

A minimum viable product is not the smallest product you can ship. It is the smallest credible build or test that teaches you whether a risky assumption is true.

Use an MVP when you already have some evidence of pain, demand, or current behavior, but still need to test one important belief before spending more time and money.

Do not scope from the roadmap. Scope from the risk.

The central question is:

What is the smallest credible thing we can put in front of a real buyer that will force a decision?

That decision might be: pay, commit time, send data, change workflow, invite a teammate, use it again, or say no clearly enough that you learn what was wrong.

What is a minimum viable product?

A minimum viable product is the smallest credible version of a product, service, workflow, or test that helps you learn whether a risky assumption is true. It should create evidence from real buyer behavior, not just opinions. The point is to test demand, workflow fit, or willingness to pay before you commit to a larger build.

That assumption is usually one of three things:

The MVP is not the product vision. It is the first serious test of the product logic.

If the MVP cannot teach you anything specific, it is likely just a reduced feature list.

What an MVP is not

An MVP is not automatically:

• a landing page

• a buggy product

• a cheap version of the final app

• a prototype

• a beta

• a Product Hunt launch

• a three-feature version of a ten-feature roadmap

• a no-code build

• a public release

Those can all be useful. None of them is automatically an MVP.

A landing page can be a smoke test if it measures intent before you build. A prototype can help if the risk is comprehension. A beta can help when demand exists and you need real usage feedback from beta customers. A paid pilot can be the right MVP when a B2B buyer needs to see the workflow inside their company before committing.

The format matters less than the learning.

MVP vs prototype vs beta

Founders often use these words as if they mean the same thing. They typically do not.

A prototype shows how something might work. It is useful when you need to test understanding, flow, or desirability before real usage.

An MVP tests behavior. It asks whether a real buyer or user will do something meaningful: pay, share data, switch workflows, invite a teammate, return, or commit time.

A beta tests a more complete product with early users. It is useful after you already have enough evidence to justify real usage feedback.

If you are asking, "Do people understand this?" you may need a prototype. If you are asking, "Will people act?" you need an MVP. If you are asking, "Does this hold up with real users?" you may be ready for a beta.

When should you use an MVP?

Use a minimum viable product when you have enough early evidence to justify a focused test, but not enough evidence to justify building the full product.

That usually means you have already done some version of:

• customer interviews

• research into current workarounds

• manual delivery

• waitlist or offer testing

• conversations with buyers

• proof that the pain exists outside your imagination

If you are still unsure who the buyer is, start with how to validate a product idea or a broader business idea validation process before building.

If you know the buyer but do not know whether demand is real, collect proof of demand first. If you need concrete patterns, study proof of demand examples and market validation examples.

An MVP is useful after the question changes from "Does anyone care?" to "What is the smallest version that can prove the next important thing?"

What to prove before you build

Before building, look for evidence from real behavior, not politeness.

Weak evidence sounds like:

• "That's interesting."

• "I would use that."

• "Keep me posted."

• "This could be big."

• "We hate spreadsheets."

Better evidence sounds like:

• "We do this manually every Friday."

• "We already pay someone to solve part of this."

• "We built a workaround in Airtable."

• "We tried two tools and stopped using both."

• "Can you run this on our data this week?"

Strong evidence looks like:

• payment

• deposit

• paid pilot

• data shared

• calendar time committed

• workflow switch

• repeated use

• introduction to the budget owner

• acceptance of a sharp tradeoff

Three users sending messy files by Friday is stronger evidence than 300 people saying the idea sounds interesting.

If you need better interview prompts, use customer discovery questions and customer research questions. Ask about previous behavior, current workarounds, switching costs, and what already gets budget.

How to build a minimum viable product

Most founders start with the roadmap and ask, "What can we remove?"

Better question: "What must we learn next?"

Use this seven-step scoping pass:

1. Pick one narrow ICP.

2. Name the painful situation.

3. Identify the current workaround or substitute.

4. Choose the riskiest assumption.

5. Define the behavior that would count as evidence.

6. Build the smallest credible version that can trigger that behavior.

7. Decide in advance what result means continue, change, or stop.

The narrow ICP matters. "All founders" is too broad. "Seed-stage B2B SaaS founders who manually prepare investor update metrics every month" is much better. You will learn faster because the workflow, pain, language, and buying trigger are more specific.

Also, do not confuse the internal mechanism with the sellable thing.

"Date of birth" is only an input. The sellable thing might be the chart, card, spread, compatibility read, or decision ritual someone wants to save, share, understand, or pay for.

The same applies to AI products. The model is rarely the whole product. The product is the surrounding system: the input, workflow, output, trust layer, handoff, and reason someone comes back.

MVP scoping checklist

Use this before writing tickets. It should fit into a larger business validation plan, because the MVP is one step in the sequence, not a substitute for thinking.

• Who is this for? One narrow buyer or user segment.

• What painful job are they already trying to solve? A current behavior, not a hypothetical wish.

• What do they use today? Spreadsheet, agency, employee, manual process, direct competitor, or substitute.

• What is the riskiest assumption? Demand, workflow, delivery, trust, pricing, or repeat use.

• What behavior proves they care? Payment, data, time, switch, repeated use, referral, budget step.

• What is the smallest credible test? Manual, concierge, fake door, pilot, prototype, smoke test, or narrow build.

• What will you skip? Anything that does not affect the evidence you need.

Small does not mean vague. A good MVP is narrow and sharp.

Build vs. test decision table

If you face uncertainty, align your next move with the specific risk.

Discovery and demand risk

Execution and traction risk

Do not skip the part that makes the test credible. If the user needs to trust the result, the MVP must be trustworthy. If the buyer needs to understand the value, the MVP must make the value obvious. Removing the thing that carries the value is not lean. It is just broken.

Build first, skip for now

Focus on core elements and skip premature polish.

• Build first: One core workflow. Skip for now: Full platform.

• Build first: One ICP. Skip for now: Universal positioning.

• Build first: One measurable behavior. Skip for now: Vanity launch metrics.

• Build first: One output users care about. Skip for now: Admin polish.

• Build first: Manual backend if acceptable. Skip for now: Premature automation.

• Build first: Basic trust and reliability. Skip for now: Edge-case settings.

• Build first: The smallest payment or commitment path. Skip for now: Complex billing.

• Build first: A clear feedback loop. Skip for now: Dashboards nobody asked for.

MVP examples by type

Concierge MVP

Use it when: You need to prove the outcome matters.
What you build: Manually deliver the result for a few users.
What you measure: Do they return, pay, or ask for another run?

Wizard-of-Oz MVP

Use it when: The interface matters but automation is not proven.
What you build: Simple front end, manual backend.
What you measure: Do users behave as if the product is useful?

Smoke test

Use it when: Demand is unclear.
What you build: Landing page or offer page.
What you measure: Do qualified buyers request access, pricing, or a next step?

Fake-door test

Use it when: A feature or promise may not matter.
What you build: Button, page, or offer before full build.
What you measure: Do users click, opt in, or request it?

Paid pilot

Use it when: B2B value and payment are the risk.
What you build: Manual or thin workflow for one buyer.
What you measure: Will they pay and involve the team?

Prototype

Use it when: Comprehension is the risk.
What you build: Clickable mockup or demo.
What you measure: Do users understand the flow and ask to use it?

Single-feature MVP

Use it when: Demand is known, scope is the risk.
What you build: One painful job for one ICP.
What you measure: Does usage repeat without heavy pushing?

Manual service wrapper

Use it when: Automation is expensive.
What you build: Service process around the promised outcome.
What you measure: Can you deliver value before productizing?

For a landing page or offer test, see how a smoke test for a startup works. For feature-intent tests, use fake-door test examples.

For B2B, the MVP may be a pilot, not a public launch. If that is your path, focus on how to get pilot customers.

Signal strength ladder

Different signals carry different weight when evaluating behavior.

• Compliment (Weak): Politeness, not demand.

• Generic waitlist signup (Weak): Useful only with context.

• Survey interest (Weak): Often detached from behavior.

• Repeated pain story (Better): Worth investigating.

• Current workaround (Better): Pain has already caused action.

• Time spent with you (Better): Some commitment exists.

• Data shared (Strong): User is exposing real workflow.

• Paid pilot (Strong): Budget and urgency are present.

• Workflow switch (Strong): Product is replacing something.

• Repeated use (Strong): Value may survive novelty.

A launch can amplify attention, but attention is not validation by itself. Product Hunt, press, and social buzz can support traction. They do not prove that a specific buyer will change behavior or pay.

For the original MVP concept, Eric Ries's early explanation of a minimum viable product is still worth reading. Y Combinator also has a practical guide on how to plan an MVP, especially if you are trying to avoid building too much too early.

Common MVP mistakes

Building the impressive thing first

Founders often build the assistant, dashboard, marketplace, automation, or platform because it feels like progress.

But the impressive thing may not be the risky thing.

If the real risk is whether a buyer will send sensitive files, do not start with admin settings. If the real risk is whether a user wants the output, do not spend weeks on backend architecture. Agree on the product logic first. Then choose the technical shape.

Building for everyone

A universal MVP usually teaches too little.

If you build for all agencies, all founders, or all ecommerce brands, you will get muddy feedback. One group wants speed. Another wants control. Another wants compliance. Another wants price. You end up averaging different problems into a product nobody loves.

Pick one segment.

Treating feature count as the main constraint

"Three features" is not a strategy.

A one-feature MVP can still be too big if it tests nothing important. A manual pilot can be enough if it tests payment, workflow, and urgency.

Scope is not about the number of features. It is about the proof needed for the next decision.

Confusing prototype with MVP

A prototype tests understanding. An MVP tests behavior.

If users can click through a mockup and explain it back to you, that is useful. But it does not prove they will use it in a real workflow, share data, invite a team member, or pay.

Calling low quality "minimum"

Minimum does not mean sloppy.

If your buyer needs accuracy, trust, speed, privacy, or a professional handoff, those may be part of the minimum. You can skip polish that does not affect the test. You cannot skip the thing that makes the test credible.

Ignoring substitutes

Your competitor is not always another startup.

It might be a spreadsheet, intern, agency, calendar reminder, Slack thread, Notion page, habit, or doing nothing. Sometimes the substitute is not even in your category. The MVP has to beat the current behavior, not just look better than direct competitors.

Treating early channel failure as product failure

If one ad campaign, launch, or outbound sequence fails, you may have a demand problem. You may also have a channel, message, audience, or timing problem.

Do not use one weak channel test as proof that the product is invalid. Separate acquisition learning from product learning.

A practical way to choose your MVP

Write this sentence:

We believe [specific buyer] will [specific behavior] because [specific pain or current workaround], and we will test it by [smallest credible MVP].

Examples:

• We believe Shopify operators will send weekly CSV exports because inventory mistakes cost them time, and we will test it by manually producing reorder alerts for five stores.

• We believe seed-stage founders will pay for investor-update metric cleanup because they already spend hours preparing updates, and we will test it with a paid pilot before building a dashboard.

• We believe sales managers will use call-analysis summaries because they already review calls manually, and we will test one meeting type with manually cleaned summaries before building CRM sync.

• We believe users want the astrology output, not the date-of-birth input, and we will test a shareable reading artifact before building a full app.

If you cannot fill in the buyer, behavior, pain, and test, you are probably not ready to build the MVP yet.

FAQ

• What is an MVP in simple terms?

  An MVP is the smallest credible product or test that helps you learn whether an important assumption is true. It should force real behavior, not just opinions.

• How small should an MVP be?

  Small enough to build quickly, but real enough to test the behavior you care about. If you remove the part that makes the buyer act, the MVP is too small.

• When should you build an MVP?

  Build an MVP after you have evidence that a real buyer has the pain, but before you commit to a full product. If you still do not know who the buyer is, do discovery first.

• Is a landing page an MVP?

  Sometimes. A landing page can be an MVP if the risk is demand and the page asks for a meaningful action, such as a demo request, pilot conversation, qualified signup, or payment intent.

• What is the difference between an MVP and a prototype?

  A prototype tests whether people understand the concept or flow. An MVP tests whether people behave differently when the offer or product is real enough to act on.

• Can an MVP be a paid pilot?

  Yes. For B2B startups, a paid pilot is often stronger than a public launch because it tests value, urgency, internal workflow, and willingness to pay.