The most expensive way to find out nobody wants your product is to build the whole thing first. The MVP approach—building a Minimum Viable Product—lets you test your core assumptions with the smallest possible investment before committing to full development.
But "minimum" is often misunderstood. An MVP isn't a broken or unusable product. It's the smallest thing that delivers enough value to test whether your idea works. Getting this balance right is the challenge.
What an MVP Actually Is
An MVP is a product with just enough features to attract early-adopter customers and validate a product hypothesis. It's a learning tool—designed to answer questions, not to be a finished product.
The key question an MVP answers: "Will people actually use this to solve their problem?" Not "Is the product finished?" or "Does it have all the features we imagined?"
What MVP Is Not
- Not a prototype: Prototypes demonstrate concepts. MVPs deliver value to real users.
- Not a broken product: It must work well enough that users can actually achieve their goal.
- Not version 1.0: Your first public release will typically have more features than a true MVP.
- Not feature-complete: Missing features are intentional, not oversights.
Identifying Your Core Value
The hardest part of MVP development is deciding what to include. Start by identifying the one thing your product must do well.
The Core Value Exercise
- List all features you've imagined. Get everything out of your head.
- For each feature, ask: "If this is missing, would users still try the product?" Be honest.
- Identify the single core capability. What's the one thing that delivers value?
- Add only what's essential to support that core. Login might be essential; social sharing probably isn't.
Examples of Core Value
- Dropbox: Sync files between computers. Not sharing, not collaboration—just sync.
- Airbnb: Book someone's spare room. Not reviews, not instant booking—just connect guest and host.
- Uber: Get a ride from your phone. Not ratings, not fare estimates—just the core transaction.
Types of MVPs
Not every MVP requires code. Different validation needs call for different approaches.
Landing Page MVP
A single page describing your product with a signup form. Measures interest before building anything. If nobody signs up, reconsider the idea.
Concierge MVP
Deliver the service manually before automating. A cleaning service might manually match clients with cleaners via spreadsheet before building an app. Validates demand and helps you understand the process.
Wizard of Oz MVP
Users think they're using automated software, but humans are doing the work behind the scenes. Tests whether users want the output without investing in automation.
Single-Feature MVP
A fully functional product that does one thing well. No bells and whistles, but that one thing works reliably. This is the classic software MVP.
Piecemeal MVP
Combine existing tools to deliver your service. Use Typeform for intake, Zapier for automation, Google Sheets for data—test the concept before building custom software.
Building Your MVP
Set a Time Box
Decide upfront how long MVP development will take. 4-8 weeks is typical for a software MVP. The deadline forces difficult prioritisation decisions that make your product more focused.
Choose Boring Technology
Your MVP is not the place to experiment with new frameworks or architectures. Use technologies your team knows well. Speed and reliability matter more than using the latest tools.
Skip the Polish
Invest in functionality, not visual polish. A basic-looking product that works is more useful for validation than a beautiful product that crashes. You can add polish later if the concept proves valuable.
Build for Learning
Include analytics from day one. You need to understand how users actually behave, not just that they signed up. Track key actions that indicate whether users are getting value.
Essential MVP Components
- Core functionality that delivers your value proposition
- Basic user authentication (if required)
- Analytics to track user behaviour
- Feedback mechanism (even just an email address)
- Error tracking to catch and fix issues quickly
Common MVP Mistakes
Avoid These Traps
- Feature creep: "Just one more feature" delays launch and dilutes focus.
- Wrong audience: Testing with friends and family instead of real target users.
- Ignoring feedback: Building what you want instead of what users say they need.
- No success metrics: Launching without defining what success looks like.
- Premature scaling: Building infrastructure for millions of users you don't have.
- Perfection paralysis: Waiting until it's "ready" instead of learning from real users.
Validating Your MVP
An MVP only succeeds if you learn from it. Define your validation criteria before launch.
Metrics That Matter
- Activation rate: Of people who sign up, how many complete the core action?
- Return usage: Do users come back after their first session?
- Willingness to pay: Will users pay, or at least take steps toward paying?
- Referrals: Do users recommend the product to others?
Qualitative Feedback
Numbers don't tell the whole story. Talk to your early users. Understand why they use the product, what's frustrating, what's missing, and whether they'd miss it if it disappeared.
After the MVP
Your MVP will reveal one of three outcomes:
- Validated: Users love it, metrics are strong. Invest in building the full product.
- Pivot needed: Users engage but not as expected. Adjust your approach based on learnings.
- Invalidated: Nobody wants this. Difficult, but better to know now than after building everything.
All three outcomes are successes—you learned something that informs your next move. The only failure is not learning.
Summary
MVP development is about learning, not launching. Build the smallest thing that tests your core hypothesis, get it in front of real users quickly, and let their behaviour guide your next steps.
Resist the temptation to add "just one more thing." The best MVPs feel almost uncomfortably minimal—but that focus is exactly what makes them effective learning tools.