Why this matters
The MVP feature list is where startups quietly lose six months. Every "just one more feature" delays the only thing that produces learning: real users using a real product. A disciplined list gets you to market while your motivation and your runway are both still intact.
What "done" looks like
- A written list split into: core (launch blockers), later (post-launch), and never (explicitly rejected)
- The core list delivers the ONE outcome your persona is hiring the product for
- Every core feature has a one-line justification tied to the validated problem
- The team agrees nothing enters "core" without removing something else
How to do it
- Write the user's job story first: "When [trigger], I want to [action], so I can [outcome]." The MVP is the shortest path through that sentence.
- Brainstorm freely, then cut brutally. List everything, then ask of each item: does launch fail without this?
- Cap the core list. As a rough starting point, an MVP core often fits in 3 to 7 features, depending on product complexity.
- Define each feature's minimum shape. "Login" can be email-magic-link only; "reports" can be one fixed report.
- Timebox the build. As a rough starting point, if the core list cannot ship in 4 to 8 weeks, it may not be minimum yet, depending on product complexity.
Common mistakes
- Building for edge cases before a single main-case user exists
- Copying a mature competitor's feature set as your baseline
- Treating "later" as a promise instead of a parking lot
Real-world examples
- Dropbox, rather than finish the hard engineering first, Drew Houston made a short demo video of how file sync would work (a limited, Windows-only beta existed, but the product was far from done). When the video reached Digg in 2008 it grew the beta waiting list from around 5,000 to 75,000 people almost overnight, demonstrating strong early interest before the full product was built.
- Zappos, founder Nick Swinmurn tested whether people would buy shoes online by photographing pairs at local stores and buying them at retail to fulfill each order by hand. No inventory, no warehouse, just the one feature that mattered: can we sell a shoe online?
- The through-line is that the strongest MVP feature lists are brutally short: one core job done well, and everything else waits until a real user proves it's needed. It pays to write that list against a clear target user persona and pressure-test demand with a smoke-test landing page first.
From a founder's point of view
The hardest part of an MVP feature list is deleting things, not adding them. Every feature you cut is one less thing to build, test, and support before you learn whether anyone actually wants the core idea, and that learning is the only thing the first version owes you. Founders who ship one feature that solves one real problem tend to beat the ones still polishing five features nobody asked for.
Rule of thumb
If removing a feature would not lose you the first ten users, it does not belong in the MVP.
