Handbook
/
Product & Engineering
How to Build an MVP That Actually Validates
Most MVPs are either too big or too small. Here's how to build the minimum viable product that actually tests your hypothesis.
The MVP concept is widely misunderstood. Founders either build too little (a landing page with no functionality) or too much (a polished product with features nobody asked for). A true MVP is the smallest thing you can build to test your core hypothesis.
What an MVP Actually Is
MVP stands for Minimum Viable Product. Each word matters:
Minimum: The smallest possible implementation. Not fewer features than ideal—the absolute minimum needed to learn.
Viable: It must actually deliver value. A landing page isn’t viable if you’re testing whether people will use a product. A broken prototype isn’t viable if users can’t accomplish the core task.
Product: Something users interact with. Not a pitch deck, not a spec, not a conversation. An actual thing people use.
The MVP isn’t a product strategy. It’s a learning strategy. The goal isn’t to build a business on the MVP—it’s to learn whether your core hypothesis is correct.
The Core Hypothesis
Before building anything, articulate what you’re testing:
“We believe [customer segment] will [desired behavior] because [reason], and we’ll know we’re right when [measurable outcome].”
Example: “We believe marketing managers will switch from spreadsheets to our tool because it saves them 5+ hours per week, and we’ll know we’re right when 30% of trial users convert to paid.”
Your MVP should test this hypothesis and nothing else. Every feature either helps test the hypothesis or should be cut.
Scope Ruthlessly
The most common MVP mistake is scope creep. Here’s how to prevent it:
The One-Feature Rule
If your product had only one feature, what would it be? Build that. Not “the three most important features.” One.
For Dropbox, it was file sync. For Uber, it was requesting a car. For Airbnb, it was listing a room. Everything else came later.
The Manual Test
Before automating anything, ask: can we do this manually?
•
Instead of building recommendation algorithms, manually recommend.
•
Instead of building payment processing, invoice manually.
•
Instead of building integrations, copy-paste data yourself.
Manual processes don’t scale, but they help you learn what to automate. Many successful companies started with founders manually doing things that later got automated.
The Time Constraint
Give yourself a hard deadline: 2-4 weeks to build and launch the MVP. Whatever you can build in that time is your scope. This forces prioritization and prevents scope creep.
If you can’t launch something in a month, you’re not building an MVP.
The “Won’t Have” List
Make a list of features you explicitly won’t build in the MVP. Write them down. When stakeholders ask for them, point to the list. This makes scope decisions explicit rather than implicit.
Types of MVPs
Different hypotheses require different MVP types:
Concierge MVP
You deliver the value manually, as a service. No technology required.
Example: Before building an AI meal planning app, you personally create meal plans for 10 users each week. You learn what they want, what questions they have, what problems arise—all before writing code.
Best for: Testing whether people want the outcome, regardless of how it’s delivered.
Wizard of Oz MVP
The product looks automated but is actually powered by humans behind the scenes.
Example: A chatbot that appears to use AI but actually has humans typing responses. Users experience the product as intended; you learn what they need.
Best for: Testing the user experience before building the technology.
Single-Feature MVP
One feature, implemented properly.
Example: A todo app that only lets you create and check off items. No projects, no tags, no collaboration. Just the core.
Best for: Testing whether the core mechanic works.
Piecemeal MVP
Combine existing tools to simulate your product.
Example: Use Typeform for intake, Zapier for automation, Airtable for storage, and email for communication. Wire them together. It’s hacky but it works.
Best for: Testing workflows before building custom software.
Landing Page MVP
A page describing your product with a signup form.
Example: Explain what the product will do, show mockups, collect emails from interested users.
Best for: Testing demand and messaging. Not sufficient for testing whether people will actually use the product.
Building the MVP
Week 1: Core Functionality
Build only what’s needed for users to experience the core value. Skip:
•
User authentication (use magic links or no auth)
•
Settings and preferences
•
Edge case handling
•
Performance optimization
•
Beautiful design (functional is enough)
Focus on the one path users will take to get value.
Week 2: Minimal Polish
Add just enough polish to not embarrass yourself:
•
Fix obvious bugs
•
Make the UI understandable
•
Write minimal onboarding
•
Set up basic analytics
You’re not trying to impress users. You’re trying to learn from them.
Week 3: Testing
Get the MVP in front of users:
•
Start with 5-10 users maximum
•
Watch them use it (screen share or in person)
•
Ask questions about their experience
•
Track behavior (signups, activation, retention)
Week 4: Iterate
Based on what you learned:
•
Fix blocking issues
•
Remove confusing elements
•
Double down on what works
•
Prepare for a broader launch
Measuring MVP Success
Your MVP succeeds if you learn something. The metrics depend on your hypothesis:
For demand validation:
•
Email signups
•
Waitlist conversions
•
Pre-orders
For usability validation:
•
Completion rate of core task
•
Time to complete core task
•
User-reported confusion points
For value validation:
•
Return usage (Day 1, Day 7, Day 30)
•
NPS or satisfaction scores
•
Willingness to pay
For growth validation:
•
Referral rate
•
Organic mentions
•
Viral coefficient
Pick 2-3 metrics that directly test your hypothesis. Ignore vanity metrics.
When to Iterate vs. Pivot
After your MVP test:
Iterate if:
•
Core hypothesis seems valid but execution needs work
•
Users are engaging with the core value
•
Feedback is about improvements, not fundamental misunderstanding
Pivot if:
•
Users aren’t engaging with core value despite clear UX
•
The problem turned out to be less painful than expected
•
You discovered the real problem is different
Abandon if:
•
Multiple iterations haven’t improved metrics
•
You’ve tested multiple pivots without success
•
The market signal is consistently negative
Common MVP Mistakes
Building too much. The MVP takes 6 months and has 20 features. That’s not an MVP.
Building too little. A landing page that tests nothing about actual product usage.
Targeting the wrong users. Testing with friends who’ll be nice instead of real potential customers.
Ignoring negative feedback. Cherry-picking positive signals while dismissing criticism.
Not measuring. Launching without defining success metrics.
Premature optimization. Scaling infrastructure before knowing if anyone wants the product.
Perfecting before launching. Polishing features instead of getting user feedback.
Key Takeaways
•
An MVP tests your core hypothesis, not builds your product
•
Scope ruthlessly: one feature, manual processes, hard deadlines
•
Choose the MVP type that matches what you need to learn
•
Build in 2-4 weeks maximum, then get it in front of users
•
Measure learning, not vanity metrics
•
Iterate if the hypothesis is valid; pivot if it’s not
AIMake has access to all of this
Our AI has access to the entire Startup Handbook. Ask it anything about building your startup.
Get started →
← Previous
Feature Flags and Progressive Rollouts
Next →
How to Run a Beta Program