From raw idea to your first real users — without building the wrong thing.
The Minimum Viable Product process addresses this challenge directly. It is not a shortcut or a compromise; rather, it is a rational approach to building new products in uncertain environments. The MVP framework prioritizes testing your riskiest assumptions early, before you exhaust your resources, your team’s energy, or your users’ goodwill.
This guide leads founders, product managers, and builders through each stage of MVP development, from validating the problem to determining when to stop iterating and begin scaling.
"Most startups don't fail because the product was built badly — they fail because the wrong product was built entirely."
90%
42%
3–6 mo
$0
What is an MVP? and what it's not
The three myths you need to kill right now
Myth 1: An MVP is a poor-quality version of your product. This is incorrect.
Myth 2: An MVP is the same as a beta.
Myth 3: An MVP must be software.
Dropbox — a demo video, not code. Airbnb — three airbeds in a San Francisco apartment. Zappos — a founder buying shoes from other stores and manually shipping them. All became billion-dollar companies. None built software first.
Validate the problem before touching a keyboard
The most expensive mistake in product development is building a solution before confirming the problem is real. Most founders skip this step because it feels uncomfortable. Talking to potential users seems slow, while building feels productive. This is a trap.
42%
5–25×
100
3
How to run a problem interview?
The Problem Interview Checklist
- Ask about their life, not your idea ("Walk me through how you handle X today")
- Ask about specifics in the past, not hypotheticals in the future
- Look for workarounds — if they've built a spreadsheet hack, the pain is real
- Find out who else is affected and who else they've talked to about this
- Ask what they've already tried to solve it — and why it didn't work
- Never ask "would you use this?" — ask "would you pay for this, and how much?"
Red flag vs green flag
Red flag: "Yeah, that would be nice to have." Green flag: "Oh my god, we've been trying to solve this for months. Where do I sign up?" The energy matters as much as the words.
Define your target user with ruthless precision
“Anyone who has this problem” is not a user segment. It’s a way of avoiding the hard work of defining who you’re really building for. The narrower your early target, the faster you’ll learn, and the more likely your product will be exactly right for someone instead of vaguely okay for everyone.
Jobs-to-be-Done Framework
The three layers of narrowing
Begin with a broad segment and refine it through three levels of specificity. For example: Small business owners, then solo service business owners who invoice clients, and finally freelance designers who invoice more than ten clients per month and currently use spreadsheets.
This third-level persona has specific needs, context, and behaviors. You can identify, engage, and develop solutions tailored to them. Products that address these needs effectively often become category leaders, as these users become strong advocates.
Scope your MVP: what to build and what to ruthlessly cut
This is where most MVPs go wrong. Not in the building — in the scoping. Feature lists grow because saying no is hard, because stakeholders have opinions, because you’re excited. The antidote is a simple filter: does this feature directly serve the one hypothesis you’re testing? If not, it’s a future version’s problem.
"If you're not embarrassed by the first version of your product, you've launched too late."
Three prioritization frameworks — pick one
MoSCoW Method
RICE Scoring
Impact vs. Effort Matrix
The One Sentence Test
Before building anything, simulate your product manually. Charge real money. Deliver the outcome by hand. If customers pay and come back, then you build software to automate it. This approach eliminates the biggest risk in one step.
Choose your MVP type and build strategy
Not all MVPs are apps. The right MVP type depends entirely on what question you’re trying to answer. Matching the format to the hypothesis is one of the highest-leverage decisions you’ll make.
Build vs. no-code vs. low-code
Unless your product’s core value proposition is a technical innovation that can only be demonstrated with custom code, resist the urge to engineer from scratch. Tools like Bubble, Webflow, Glide, and Airtable can produce functional MVPs in days, not months. Save engineering velocity for after you have signal.
Taking shortcuts is acceptable — even advisable — at the MVP stage. What matters is knowing which shortcuts you’re taking. Acceptable: manual processes, hardcoded values, no caching, limited error handling. Unacceptable: insecure data handling, architectural decisions that will require a full rewrite at 10× scale.
Get your first users — without a marketing budget
Paul Graham’s directive — “do things that don’t scale” — is the most important piece of early-stage distribution advice ever written. Your first 100 users should not come from ads, SEO, or a viral loop. They should come from you, personally, reaching out to people who have the problem you’re solving.
1. Start with your warm network
Who do you personally know who has this problem? Message them directly. Not a mass email — a personal message that shows you’ve thought about their specific situation.
2. Find communities where your user lives
3. Cold outreach with radical personalization
4. Launch on Product Hunt and Hacker News
5. Charge from day one
Free users will tell you what they want to be true. Paying users will tell you what’s actually true. Even $10/month filters out tire-kickers and produces dramatically better signal.
Measure, learn, and decide: the build-measure-learn loop
The metrics that actually matter at the MVP stage
The pivot vs. persevere decision
Signals to persevere
- Users are coming back even when the product is rough
- Some users describe it as “irreplaceable”
- Activation is improving week-over-week
- Word-of-mouth is bringing in users you didn’t reach out to
- Users are angry when the product breaks — not indifferent
Signals to pivot
- Users sign up, try it once, and disappear
- NPS is below 20 and not improving
- You have to convince every single user it’s worth using
- User interviews reveal a different problem they care more about
- No one is willing to pay, even at a very low price
From MVP to v1: when and how to scale
There isn’t one clear metric that shows your MVP is finished and version one is ready. Instead, you’ll notice a mix of signals, and it takes real honesty to see what’s actually happening instead of just what you hope to see.
Signs your MVP has proven its thesis
- You have users who return week after week without being prompted
- At least some users are paying — and haven't asked for a refund
- Users are referring other users organically (k-factor > 0.3)
- You can articulate exactly who your user is and why they love it
- You know which features to build next because users are asking for the same things
What changes between MVP and v1
The MVP proved the hypothesis. V1 is about making the product reliable, onboardable, and polished enough to grow. The order of operations matters enormously:
1. Stability first
2. Onboarding second
3. Polish third
4. New features last
The MVP mindset never fully ends
The best product teams at companies like Stripe, Notion, and Linear never fully abandon MVP thinking. They continue shipping small, learning fast, and killing features that don’t pull their weight. The MVP is not a phase — it’s a culture.
