An MVP is not a smaller version of your product. It is an experiment with a user interface attached — and the only question that decides its scope is which assumption would kill the business if it turned out to be wrong.
Your MVP should contain exactly one complete user journey that tests your riskiest assumption, instrumented well enough to tell you whether people actually do the thing. Everything else — accounts, admin panels, billing, a second platform, scalable architecture, polish — is deferred, however reasonable each one sounds in isolation.
That definition is unpopular because it produces something that feels embarrassing to show. Which is roughly the point: if the first version does not make you slightly uncomfortable, it was built too late.
What an MVP is for
The term comes from Frank Robinson in 2001 and was popularised by Eric Ries in The Lean Startup, where the MVP is defined by what it teaches rather than by what it contains: the version of a product that allows a team to collect the maximum amount of validated learning about customers with the least effort.
Note what that definition does not say. It does not say “the smallest set of features people would pay for.” It does not say “version one.” It says learning — which means an MVP has a question attached to it, and a build with no question attached is not an MVP, it is just an early product.
This distinction has practical consequences. If you cannot state, in one sentence, what you will know at the end of the build that you do not know now, the scope has no natural boundary — and scope without a boundary expands until the money runs out.
Every feature argument is really a disagreement about what you are trying to find out.
Start with the assumption, not the feature list
The useful exercise takes about ninety minutes. Write down every assumption the business rests on — that this group has the problem, that they will change their workflow, that they have budget, that you can reach them affordably, that the technology works at acceptable cost. Then place each one.
Most teams find that their genuinely fatal, genuinely uncertain assumption is behavioural rather than technical. “Can we build it?” is rarely the real risk. “Will anyone change what they currently do?” almost always is — and it is the one that feature lists are worst at testing.
Once you have identified the quadrant-one assumption, the scope question becomes tractable. For each proposed feature, ask: does this change what we learn about that assumption? If not, it goes on the v2 list. Not deleted — listed, dated, and out.
The six things founders insist on
These come up in nearly every scoping conversation. Each one is defensible; none of them tests anything.
The pattern connecting all six is that they are the parts that make software feel like a real company. Accounts, billing and an admin panel are what a proper product has. They are also the parts that generate no information about whether anyone wants the thing.
The manual alternatives are not shortcuts, they are better instruments. Sending invoices yourself forces a conversation with a buyer about money. Creating accounts by hand tells you exactly who signed up and why. Doing things manually is how you find out what should eventually be automated — and, frequently, what should not be built at all.
The one exception worth arguing about
If your quadrant-one assumption is specifically about scale, cost per transaction, or regulatory compliance, then the corresponding “cut” above is exactly what you must build. An AI product whose fatal risk is inference cost has to test inference cost. The rule is not “never build infrastructure” — it is “only build what tests the thing that could kill you.”
The statistic everyone cites — and why to be careful with it
You will have seen the claim that 64% of software features are rarely or never used, often split as 45% never and 19% rarely. It is worth knowing where it comes from before you put it in a deck.
The figure was presented by Jim Johnson, chairman of the Standish Group, at the XP 2002 conference in Sardinia. As Mike Cohn has documented, the underlying research covered four internal applications at four companies — all internal-use enterprise software, no commercial products.[1] The number has since been repeated so widely that most people citing it have never seen the source.
The directional point — that a lot of built software goes unused — matches what most engineering teams observe. The precise figure does not generalise from four internal applications to every product. Use the argument; drop the number.
Write the scope down before you write any code
The single most effective intervention we make on MVP builds is not technical. It is a one-page document agreed before the first ticket is written.
The freeze date and the named owner matter more than founders expect. Without a date, “while we’re in there” additions accumulate invisibly. Without a single named person who can approve a scope change, every stakeholder becomes a scope-changer and nobody notices until the build is six weeks long.
The exclusion list does most of the work. Writing “no accounts, no billing, no mobile app” converts an unspoken assumption into a decision someone has to actively overturn — which they rarely do, because now it is visible.
How long should an MVP take?
Eight to eighteen weeks for most software ventures, with the wide range driven almost entirely by two factors: whether the product touches regulation, and whether integrations with existing systems are required.
| Product type | Typical MVP | What stretches it |
|---|---|---|
| Marketplace | 10–16 weeks | Two-sided liquidity; payments and trust mechanisms |
| B2B SaaS tool | 8–14 weeks | SSO, security review, integration with the system of record |
| AI product | 8–16 weeks | Evaluation sets, cost per inference, acceptable failure modes |
| Consumer mobile | 10–16 weeks | App store review; onboarding matters far more than in B2B |
| Regulated (health, finance) | 16–30 weeks | Compliance requirements that cannot be deferred to v2 |
Ranges are First500days planning estimates from our own build engagements, not published research.
If your MVP is going to take more than about four months, the scope is almost certainly testing more than one assumption. Split it. Two sequential four-week builds that each answer a question beat one sixteen-week build that answers none until the end.
What to measure
An MVP without instrumentation is an opinion generator. Decide the measurements before launch, because deciding afterwards means measuring whatever happens to be convenient.
- Activation: what fraction of people who start the one journey actually complete it? Below about 40% and the problem is usually the journey, not the demand.
- Repeat use: does the same person come back and do the core action again without being prompted? This is the single most informative number.
- The unprompted signal: anyone who uses it in a week when you did not contact them. Count these individually — at this stage the number is small enough to name each one.
- Where they stop: the step at which people abandon. Usually more informative than anything they tell you in an interview.
- What they ask for: requests repeated by three or more unrelated users. One request is a preference; three is a pattern.
Notice what is absent: signups, page views and downloads. Those measure your launch announcement, not your product.
When the MVP is done
Not when the features are finished — when the question is answered. There are three honest outcomes, and only one of them is “keep building.”
- The assumption held. People do the thing, repeatedly, unprompted. Move to phase five: launch properly, and start on the second-riskiest assumption.
- The assumption failed, and you know why. This is a successful MVP. It cost you three months instead of two years, and the reason it failed usually points at the next thing to test.
- Nothing conclusive happened. Usually an instrumentation problem or too few users, not a product problem. Fix the measurement and run it again — do not add features to a build you cannot yet read.
