How to Scope an MVP: From Idea to Feature List

Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.

Scoping is where MVPs are won or lost, and it happens before anyone writes code. A founder arrives with a list of thirty features, all of which seem necessary, and the job is to find the five that are. This post gives you a method to do it, a worked example, and the written scope that comes out of it, which is also the document that gets you an accurate quote.

What do you write before the feature list?

Three sentences, and they are harder than they look:

1. The problem. One sentence, in the user's words, about something they do today that is slow, expensive or painful. If you cannot say it without describing the solution, you have not found it yet. Defining the ultimate problem is our longer treatment.
2. The user. One type of person, specific enough that you could find ten of them this week. Not "small businesses". "Owners of independent restaurants with two to five staff who do their own rotas."
3. The core journey. The sequence of steps from the user arriving to the user getting the value, for the problem above, with nothing else in it. Usually five to eight steps.

Everything in the MVP serves the core journey. Everything that does not serve it is a candidate for later. That rule, applied honestly, does most of the scoping on its own.

How do you score the feature list?

List every feature anyone has suggested. Then ask three questions of each:

Most features fail question 1 and question 2, and most of the rest can be done by hand. What survives is the MVP. A typical thirty-feature list produces four to six.

A worked example

Take a product that helps independent restaurants build staff rotas. The founder's list had 24 features. The three sentences: owners spend two hours every Sunday building the rota in a spreadsheet and messaging it out; the user is the owner; the core journey is open the app, see staff and their availability, drag shifts into a week, publish, staff receive it.

• Staff list with availability: needed for the journey. In.
• Drag shifts into a week view: needed. In.
• Publish and notify staff by message: needed. In.
• Staff app to view their shifts: not needed for the owner's journey, and a text message does it. Out, by hand.
• Shift swap requests between staff: not needed, tests an assumption, can be done by message. Out, by hand.
• Labour cost forecast: not needed, tests whether owners care about cost against sales, cannot be faked at scale but can for a hundred users with a spreadsheet. Out.
• Payroll export: not needed, tests nothing new, can be done by hand. Out.
• Templates for recurring weeks: not strictly needed, but tests whether owners build the same rota weekly, which decides the product's direction, and cannot be faked. In.
• Multi-site support, integrations with point of sale, holiday tracking, compliance reports, manager roles, mobile app: all out.

Four features, one user type, web only. A build of $20,000 to $40,000 (€17,000 to €35,000, £15,000 to £30,000) and eight to ten weeks, instead of a 24-feature platform that would have cost four times as much and tested the same assumption. The owner's hour on Sunday is the metric.

What do founders include too early?

• A second user type. Each role doubles the screens and the testing. The second side of a marketplace is the exception, and even there one side can often be served by hand at first.
• Settings and preferences. Decide the defaults. Let users ask for options.
• Social and sharing features. These test nothing until there are users to share with.
• Multiple platforms. One. See mobile app or web platform.
• Integrations that a person can do. Exporting to the accounting tool by hand each month is fine for a hundred users.
• Reporting and dashboards. You do not yet know which numbers matter.
• Admin tools beyond the basics. You need to see users and fix data. You do not need a back office.

What an MVP is and what to leave out covers the reasoning behind each.

What should never be cut?

The core journey, complete and reliable. Analytics on every step of it. Basic security: encrypted connections, hashed passwords, nothing public that should not be. A way to contact you. And enough design that the first session does not confuse the user, since a confused user tells you nothing about the idea. Scoping down is not the same as building badly.

What does the written scope look like?

One to three pages: the three sentences, the core journey as numbered steps, the feature list with in and out marked and a one-line reason for each, the platform, the user type, what you will do by hand, and what success looks like at 90 days. That document is the brief. Send it to teams for quotes and you will get comparable numbers back. Send a thirty-feature list and every quote will be for a different product. How to write an app brief when you are not technical shows the format.

How 7L scopes

Discovery at 7L is this method, run with the founder over one to two weeks, and the written scope is its output. We have talked founders out of more features than we have built, and we count that as the most valuable part of the engagement, because the feature we cut is money that stays in the company. If you have a feature list and want it scored, send it over and we will do the first pass with you.