The concept of a minimum viable product has been so thoroughly absorbed into startup culture that it’s lost most of its original meaning. Teams call everything an MVP – from a landing page with an email signup form to a six-month, half-million-dollar development project with 40 features. The result is that most “MVPs” either ship too little to learn anything meaningful or ship so much that they aren’t minimum at all. Scoping an MVP correctly requires discipline: start with a falsifiable hypothesis, identify the smallest product that can test it, and ruthlessly cut everything else.
Start With a Hypothesis, Not a Feature List
The single most common mistake in MVP scoping is starting with features. Someone says “we need user accounts, a dashboard, notifications, an admin panel, integrations with Slack and email, and a mobile app.” That’s not an MVP – it’s a product roadmap masquerading as a first release.
An MVP starts with a hypothesis: a specific, testable belief about the market. Good hypotheses follow a structure: “We believe that [target customer] has [this problem] and would [take this action] if we provided [this solution].” The more specific, the better.
“Small business owners will pay for software that manages their inventory” is too vague to test. “Independent coffee shop owners with 1-3 locations will switch from spreadsheet-based inventory tracking to a dedicated app if it can reduce their weekly stock-taking time from 4 hours to under 30 minutes” is testable. You know who to talk to, what to measure, and what success looks like.
Your hypothesis should have a clear falsification criterion. What result would convince you that you’re wrong? If nothing could convince you, you don’t have a hypothesis – you have a belief, and you’re building a product to confirm it. That’s an expensive way to learn nothing.
Write down three to five hypotheses ranked by risk. The riskiest assumption – the one that, if wrong, invalidates the entire business – should be what your MVP tests first. For most startups, this is demand risk (will anyone want this?) rather than feasibility risk (can we build it?). Engineers tend to focus on the latter because it’s in their comfort zone, but the graveyard of startups is full of technically impressive products that nobody needed.
The One-Feature MVP Framework
Once you have your primary hypothesis, identify the single feature that tests it. Not the three most important features. One feature.
This feels uncomfortable because a single feature doesn’t feel like a “real” product. But that discomfort is the point. An MVP is not a version 1.0 – it’s an experiment. Its job is to produce learning, not revenue.
Dropbox’s MVP was a video demonstrating the product concept. It didn’t sync a single file. But it validated the hypothesis that people wanted seamless file syncing badly enough to sign up for a waitlist. Zappos started by posting photos of shoes from local stores online. When someone ordered, the founder went to the store, bought the shoes, and mailed them. It wasn’t scalable, but it tested whether people would buy shoes online without trying them on.
For your one feature, ask: what is the smallest thing I can put in front of real users that tests my riskiest hypothesis? If you’re testing whether coffee shop owners will use inventory management software, you don’t need multi-location support, supplier integrations, or financial reporting. You need a way for them to count their stock faster than a spreadsheet. Maybe that’s a mobile app with a barcode scanner and a pre-loaded product list. Maybe it’s even simpler – a shared Google Sheet with some automation scripts, deployed with a one-hour training session, to test whether the workflow concept resonates before you write any custom code.
Deciding What to Build, Buy, Fake, or Skip
For every capability your MVP might include, make a deliberate build/buy/fake/skip decision.
Build the one thing that represents your unique value proposition. This is the core of what you’re testing. It should be functional enough for real users to get real value from it, even if it’s rough around the edges.
Buy everything that’s commodity infrastructure. Authentication? Use Auth0 or Clerk. Payments? Stripe. Email? SendGrid. Database? A managed Postgres instance. File storage? S3. Don’t build any of these from scratch – they aren’t what you’re testing, and they’ll consume months of development time that should go toward your core hypothesis.
Fake the things that need to feel real to the user but don’t need to work automatically yet. If your product needs a “smart recommendation engine,” have a human make the recommendations manually behind the scenes for the first 50 users. If you need data from a source that’s expensive to integrate, manually import it weekly. This “Wizard of Oz” approach lets you test whether the value proposition resonates without investing in automation that might be thrown away.
Skip everything else. No admin panel – use a database GUI. No user settings page – pick sensible defaults. No onboarding flow – onboard users yourself over a video call (you’ll learn more from watching them use the product anyway). No analytics dashboard – use Mixpanel or PostHog with a manual query. No notification system – send a manual email when something important happens.
The skip list should be long. If your skip list isn’t uncomfortable, you haven’t cut enough.
See also: How to Find Product-Market Fit for Software Products
Setting Measurable Success Criteria Before You Build
Before writing the first line of code, define what success and failure look like in concrete, measurable terms. This is the part that most teams skip, and it’s why most MVPs produce opinions instead of evidence.
Pick leading indicators that you can measure within your test period. If your test runs for 6 weeks with 30 users, you can’t measure annual retention. But you can measure weekly active usage, task completion rate, time-on-task, and whether users come back without being reminded.
Set a minimum bar. “If fewer than 40 percent of users complete the core workflow in their first session, we’ll revisit our UX approach.” “If fewer than 20 percent of users return in week 2 without a prompt, we’ll question whether we’re solving a real pain point.” “If our NPS score is below 30 after the test period, we’ll pivot.”
Also define the qualitative signals you’re looking for. Are users asking for features that expand the product’s scope (a good sign – they want more of this)? Are they asking for features that change its fundamental direction (a warning sign – you might be solving the wrong problem)? Are they offering to pay before you’ve even asked (the strongest possible signal)?
Document these criteria and share them with everyone involved before the build starts. This prevents the post-hoc rationalization that kills learning: “Well, usage was low, but that’s because we didn’t have feature X” or “The numbers don’t look great, but the qualitative feedback was positive.” You committed to what success looks like before you had results, so the results mean something.
Timeboxing: The Two-Week and Six-Week Constraints
An MVP should take two to six weeks to build. If your scope requires more than six weeks of development time, you haven’t cut enough.
The two-week version is appropriate when you’re testing demand or willingness to pay before building anything substantial. A landing page that describes the product and collects email signups (or better, pre-orders). A concierge MVP where you deliver the service manually to a handful of customers. A clickable prototype built in Figma that you walk users through in a usability test.
The six-week version is appropriate when you need a functional product in users’ hands to test the core hypothesis. This timeframe forces brutal prioritization. With one or two developers, six weeks gives you roughly 400 to 500 hours of development time. That’s enough for one well-built feature with authentication, basic data persistence, and a clean (if minimal) interface.
Use the “scope hammer” throughout the build. Every time something takes longer than expected – and it will – cut scope rather than extending the timeline. The deadline is sacred because it’s tied to your learning timeline. Users are waiting. Hypotheses are aging. The market is moving. Shipping something imperfect in six weeks teaches you more than shipping something polished in six months.
Fixed scope and fixed timeline can’t coexist. Fix the timeline, flex the scope. This is the fundamental discipline of MVP development.
From MVP Results to Your Next Move
The MVP ships. Users interact with it. Data comes in. Now what?
If your success criteria are met, you’ve validated the hypothesis – not proven the business, but reduced a key risk. The next step is usually to identify the next riskiest hypothesis and design another focused experiment. Maybe demand is validated, but you need to test pricing. Maybe the workflow works for independent shops, but you need to test whether it works for small chains. Each experiment builds on the previous one, and the product grows as a byproduct of validated learning.
If your success criteria aren’t met, resist the urge to add features and try again. First, dig into the qualitative data. Did users understand the value proposition? Did they use the product as intended, or did they try to use it for something unexpected? Were there specific points in the workflow where they dropped off? The pattern of failure tells you more than the fact of failure.
Sometimes the right response to a failed MVP is a pivot: same target customer, different problem. Or same problem, different customer. Or a fundamentally different solution approach. Sometimes the right response is to kill the idea and move on. The whole point of investing two to six weeks instead of twelve months is that a failed experiment at this scale is a learning experience, not a catastrophe.
The worst response – and the most common one – is to say “the MVP was too minimal, we just need to build the full product and then people will get it.” This is the sunk cost fallacy wearing a product strategy disguise. If the core value proposition doesn’t resonate in its simplest form, adding features won’t fix that.
Scoping an MVP that produces real signal requires equal parts product thinking and engineering discipline. If you need help going from hypothesis to shipped experiment in weeks rather than months, let’s talk.