MVPs Are Misunderstood: What to Build First (And What to Skip)

The term “MVP” (Minimum Viable Product) has been so abused that it’s almost meaningless. Founders use it to justify building half-baked products. Investors use it to pressure teams to ship faster. Everyone has a different definition of what “minimum” and “viable” actually mean.

The result? Products that are so minimal they’re not viable. Or products that are perfectly viable but took 18 months to build and aren’t actually minimum. Or worst of all, products that answer the wrong questions entirely because founders didn’t understand what an MVP is supposed to prove.

An MVP isn’t a crappy version of your vision. It’s not the cheapest thing you can build. And it’s definitely not an excuse to ship broken software.

An MVP is an experiment designed to test your riskiest assumptions with the least amount of effort. What you build depends entirely on what assumptions you need to validate.

Here’s what MVPs actually are, what to build first based on your specific risks, and what to skip until you’ve validated the fundamentals.

What an MVP Actually Is (And Isn’t)

An MVP is:

• The smallest thing you can build to test a specific hypothesis
• A learning tool, not a product
• Focused on one or two critical assumptions
• Meant to fail fast if your assumptions are wrong
• Different for every business based on what’s uncertain

An MVP is not:

• A bad version of your product
• The cheapest thing you can ship
• Feature-complete but buggy
• An excuse for poor quality
• The same for every company

The point of an MVP: Learn whether your core assumptions are correct before investing heavily in building. If you’re wrong about the problem, the solution, or the market, you want to know at $10K invested, not $500K.

The Three Types of Risk (And Which MVP to Build)

Every startup has three types of risk. Your MVP should target whichever is highest.

1. Market Risk: Is there actually a problem worth solving?

What you’re testing: Do people actually have this problem? Is it painful enough that they’ll pay to solve it?

MVP approaches:

The landing page test:

• Create a compelling landing page describing the solution
• Drive traffic (ads, organic, outreach)
• Measure signups, wait-list conversions, or pre-orders
• Cost: $500-$2,000, Time: 1-2 weeks

Use when: You’re not sure if the problem exists or if people care enough to pay.

Example: Dropbox famously tested demand with just a demo video before building the product. 75,000 wait-list signups validated market demand.

The concierge MVP:

• Manually deliver the service you plan to automate
• Charge real money
• Learn exactly what customers need
• Cost: Your time, Time: 2-4 weeks to first customer

Use when: You understand the problem but don’t know if people will pay or what the actual workflow should be.

Example: Food on the Table (meal planning app) started with founder Erin Glaser personally meeting with customers weekly to plan their meals before building any software.

The problem interview:

• Talk to 20-50 potential customers about their problems
• Don’t pitch your solution—just learn about their pain
• Quantify how much the problem costs them
• Cost: Your time, Time: 2-3 weeks

Use when: You’re in a market you don’t know well and need to validate that the problem is real.

2. Product Risk: Can you actually build a solution that works?

What you’re testing: Can you create something that solves the problem? Will the solution actually work?

MVP approaches:

The Wizard of Oz MVP:

• Frontend appears automated but humans do the work behind the scenes
• Users get real value but you’re manually delivering it
• Learn if the solution actually solves the problem before building automation
• Cost: $2,000-$10,000, Time: 4-8 weeks

Use when: You know there’s demand but don’t know if your solution approach will work.

Example: Zapier started with founders manually connecting apps behind the scenes while users thought it was automated.

The feature-stub MVP:

• Build only the core workflow that demonstrates value
• Fake or skip everything else
• Focus on proving the solution works, not on polish
• Cost: $5,000-$30,000, Time: 6-12 weeks

Use when: The core functionality is complex and you need to prove it’s possible before building peripheral features.

The prototype:

• Working model that demonstrates feasibility but isn’t production-ready
• Could be hardware prototype, technical proof-of-concept, or clickable mockup
• Validates that the technology can work
• Cost: $10,000-$100,000+, Time: 3-6 months

Use when: You’re building something technically difficult and need to prove it’s possible (hardware, deep tech, complex algorithms).

3. Traction Risk: Can you actually get customers?

What you’re testing: Can you find customers? Can you acquire them at reasonable cost? Will they actually use it?

MVP approaches:

The single-channel test:

• Pick one customer acquisition channel
• Build the minimal product needed for that channel
• Measure conversion, CAC, and retention
• Cost: Varies, Time: 4-8 weeks

Use when: You have a working product but don’t know how to get customers.

Example: Focus on one channel (SEO, cold outreach, paid ads, partnerships) and measure if you can acquire customers profitably before diversifying.

The pilot program:

• Offer free or discounted pilot to 5-10 customers
• Deliver high-touch service
• Learn usage patterns and outcomes
• Cost: Your time, Time: 8-12 weeks

Use when: You need to prove customers will adopt and get value before scaling.

What to Build First: The Decision Tree

Use this decision tree to figure out what type of MVP you need:

Step 1: Do you know that people have this problem and will pay to solve it?

• No → Build a market-risk MVP (landing page, problem interviews, concierge)
• Yes → Go to Step 2

Step 2: Do you know you can build a solution that works?

• No → Build a product-risk MVP (Wizard of Oz, feature stub, prototype)
• Yes → Go to Step 3

Step 3: Do you know you can acquire customers and they’ll use it?

• No → Build a traction-risk MVP (single-channel test, pilot program)
• Yes → You’re ready to build a real product and scale

Most founders skip straight to building a full product (Step 3) without validating Steps 1 or 2. Then they launch and discover nobody wants it or it doesn’t work as intended.

What to Include in Your MVP

