How do you scope an MVP? What belongs in the first release and what can wait

You scope an MVP by choosing the one question you want answered, not by trimming a feature list. What goes into release one is the narrowest vertical slice in which a single user can finish a real job end to end: one user type, one scenario, one channel. What stays out is every variation of that job, the edge cases, the admin panels, the reports and the settings screens added because "we'll need it eventually." One test settles most arguments: if we remove this, can the first user still finish the job? If yes, it does not belong in release one.

Why the term MVP causes so much trouble

Frank Robinson, co-founder of SyncDev, coined the phrase in 2001, and his definition was not really about minimalism. He described it as the product that maximises return on risk for both the vendor and the customer. When Eric Ries popularised the term, the emphasis moved to learning: the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. Ries himself felt the need to add that despite the name, an MVP is not about producing the bare minimum of anything.

In practice the phrase gets pulled in two directions at once. In his 2016 article, Henrik Kniberg wrote that for some customers MVP effectively means "minimum releasable crap," and proposed dropping the term for three plainer stages: earliest testable, earliest usable, earliest lovable. Marty Cagan draws a related line. The thing you build to test a hypothesis is an MVP test, not a product; when you say product you mean something people choose to use, can figure out on their own, and that you can deliver when it is needed. Using one word for both is how two people leave a meeting having agreed to different things.

Inside a company, an MVP does a different job

At a startup the underlying question is whether anyone wants this at all. In commissioned business software the demand is already established, the decision to build has been made. There the point of an MVP is not to validate demand but to pull delivery risk forward: to find out in week six rather than month six that the ERP actually returns that field in the format you assumed, that the data model holds up against real records, that the warehouse team will genuinely adopt the flow.

So make the distinction in the first meeting and put it in writing. Is this an MVP, meaning we may learn something and change direction, or is it phase one, meaning the direction is settled and we are only cutting scope? Those are two different acceptance criteria, two different budgets and often two different contracts. On how that risk gets split between the parties, see fixed price or time and materials.

Cut vertically, not by layer

Scope discussions usually happen along the wrong axis. "Let's finish the data model and the admin panel first, screens come later" is a horizontal cut, and it reliably produces half a system that nobody can use. The walking skeleton, named by Alistair Cockburn in the nineties, argues the opposite: build a tiny implementation that performs one small end-to-end function, and even if it does not use the final architecture, make it connect the main components. Kniberg's well-known skateboard-to-car drawing is the same idea in pictures.

In an order management project the difference looks like this. The wrong first release: a data model covering every order type, a full permission matrix, management reports, and not one order that has actually travelled through the system. The right first release: one order type, one sales channel, one currency, but the whole path from entry through approval to invoice working for real. Returns, partial shipments, the second warehouse and the other channels are later slices. The difference is that in the second version a real order has gone through the system by week six.

Make the cut list concrete

These can be left out of release one in almost every project: two roles instead of the full permission matrix, a CSV export instead of reporting screens, bulk import, multiple languages, a notification preferences screen, a settings page (values can sit in code for now), theming and appearance options.

Then there is automation you should deliberately not write yet. The Dropbox demo video shot before the product existed is the famous version of this, but the corporate equivalent looks far more ordinary: a daily CSV transfer instead of a real-time integration, one person in operations approving items instead of an approval workflow, a manual matching screen instead of a matching algorithm. A manual step looks primitive on a slide. Ripping out an automation that learned the wrong rules costs more, and those rules are usually only discovered by doing the work by hand for a few weeks.

Most features really do go unused, but pick your statistic carefully

Pendo's 2019 Feature Adoption Report analysed three months of anonymised usage across 615 subscriptions from customers who had been on the platform for over a year. Two findings are clean: in the average product, 80 percent of features are rarely or never used, and roughly 12 percent of features drive 80 percent of average daily usage. The same report's $29.5 billion figure for industry-wide waste is not a measurement; it is an extrapolation built on public companies' R&D spend. The first two numbers come from the data, the third is interpretation.

Be careful with the widely shared claim that 45 percent of features are never used. That number comes from Jim Johnson of the Standish Group at the XP 2002 conference, and it rests on four applications, all of them internal-use systems rather than commercial products. Mike Cohn documented this years ago. The conclusion may well be directionally right, but it is not a sample to build a budget decision on. If your own product is already live, there is a better way to end the argument: instrument feature-level usage and pull the list of screens nobody has opened in three months.

