Building an MVP: What to Include and What to Skip

The concept of a minimum viable product has been misunderstood since Eric Ries popularized it in The Lean Startup. Most founders interpret "minimum" as "stripped-down version of the full product" — and then spend four months building something that is neither minimum nor viable. The actual definition is more radical: an MVP is the smallest thing you can build (or fake) that lets you test your core hypothesis with real users.

Zappos did not build an e-commerce platform. Nick Swinmurn took photos of shoes at a local store, posted them online, and when someone ordered, he bought the shoes at full price and shipped them. He was testing one hypothesis: will people buy shoes without trying them on? The answer was yes. Everything else — inventory management, warehouse operations, customer service systems — came later.

That is the mindset shift most founders need to make. The MVP is not the first version of your product. It is the first version of your learning.

Why Most MVPs Fail

They Are Not Minimum Enough

The average "MVP" takes 3-6 months to build. That is not minimum — that is a full product with fewer features. A true MVP should take 2-6 weeks. If it takes longer, you have included too much.

The root cause is usually founder anxiety. You are afraid that if the product is too basic, users will reject it. But the opposite is true: if you launch a polished product and it fails, you have wasted months. If you launch a crude experiment and it fails, you have wasted weeks — and learned exactly why it failed.

They Are Not Viable Enough

"Minimum" does not mean broken. The V in MVP is just as important as the M. Your MVP must deliver real value to the user in at least one dimension. It can be ugly, limited in scope, and missing most features. But the core experience — the single thing you are testing — must work well enough that users can honestly evaluate it.

Dropbox's MVP was a three-minute video demonstrating the product concept. It was not interactive. You could not upload files. But it was viable as a test: the video clearly communicated what Dropbox would do, and the waitlist signups (75,000 overnight) proved demand. The MVP matched the hypothesis being tested.

They Test the Wrong Hypothesis

Before building anything, write down the single most important assumption your business depends on. Not "will people like this?" — that is too vague. Something specific:

• "Will freelance designers pay $29/month for a client management tool?"
• "Will parents in urban areas order weekly meal kits for kids under 5?"
• "Will mid-market sales teams switch from spreadsheets to our pipeline tool?"

Your MVP should be designed to test that specific hypothesis. Everything that does not contribute to testing it should be cut.

The MoSCoW Framework for Feature Prioritization

MoSCoW is a prioritization method that sorts features into four categories:

Must Have

Features without which the MVP has no value. These are the bare minimum for testing your core hypothesis. For a task management tool, this might be: create a task, mark a task complete, see a list of tasks. That is it — not labels, not due dates, not team sharing.

The test for "Must Have" is brutal: if you remove this feature, can you still test your hypothesis? If yes, it is not a Must Have.

Should Have

Features that are important but not essential for the initial test. These might be included if time permits, but should not delay launch. For the task management tool: due dates and reminders. Important for a full product, but not necessary to test whether people will use a simpler alternative to their current system.

Could Have

Nice-to-have features that you will build later if the MVP succeeds. These are noted and filed away. For the task management tool: labels, filters, integrations, team sharing. These features make the product better but are irrelevant until you know whether the core concept works.

Will Not Have (This Time)

Features explicitly excluded from this version. Writing these down is just as important as writing down what you will include. It prevents scope creep when a team member says "but what about..." — you can point to the list and say "we agreed: not this time."

Applying MoSCoW in Practice

Gather your full feature list (every idea, every request, every "it would be cool if..."). For each feature, ask: "Does this directly test our core hypothesis?" If yes, it is a Must Have candidate. If no, it goes into Should, Could, or Will Not.

Then apply the time constraint. You have 2-6 weeks. What can you realistically build? Strip the Must Haves to their absolute minimum implementation. A "create task" feature does not need drag-and-drop reordering — it needs a text field and a save button.

MVP Archetypes: Choose Your Format

The Concierge MVP

Deliver the product experience manually. No technology required. You are the product.

Food on the Table's founder personally created meal plans for individual customers based on their preferences and local store sales. He was testing whether people valued personalized meal planning enough to pay for it — and he could test that without writing code.

Best for: Service-based businesses, marketplaces, and any product where the value comes from a process you can manually replicate.

The Wizard of Oz MVP

The user interacts with what appears to be an automated product, but behind the scenes, humans are doing the work manually.

