Every first release has the same argument inside it. Someone wants to ship narrow and learn. Someone else has a list of things the product obviously needs. Both are reasonable, which is why the argument rarely resolves on its merits and usually resolves on seniority.
Here is a way to settle it on something firmer.
Why scope is the lever that matters
The most durable finding in software project research is that small projects succeed at far higher rates than large ones. The Standish Group has reported this for three decades, and while its methodology has been contested in the academic literature, the direction has never seriously been in dispute.
The reason is mechanical rather than mysterious. A larger scope means more unknowns, more integration points, more people who must agree, and a longer gap between deciding something and finding out whether it was right. Each of those compounds.
Alongside it sits the McKinsey and Oxford finding across more than 5,400 IT projects: the average value shortfall of 56% exceeded the average cost overrun of 45%. Projects more often fail to be worth it than fail to be finished. Scope is where that is decided, and it is decided before anyone writes code.
What an MVP is actually for
The phrase has drifted to mean “version one, but cheaper”. That framing produces a worse product for the same money.
The useful definition is narrower: the smallest thing you can build that settles the assumption you are least sure about. Which assumption that is differs by project, and naming it is most of the work.
If you are unsure anyone wants this, the risky assumption is demand, and the MVP needs real users and can have an unglamorous interior. If you are confident in demand but unsure the thing is technically feasible at your data volumes, the MVP is a technical proof and barely needs an interface. If both are known and the risk is operational, whether your team can actually run this daily, the MVP is a pilot with one department.
Those three produce completely different first releases. Building “a small version of everything” serves none of them.
The cut test
For every proposed feature, ask: what happens if a person does this manually for the first six months?
Most features survive manual handling perfectly well at early volumes. Reporting can be a query someone runs on Fridays. Admin screens can be a developer with database access. Bulk import can be a one-off script. None of that is elegant and all of it is cheap, reversible, and tells you what the real requirement is before you build the permanent version.
What not to cut
The keep list is short and it is not about importance. It is about what is expensive to change later.
The data model. Everything else is built on it. Getting it wrong means migrations, and migrations mean downtime and risk. Spend the time here.
Authentication and permissions. Retrofitting a permissions model into a system that assumed one user type is close to a rewrite of every screen.
Audit logging, where you will need it. You cannot reconstruct history you never recorded. If there is any chance of a regulatory or contractual requirement, log from day one.
The workflow that delivers the value. Cut everything around it. Build this one properly. A product that does one thing well is useful. One that does six things adequately usually is not.
Compliance obligations are not scope. If you handle payment data, health records, or personal data at volume, the associated controls are not a later phase. Retrofitting access control, retention rules and encryption costs several times what including them costs, and it is the single most common source of an unpleasant surprise in a second release.
Sequence by risk, not by ease
Once scope is agreed, the order of work is a commercial decision rather than a technical one. Building the easy parts first produces comfortable early progress and concentrates every unknown at the end, when there is no budget left to absorb what you learn.
Build the frightening part first. The integration nobody has tested, the data migration nobody has looked at, the performance question nobody can answer. Early weeks look slower and the project finishes sooner. We cover the warning signs when this goes the other way in why software projects run over budget, and what a proper scoping exercise produces in what actually happens in a discovery phase.
A practical way to run the argument
Put every proposed feature into one of three boxes, with a named owner for each decision.
- Required for the assumption to be tested. Build it.
- Required eventually, cheap to add later. Write it down and do not build it.
- Required eventually, expensive to add later. Build the foundation now, the interface later.
The third box is where judgement is actually needed, and it is short. Most disagreements are really about which box something belongs in, which is a much more tractable argument than whether a feature is important.
If you have a first release that keeps growing and want an outside read on what can safely come out, tell us what you are planning to build.
Common questions
What should an MVP include?
The smallest set of functionality that settles your riskiest assumption, plus the things that are expensive to retrofit: the data model, authentication and permissions, audit logging where it will be required, and any compliance controls. Everything else can usually be handled manually for the first few months.
How do we decide what to cut from a first release?
Ask what happens if a person does it manually for six months. Reporting, admin screens, bulk operations and secondary user roles usually survive that test comfortably. Anything that fails it, or that would require migrating data or rewriting every screen to add later, stays in scope.
Why do smaller projects succeed more often?
Fewer unknowns, fewer integration points, fewer people who must agree, and a shorter gap between making a decision and finding out whether it was right. Across more than 5,400 IT projects the average value shortfall was 56%, larger than the 45% cost overrun, so building the wrong scope is the more common failure.
Sources
- McKinsey & Company with the University of Oxford, Delivering large-scale IT projects on time, on budget, and on value. More than 5,400 projects: 45% average cost overrun, 56% less value than predicted.
- The Standish Group CHAOS research has reported for three decades that small projects succeed at substantially higher rates than large ones. Its methodology has been contested in the academic literature, so it is cited here for direction rather than for precise percentages.
Figures were current at the time of writing (September 2026).