Once you know which type of MVP to build, what should it include?

Always include:

1. The core value proposition. The one thing that makes customers say “I need this.”
2. The minimum workflow. The essential path from problem to solution.
3. A way to collect feedback. How will you learn if this works?
4. A way to capture demand. Email, payment, commitment—something that proves interest.

Usually include:

• Basic authentication if needed
• Core functionality that delivers the promised outcome
• Enough polish that you’re not embarrassed to show it
• Payment/pricing if you’re testing willingness to pay

Skip for now:

• Edge cases and rare scenarios
• Advanced features that aren’t core to value
• Integrations with every possible platform
• Perfect mobile responsiveness (if desktop works)
• Scalability beyond 100 users
• Anything customers don’t see or interact with

The Quality Question: How Good Should an MVP Be?

This is where founders get confused. “Minimum” doesn’t mean “broken.”

Your MVP should be:

• Good enough to test your hypothesis. If quality is part of what you’re testing (luxury product, professional tool), it needs to be high quality
• Good enough that users can accomplish the core task. Bugs in edge cases are fine. Bugs in the main workflow are not
• Good enough that you’re not embarrassed. If you wouldn’t show it to potential customers, it’s too rough

Your MVP should not be:

• Feature-complete. It’s missing most features and that’s intentional
• Perfectly polished. Minor UI issues, occasional bugs, limited scenarios—all acceptable
• Scalable to millions of users. Optimized for 10-100 users learning, not 10,000 users

The test: Would you pay for this yourself in its current state to solve the problem it addresses? If yes, it’s viable. If no, it’s just minimum.

Common MVP Mistakes

Mistake 1: Building for too long before testing. Spending 6-12 months building before getting any customer feedback. You’re accumulating risk, not reducing it.

Fix: Set a hard deadline—4-8 weeks max—and ship whatever you have. Perfect is the enemy of learning.

Mistake 2: Including too many features. “We need login, and profiles, and social sharing, and notifications, and…”

Fix: If you can test your hypothesis without it, cut it. Ruthlessly prioritize the one workflow that proves value.

Mistake 3: Making it too cheap/ugly to be credible. An MVP for enterprise software that looks like a high school project won’t get taken seriously.

Fix: Match quality to your target customer’s expectations. B2B enterprise? Polish matters. Consumer utility? Speed matters more.

Mistake 4: Testing too many assumptions at once. Building a full product that tests market, product, and traction simultaneously.

Fix: One MVP per major assumption. Test market, then product, then traction.

Mistake 5: Not defining success criteria. You build an MVP but don’t know what would constitute validation.

Fix: Before building, write down: “This MVP succeeds if [specific metric/outcome happens].”

What Success Looks Like

Your MVP succeeded if you learned something that changes your next decision.

Good outcomes:

• ✓ Validated: People have the problem and will pay → Build the product
• ✓ Invalidated: Nobody cares about this problem → Pivot or quit
• ✓ Partially validated: Different customer segment cares → Adjust target market
• ✓ Solution doesn’t work as planned → Try different approach

Bad outcomes:

• ✗ Built an MVP but got no feedback or data
• ✗ Spent so much time/money that you’re committed regardless of results
• ✗ Tested the wrong assumption (e.g., tested product when market was the real risk)

The Build-Measure-Learn Loop

An MVP is not one-and-done. It’s the first iteration in a learning loop:

1. Build: Create the smallest thing to test your assumption
2. Measure: Collect data—signups, usage, feedback, payments
3. Learn: Analyze data and decide what it means
4. Decide: Pivot, persevere, or iterate
5. Repeat: Build the next experiment based on learnings

Most successful products went through 3-5 major MVP iterations before finding product-market fit.

Real MVP Examples

Airbnb:

• MVP: Founders rented out air mattresses in their apartment and created a simple website
• Tested: Will people pay to stay in strangers’ homes?
• Result: Validated demand, iterated from there

Stripe:

• MVP: Demo video and early access to devs
• Tested: Will developers use an API for payments?
• Result: Wait-list validated demand before building full product

Groupon:

• MVP: WordPress blog posting one deal per day, manual fulfillment
• Tested: Will people buy daily deals?
• Result: Validated, scaled from there

Amazon:

• MVP: Online bookstore with inventory bought from distributors
• Tested: Will people buy books online?
• Result: Validated, expanded categories over time

Notice: None of these were feature-complete. All tested one core assumption. All succeeded by learning, not by building everything.

What to Build After Your MVP

Once your MVP validates your assumptions, you have choices:

If validated strongly:

• Build toward a real product
• Add features based on customer feedback
• Scale customer acquisition
• Optimize for retention and growth

If partially validated:

• Adjust based on learnings
• Build another MVP testing the next assumption
• Pivot to the segment/solution that worked

If invalidated:

• Decide whether to pivot or quit
• If pivoting, test the new direction with a new MVP
• If quitting, you saved yourself years and hundreds of thousands of dollars

The Bottom Line

An MVP isn’t about building fast and cheap. It’s about learning fast and smart.

Build the smallest thing that tests your riskiest assumption. If it’s market risk, you don’t need to build anything—landing pages and interviews work. If it’s product risk, build only the core functionality. If it’s traction risk, focus on one channel.

Skip everything that doesn’t help you learn. Polish, edge cases, scalability, features—none of that matters until you’ve validated the fundamentals.

The best MVPs feel incomplete because they are. They’re experiments, not products. Build them fast, test them hard, and learn what you need to know before investing in building the real thing.

Your MVP’s job isn’t to delight customers—it’s to keep you from spending years building something nobody wants.