Zappos is the classic example — the website looked like an e-commerce store, but there was no inventory system. The founder bought shoes from retail stores and shipped them manually.

Best for: Products where the user experience matters but the back-end automation is expensive to build. Test the front-end value proposition before investing in the infrastructure.

The Landing Page MVP

A single web page that describes your product and collects signups or pre-orders. No product exists yet.

Buffer validated demand with a landing page showing pricing tiers before writing any code. When visitors clicked a plan, they saw a message explaining the product was not built yet and were asked for their email. The conversion rate from visitor to email signup validated demand.

Best for: Digital products where you need to validate demand before investing development resources. Combine with targeted ads for a faster feedback loop.

The Video MVP

A demo video that shows how the product will work.

Dropbox's explainer video generated 75,000 waitlist signups overnight — from a product that did not exist. The video was specifically targeted at a tech-savvy audience (posted on Hacker News and Digg), using insider references that made it feel authentic rather than promotional.

Best for: Products with a novel interaction model that is hard to describe in text. Video shows rather than tells, making the concept tangible without requiring a working prototype.

The Single-Feature MVP

Build one feature — the core value proposition — and launch it without anything else. No settings page, no user profiles, no integrations.

Twitter launched as a single feature: post 140-character messages. No retweets, no mentions, no direct messages, no algorithmic feed. Just post and read. That single feature was enough to test whether people wanted a public, short-form communication channel.

Best for: Software products where the core value can be delivered through a single, well-executed feature.

Timeline: From Idea to MVP in 4 Weeks

Week 1: Hypothesis and Scope

Write your core hypothesis. Define your target user. Choose your MVP archetype. Create your MoSCoW feature list. Commit to a ship date — week 4 — and do not move it.

Week 2: Build the Core

Focus exclusively on the Must Have features. Use existing tools wherever possible. Do not build a user authentication system — use Auth0 or Firebase Auth. Do not build a payment system — use Stripe Checkout. Do not design a custom UI — use a component library like Tailwind UI or Shadcn. Every hour spent on infrastructure is an hour stolen from your core value proposition.

Week 3: Test With 5 Real Users

Before your public launch, put the MVP in front of 5 real users from your target audience. Watch them use it. Do not explain anything — if they need your explanation, the product is not clear enough. Note where they get confused, what they try to do that does not work, and whether they reach the "aha moment."

Fix the critical issues. Ignore the cosmetic ones.

Week 4: Launch and Measure

Ship to your full target audience. This might be 20 people from your problem interviews, 200 people on your waitlist, or 2,000 people from a targeted ad campaign.

Measure one thing: did users exhibit the behavior that validates your hypothesis? If the hypothesis was "freelance designers will pay $29/month for client management," the success metric is paid conversions, not signups or page views.

What to Do After the MVP

If the Hypothesis Is Validated

Expand gradually. Add the Should Have features from your MoSCoW list. Start building the infrastructure you skipped. But maintain the discipline — each feature addition should be tied to a specific metric improvement. If adding due dates increases 7-day retention by 15%, it was worth building. If adding labels has no measurable impact, move on.

If the Hypothesis Is Partially Validated

Dig into the data. Which user segments showed the strongest signal? What feedback did they give? Often, partial validation means the hypothesis is directionally right but needs refinement — a different price point, a different customer segment, or a different core feature.

If the Hypothesis Is Invalidated

This is the best possible outcome (really). You have learned that your assumption was wrong in weeks rather than months. The question now is whether to pivot — change the hypothesis and test again — or move on to a different idea entirely.

The decision framework: if the problem interviews still suggest a real, painful problem, but your solution did not resonate, iterate on the solution. If the problem itself turns out to be less painful or less frequent than you assumed, the idea may not be worth pursuing.

Conclusion

An MVP is not a small product. It is a focused experiment designed to answer a specific question with minimal investment. Choose the right archetype for your hypothesis. Use MoSCoW to ruthlessly prioritize features. Build in weeks, not months. And measure the outcome that actually matters — not vanity metrics, but evidence that your core assumption about the market is correct.

The founders who ship the fastest MVPs are not the ones who cut the most corners. They are the ones who define the tightest hypotheses. When you know exactly what question you are trying to answer, the scope of what you need to build becomes obvious — and almost always smaller than you initially imagined. That is the real power of the MVP: it forces clarity at the moment when clarity matters most.