Scoping an MVP: how to decide what goes into version one

What an MVP is, and what it is not

“Minimum viable product” is one of the most used and most misunderstood terms in software. Eric Ries, who popularised it, defined the MVP in a 2009 post as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. In the same post he stresses that the MVP is not about building minimal products for their own sake, and that it takes judgement rather than a formula.

That definition has two consequences for scoping:

• The goal is learning, not a cut-down launch. An MVP exists to test whether your key assumptions are true: that the problem is real, that people will use your solution, and that they will pay for it or adopt it.
• “Viable” still matters. If the product is too broken or too thin for real users to try, it teaches you nothing reliable. Users who abandon a confusing prototype tell you about the prototype, not the idea.

Scoping an MVP is therefore the discipline of choosing the smallest product that can answer your most important questions credibly.

Step 1: Name the riskiest assumptions

Every new product rests on a set of beliefs. Write them down and rank them by how damaging it would be if they were wrong and how little evidence you currently have. Typical examples:

• Target users experience this problem often enough to change their behaviour.
• They will trust a new provider with their data or money.
• The core workflow can be completed in a reasonable time without training.
• A specific integration (a payment gateway, a government API, a partner system) works as expected.
• Operating costs per user will be sustainable.

The top two or three assumptions define what version one must test. Features that do not help test them are candidates to defer.

Some assumptions can be tested without software at all, through interviews, landing pages, clickable prototypes or a manual service run behind a simple interface. Ries gives the example of a feature that took weeks to build and that nobody wanted, where a cheap test would have exposed the problem far sooner. Build software only for the questions that genuinely need it.

Step 2: Define success before you build

For each assumption, decide what evidence would confirm or reject it, and how you will collect it. For example:

Agree thresholds before launch. Without them, any result can be read as success. Make sure analytics and feedback channels are in the MVP scope, not added afterwards.

Step 3: Map the user journey, then slice it

List the steps a user takes from first contact to getting value: discovering the product, signing up, setting up, doing the core task, seeing the result, coming back. Jeff Patton’s user story mapping technique lays stories out along this path, which keeps attention on the user’s journey rather than on a long, flat list of features.

Then slice across the whole journey rather than perfecting one part of it. A thin version of every essential step, working end to end, is far more useful than a polished sign-up flow leading to a half-built core feature. For each step ask: what is the simplest version that still lets a real user get through?

Step 4: Prioritise with MoSCoW

Once you have candidate stories, you need a disciplined way to say no. The MoSCoW technique, from the DSDM framework maintained by the Agile Business Consortium, sorts requirements into four groups:

• Must Have: without these, the release is not worth deploying. Together they form the Minimum Usable SubseT, the part that is guaranteed to be delivered.
• Should Have: important, but the product remains viable without them, perhaps with a workaround.
• Could Have: desirable but less important; these are the first to go if time runs short.
• Won’t Have this time: explicitly agreed to be out of scope for this release, and recorded so they are not quietly reintroduced.

The Consortium recommends keeping Must Haves to typically no more than 60% of the effort, with around 20% in Could Haves acting as contingency. These are guidelines rather than fixed rules, but the principle matters: if everything is a Must Have, there is no room to absorb surprises, and the deadline or the quality will give way instead.

A good test for a Must Have is to ask what would happen if it were missing on launch day. If the honest answer is “users could still test our main assumption”, it is not a Must Have.

Step 5: Keep the non-negotiables

Cutting scope does not mean cutting corners. Some things belong in every release, however small:

• Security basics: secure authentication, authorisation checks on every request, encrypted connections, and safe handling of secrets.
• Privacy: collect only the personal data you need, explain how it is used, and meet the legal requirements of the markets you launch in.
• Accessibility: core journeys usable with a keyboard and screen reader, with sufficient contrast and clear labels.
• Reliability: backups, error monitoring and a way to roll back a bad release.
• Analytics and feedback: the instrumentation needed to measure the success criteria from Step 2.

The Scrum Guide captures this with the Definition of Done, a formal description of the quality an Increment must meet; work that does not meet it cannot be released and goes back to the Product Backlog. Agree a Definition of Done for the MVP at the start, and include the items above in it.

Step 6: Choose an architecture you can change

An MVP should be built well enough to evolve, but not over-engineered for scale it may never reach. Martin Fowler’s essay on sacrificial architecture argues that it is reasonable to expect early code to be replaced as a product grows, provided internal quality stays high and the system is modular enough that parts can be swapped out. He also notes that a monolith often suits this early stage better than microservices, which add complexity up front.

In practice that means a straightforward, well-structured application on mainstream, well-supported technologies, with managed hosting and automated deployment from the first week.

Step 7: Test with real users early and often

Do not wait for launch to learn. Usability testing with a handful of people finds a large share of problems. Jakob Nielsen of Nielsen Norman Group argued in 2000 that a test with five users uncovers roughly 85% of usability problems, and recommended spending the budget on several small rounds of testing rather than one large one, fixing problems between rounds.

Release in small increments too. The Agile Manifesto’s principles favour delivering working software frequently, from every couple of weeks to every couple of months with a preference for the shorter timescale, and describe simplicity, the art of maximising the work not done, as essential. The Scrum Guide adds that each Increment must be usable to provide value and that several Increments can be created within one Sprint.

Common scoping mistakes

• Starting from a feature list rather than assumptions. The result is a smaller version of a full product, not a learning tool.
• Building administration before value. Elaborate admin panels, settings and reports can usually wait; a simple internal tool or even manual processes may do for the first users.
• Too many user types at once. Serve one primary user group well before adding others.
• No measurement. If you cannot tell whether the MVP worked, you have spent the budget without learning.
• Never stopping. An MVP that keeps absorbing “one more feature” stops being minimal and delays the learning it was meant to deliver.

A one-page MVP scope

Before development begins, you should be able to fit the following on a single page:

1. The problem and the primary users.
2. The two or three assumptions this release will test.
3. Success measures and thresholds for each.
4. The end-to-end journey, with the simplest acceptable version of each step.
5. Must, Should, Could and Won’t Have lists.
6. The Definition of Done, including security, privacy, accessibility and monitoring.
7. A target release date and the plan for collecting feedback.

If the page is hard to write, the scope is not ready. If it is easy, the build will be far more focused, and the first release will tell you what to build next.

Sources

1. Eric Ries: Minimum Viable Product: a guide (2009)
2. Jeff Patton & Associates: User Story Mapping
3. Agile Business Consortium: What is MoSCoW Prioritization?
4. The Scrum Guide (2020)
5. Martin Fowler: Sacrificial Architecture
6. Nielsen Norman Group: Why You Only Need to Test with 5 Users
7. Agile Manifesto: Principles behind the Agile Manifesto