How to scope an MVP: what to build first, what to cut

Knowing how to scope an MVP is mostly knowing what to leave out. The first version of a product has one job: to find out whether real people want the thing you are building. Everything that does not help answer that question can wait for version two.

This is the method we use in the first week of every project. You can run it yourself with a notebook before you talk to any developer.

Start with one user and one job

Most first versions are too big because they try to serve everyone the founder has ever spoken to. Pick one kind of user and the one job they would hire your product to do.

Write it as a single sentence:

A landlord with two or three flats lists a room and receives enquiries from verified tenants.

If the sentence needs the word "and" more than once, you are describing two products. Choose the one whose users you can reach this month.

This idea is older than software. Eric Ries describes a minimum viable product as the version that lets a team collect the most learning about customers with the least effort, in The Lean Startup. The scope follows from the thing you want to learn.

Write down what you need to learn

Before listing features, list the two or three things that must be true for the business to work. For a rental marketplace they might be:

• Landlords will list a room without being phoned by a salesperson.
• Tenants trust a listing enough to send a message.
• Somebody will pay for a featured listing.

Each feature now has a test to pass: does it help prove or disprove one of these? A dark mode does not. A way for tenants to message landlords does.

List every screen, then sort them

Now walk through the product as your one user, from the first visit to the moment the job is done, and write down every screen they touch. Do the same for the person on your team who will run it, because an admin panel is part of an MVP too.

Sort every screen and feature into three groups:

Be strict about the third column. Features in it are not rejected. They are waiting for evidence.

Cut by asking what you can do by hand

The fastest way to shrink an MVP is to do things manually at first. Ask of every feature in the "must launch" group: could a person do this by hand for the first fifty customers?

• Verification can be a team member checking documents in the admin panel, not an automated identity service.
• Payouts can be a weekly bank transfer, not a payments integration.
• Recommendations can be a hand-picked list, not an algorithm.

Manual steps do not scale, and that is fine. You are buying information, and you will rebuild the parts that prove they matter.

Decide what the first version must not skip

Cutting scope is different from cutting quality. Some things are cheap to do properly at the start and expensive to add later:

1. Sign-in and permissions. Who can see and change what.
2. A phone-sized layout. Most of your first users will arrive on a phone.
3. Analytics and error tracking. Without them you launch blind and learn nothing.
4. Ownership. The code, the domain and every account should be in your name from day one.

We keep these in every build, however small. You can see them in the projects on our work page, such as the Rehnaa rental marketplace, which launched with map search, chat and landlord verification and left everything else for later.

Turn the list into a fixed price

A scope is finished when someone can quote for it. At the end of the week you should have:

• A feature list with the three groups above.
• A map of every screen and how they connect.
• The things you will do by hand at first.
• A fixed price and a launch date for the "must launch" group.

If a developer cannot give you a fixed price from that, the scope is still too vague. Go back to the screen list and fill in the gaps.

This is exactly what the blueprint week in our MVP development process produces, and why we can agree the price before design starts.

Common mistakes when scoping an MVP

Building for investors and not for users. A demo that impresses in a meeting is not the same as a product ten people use every week. Scope for the ten people.

Launching on every platform at once. A web app that works well on phones is often enough to test the idea. Add native apps when users ask for them, or start with the phone app if the product only makes sense in a pocket.

Treating the first version as final. It will change. Scoping an MVP well means the second version is shaped by what users did, not by what you guessed.

A one-page checklist

• One user, one job, in one sentence.
• Two or three things you need to learn.
• Every screen listed for the user and for your own team.
• Each feature marked: must launch, launch if cheap, version two.
• Manual stand-ins chosen for anything expensive.
• Sign-in, phone layout, analytics and ownership kept in.
• A fixed price and a launch date.

If you would like a second pair of eyes on your list, send it to us. We will tell you what we would cut.