The mechanism that actually cuts scope: fix the time

The idea of an "appetite" from Basecamp's Shape Up is useful here. An estimate starts with a design and produces a number; an appetite starts with a number and shapes the design to fit inside it. You say "we have six weeks for this problem, the solution will be built to that." Shape Up works with two standard sizes: small batches of one to two weeks, and big batches that fill a six-week cycle. When the scope will not fit, you do not grow the appetite, you narrow the problem or split it in two.

The part that gives it teeth is the circuit breaker: a project that does not ship within its cycle is cancelled by default rather than extended by default. It sounds harsh, but what it really does is take the scope-cutting decision off the development team and put it into a rule. Wherever extension is the default, release one keeps growing, because nobody has to say no out loud and so nobody does.

Why priority frameworks are not enough on their own

Build a MoSCoW table and everyone moves their own item into the Must column, because nobody wants to label their own need as a Could. Scoring models like RICE produce an invented ranking the moment the inputs are invented. These tools are good for structuring the conversation. They do not make the decision.

Two sharper questions do. First: if we drop this, can the first group of users still complete the job end to end? Second: if we don't build this now, will we fail to learn what we set out to learn? Any item that answers "yes they can" and "no it won't" moves to the second slice. There is also an authority question. One named person has to own the cut, and that person should sit on the customer side, not the delivery side. Committees do not cut scope. Committees add scope.

The four things you do not cut

Scope cutting has a floor. Leave these four out of release one and adding them back costs several times more, because they are architectural decisions rather than features.

Authentication and authorisation. "Let everyone see everything for now, we'll add permissions in phase two" produces a temporary state that lives in production for years. There is a reason the OWASP list still opens with broken access control: authorisation is not something you sprinkle over screens afterwards, it is a layer every request passes through.

Secrets handling. In release one nobody wants to set up environment variables and a vault, so the key goes into the code and stays there. When it leaks later, deleting the line is not enough because it lives on in the repository history. The details are in managing hardcoded secrets.

Backups and a way back. Data produced by pilot users is not test data. Lose the real records entered in the first four weeks and what you lose is not the MVP, it is that team's willingness to try the next release.

Logging and error tracking, even in their simplest form. If the point of release one is learning, you cannot learn from a system you cannot see into. Without knowing how many users dropped out at which step, all you have left is impressions. Observability, SLOs and error budgets is a good starting point for the measurement side.

An MVP ends with a decision, not a date

This is the step teams skip most often. Going live does not end an MVP; the MVP ends when you look at the results and decide something. Write the decision down before you start: which metric, at which threshold, on which date, triggering which choice. A sentence like this is enough. "If at least 12 of the 20 users in the pilot warehouse complete the flow end to end once a week for four weeks, we move to the second slice; if they don't, we redesign the flow." Without that sentence the MVP quietly becomes phase one, nobody stops to look, and the features you cut come back one by one.

AI made prototyping faster, it did not change the decision

Producing a screen mockup or a working flow in a few hours is genuinely possible now, and it has made the discovery half of an MVP much cheaper. A design argument that would have run for a week can be closed in an afternoon by building both versions and putting them in front of a user. What has not changed is that prototypes and production code are written for different purposes. A prototype exists to answer a question and most of it gets thrown away. Production code is written to live for five years, be modified and be handed to someone else.

That is exactly where the risk sits. The fast prototype demos well, someone says "it already works," and it ships. It has no tests, half a permission model and dependencies nobody reviewed. From that point on you repay the weeks the MVP saved as technical debt. A one-sentence rule up front is usually enough: prototypes stay in the repository they were born in, and anything headed for production goes through normal code review and the deployment pipeline.

Four things to do this week

One: write the single user type and single scenario of release one in one sentence. Something like "a warehouse supervisor can enter a standard single-channel order, approve it and produce the invoice." If the sentence runs past two lines, the scope is still too big.

Two: take your current feature list and, next to every item, write the answer to "does that sentence still work without this?" Every item where it does moves to the second slice, and the argument now runs down that column instead of around the room.

Three: set the appetite. How many weeks are you giving this, and what happens when they run out? If extension is the default, the scope decision will never actually get made.

Four: write the decision sentence and put a date on the calendar. What you will measure, what the threshold is, and what you do if it is missed, all agreed before you start. If the open question is still whether a packaged product would do the job, off-the-shelf or custom software is the piece to read before release one starts.