How to scope an MVP: deciding what your first release should (and shouldn't) do

Most first products are late and over budget for the same reason: they try to do too much. The phrase "minimum viable product" is meant to prevent that, but in practice it is often stretched to mean "the full product, built a bit faster". This guide sets out the method we use with founders to decide what a first release should actually contain.

What an MVP is for

An MVP is not a smaller version of your final product. It is the smallest thing you can put in front of real users that tests whether your central idea is right. Its job is to answer a question, such as:

• Will shop owners photograph their bills every day if it saves them a call from their accountant?
• Will clinic receptionists use a booking link instead of a phone call?
• Will teams pay for a weekly summary of their sales data?

If you cannot state the question your MVP answers in one sentence, the scope is not ready yet.

Step 1: Choose one user and one problem

Start with a specific person, not a market. "Small businesses" is a market. "The owner of a two-person kirana store who does their own billing and sends bills to a CA every month" is a user. The more precisely you can describe them, the easier every later decision becomes.

Then write down the one problem you are solving for them, in their words. Not "inefficient accounting workflows", but "my CA keeps asking me for the same bills and I never know what's missing."

If you have several types of user, as most marketplaces and B2B tools do, pick the one whose behaviour has to change for the product to work. Build for them first.

Step 2: Map the journey, end to end

Before listing features, draw the path your user takes from the moment they have the problem to the moment it is solved. Keep it to six to ten steps. For example:

1. Owner receives a purchase bill from a supplier.
2. Owner opens the app and photographs it.
3. The bill is attached to the right month.
4. The accountant sees the new bill.
5. The accountant checks it and marks it reviewed.
6. The owner sees that the month's bills are complete.

This journey is your MVP. Every screen you build should support a step on it. Anything that does not is a candidate for later.

Step 3: Cut features with three questions

Now list every feature you have been imagining and test each one:

1. Is it on the journey? If the user can complete the journey without it, it is not in the MVP.
2. Can it be done manually for now? Many features can be replaced, at first, by a person doing the work behind the scenes: sending a reminder by hand, preparing a report in a spreadsheet, approving accounts by email. This is slower, but it lets you learn whether the feature is needed before paying to build it.
3. Does it protect trust? Some things are not optional even in a first version: data security, correct calculations, reliable sign-in, and the ability to get data out. Cutting these costs more than it saves.

Typical things that can wait: settings and customisation, admin dashboards, multiple user roles, integrations with other tools, notifications beyond the essential one, and anything described as "nice to have".

Step 4: Decide what "working" means

Before you build, agree what will tell you the MVP has worked. Pick a small number of measures tied to your question, for example:

• 20 businesses complete the journey at least once a week for a month.
• Accountants report spending less time asking for documents.
• At least five customers agree to pay after the trial.

Write these down and share them with the team. They will settle arguments about scope later, because any feature can be judged by whether it helps move one of these numbers.

Step 5: Choose the platform last

Founders often start with "we need an app". The platform should follow from the user. A business owner who lives on their phone needs a mobile experience. An accountant at a desk all day needs a web app with tables and keyboard shortcuts. Sometimes, as with products that serve both sides, you need both, but you can still start with the side whose behaviour you are testing. We cover this decision in more detail in web app, mobile app or both?

Step 6: Plan the first eight weeks after launch

An MVP that launches and is then left alone teaches you very little. Plan, before launch, how you will:

• watch usage, with simple analytics on the journey steps, to see where people drop off;
• talk to users, ideally five to ten conversations in the first month;
• fix what blocks the journey first, before adding anything new; and
• decide at the end of the period whether to continue, change direction or stop.

A worked example

Suppose the idea is "an app that connects small businesses with their accountants". The full vision includes billing, stock, reports, payments, GST filing support and a firm dashboard. A sensible MVP might contain only:

• for the business: sign in, photograph a bill, see which months are complete;
• for the accountant: see each client's bills by month, mark them reviewed, send a request for missing bills.

Everything else, from stock to reports, is valuable, but none of it is needed to test whether owners will send bills through an app and whether accountants will use what arrives. Once that behaviour is proven, the rest has something to build on.

Common mistakes

• Building for every possible user at once.
• Treating the MVP as a demo rather than something real users rely on.
• Skipping the measures, so nobody knows whether it worked.
• Cutting quality instead of scope. A small product that works is better than a large one that breaks.

Key takeaways

• An MVP answers one question about your idea.
• Start with one user, one problem and one journey.
• Cut anything not on the journey, or anything that can be done by hand for now, but never cut trust.
• Decide what success looks like before you build.

If you are shaping a first product and want a second opinion on the scope, talk to us. Helping founders decide what to build first is a large part of what we do.