How Do I Create a Minimum Viable Product (MVP)?

The concept of an MVP sounds simple: build the minimum version of your product to test if customers want it. In practice, founders struggle with what "minimum" means.

Some build too much, spending months on features that don't matter. Others build too little, shipping something that doesn't adequately test their hypothesis. The goal is finding the sweet spot: small enough to build quickly, complete enough to generate useful learning.

Here's how to think about MVPs and build one that actually helps you find product-market fit.

Understanding the purpose helps you scope correctly. An MVP isn't a crappy product. It's a learning tool.

The primary purpose: Test your riskiest assumptions with the least investment of time and money. Find out if your core hypothesis is true before building the full vision.

What you're testing:

• Do people have the problem you think they have?
• Will they use/pay for a solution?
• Is your approach to solving it correct?
• Can you reach these customers?

What you're not doing:

• Building your full vision
• Impressing everyone with polish
• Competing with established products on features
• Creating a scalable, production-ready system

The learning loop: Build (something small) → Measure (how customers respond) → Learn (whether to proceed, pivot, or stop)

The mistake: Treating MVP as "version 1" instead of "smallest possible test." Your full product might have 50 features. Your MVP might have 1 or 2.

The hardest part is deciding what goes in and what stays out. Use these filters.

Start with the core problem: What is the one essential problem you solve? Everything else is secondary. Your MVP should address this core problem only.

Identify your riskiest assumption: Every startup is built on assumptions. Which assumption, if wrong, kills your business? That's what your MVP should test.

Define the minimum loop: What's the smallest experience that demonstrates value? For a marketplace: one seller and one buyer completing a transaction. For a SaaS: one user accomplishing one task.

Strip features ruthlessly: "Nice to have" doesn't make the cut. "Users might want" doesn't make it. Only "essential to test our hypothesis" stays.

Set a time limit: A good MVP should be buildable in 2-6 weeks. If your scope takes 3 months, it's too big. Cut more.

The one-feature test: Can you describe your MVP with one feature? "It lets you [one thing]." If you need "and" or a list, you've probably scoped too big.

Example: Hypothesis: Busy professionals will pay for healthy meal delivery. MVP: Manually curate and deliver meals to 10 customers. Test demand before building a platform.

MVPs don't have to be software. Several approaches test hypotheses without full product development.

Landing page MVP: A page describing your product with a signup form. Tests: Will people express interest? Variant: collect pre-orders to test willingness to pay.

Wizard of Oz MVP: Appears automated but is manually operated behind the scenes. Zappos started by photographing shoes and buying from stores when orders came in. Tests: Will people use the experience?

Concierge MVP: Deliver the service manually to a few customers. Understand the experience deeply before automating. Tests: Is the value proposition correct?

Video MVP: Dropbox famously launched with just a video demonstrating the product. Tests: Does this concept excite people?

Pre-sell MVP: Sell the product before building it. Kickstarter campaigns are examples. Tests: Will people pay?

Feature-limited product: Build one feature extremely well. Add nothing else. Tests: Is this core feature valuable?

Choosing your approach:

• Landing page: Testing interest and positioning
• Wizard of Oz: Testing user experience
• Concierge: Testing the full value proposition with real service
• Video: Testing concept appeal
• Pre-sell: Testing willingness to pay
• Feature-limited: Testing core functionality

Speed matters. The faster you learn, the better. Here's how to move quickly.

Choose the right tools:

No-code/low-code: Bubble, Webflow, Glide, Airtable. Build functional products without writing code. Good for: Testing concepts, non-technical founders.

Simple code: If you can code, use the fastest stack you know. Don't learn a new framework for an MVP. Speed beats optimization.

Third-party services: Stripe for payments, Auth0 for authentication, Twilio for messaging. Don't build what you can buy.

Hack it together: Zapier connections, spreadsheets as backends, manual processes disguised as automation. It doesn't need to be pretty.

Cut scope, not quality: What you build should work well. Just build less of it. A polished single feature beats a buggy multi-feature mess.

Don't worry about scale: Your MVP doesn't need to handle 1 million users. Build for 10 users. Scale problems are good problems to have later.

Set a deadline: Give yourself 2-4 weeks. Whatever isn't done by then isn't in the MVP. Deadlines force prioritization.

Building is only half the work. Learning from real usage completes the loop.

Define success metrics upfront: What would tell you the hypothesis is true? What would tell you it's false? Decide before launching, not after.

Get it to real users: Friends and family feedback is biased. Find actual potential customers. Even 10-20 is enough for early learning.

Observe behavior, not just feedback: What people do matters more than what they say. Track actual usage, not just survey responses.

Ask the right questions:

• What problem were you trying to solve when you used this?
• What was confusing or frustrating?
• Would you pay for this? How much?
• Would you recommend this? To whom?

Iterate quickly: An MVP isn't one-and-done. It's the first of many small experiments. Learn, adjust, test again.

Know when to stop: If several iterations show no interest, the hypothesis may be wrong. Don't keep iterating on something nobody wants.

The honest evaluation: Did you learn something useful? If the MVP taught you that your approach is wrong, that's success. It saved you from building the wrong thing.

How do I know if my MVP is too simple?

If users can't understand the value proposition or can't complete the core task, it's too simple. The minimum viable product must be viable.

What if people copy my idea after seeing the MVP?

This rarely happens, and if it does, execution still matters most. Speed of learning beats secrecy.

Should my MVP be free?

Depends on what you're testing. If the question is "will people use this," free is fine. If it's "will people pay for this," charge something.

How many users do I need to test an MVP?

10-20 active users generating feedback is enough for early learning. Statistical significance isn't the goal. Learning is.

What if users want features I excluded?

Good sign. Write down the requests. But don't add them yet. The MVP teaches you what's essential, which may differ from what users initially request.

When do I stop iterating on the MVP and build the real product?

When you've validated the core hypothesis and understand what customers actually want. The MVP evolves into the product through iteration.