Scope your MVP around one decision, not a feature list

Almost every founder we talk to has the same first document: a list of features. Sign up, profiles, a dashboard, notifications, payments, an admin panel, maybe an AI assistant. Each item sounds reasonable. Together they describe six months of work and a product that still might not answer the only question that matters at this stage.

A better starting point is not “what should the product do?” but “what do I need to decide after it launches?”

An MVP is a tool for making a decision

The purpose of a first version is to reduce one big uncertainty. Will clinics pay for online booking? Will drivers accept jobs through an app instead of WhatsApp? Will finance teams trust automated invoice matching enough to stop checking every line?

Write that decision down as one sentence, in this form:

After launch, we will decide whether to [invest further / change direction / stop] based on whether [a specific group] does [a specific thing].

If you cannot fill in that sentence, the problem is not the scope. It is that the bet is not clear yet, and no amount of engineering will fix that.

Work backwards from the evidence you need

Once the decision is written down, ask what evidence would let you make it with confidence. Usually it is a behaviour, not an opinion: people completing a booking, paying a deposit, coming back the following week, or replacing a spreadsheet they used before.

Then list only the steps a real user must go through to produce that evidence. For a booking product that might be: find a slot, enter details, confirm, receive a reminder, show up. That path is your MVP. Everything else is a candidate for later.

Cut everything that does not touch the path

Go through the original feature list and put each item in one of three columns:

• On the path. Without it, the user cannot produce the evidence. Build it, and build it properly.
• Supports the path. It makes the path smoother but a manual workaround exists. Do it by hand for the first users: send the reminder yourself, approve accounts from a spreadsheet, issue invoices manually.
• Not related to the decision. Park it. Write it in a “later” list so nobody feels their idea was lost.

Founders are often surprised by how much lands in the second and third columns. Admin panels, analytics dashboards, multiple user roles, and settings pages are frequent examples. They matter for a business, but rarely for the first decision.

Keep quality where it counts

Small scope does not mean careless engineering. The parts on the path should be reliable, secure, and pleasant to use, because a confusing or broken flow produces bad evidence: you will not know whether people rejected the idea or the experience.

What you can relax is breadth, not depth. One payment method instead of four. One language at launch if your first users share it. One platform, often the web, before native apps.

Agree on what “done” means before you start

Before any code is written, write the success measure next to the decision sentence: “If at least 20 of the first 50 clinics we onboard take a real booking in their first two weeks, we continue.” The numbers are yours to choose; the point is to choose them in advance, so the launch produces a decision instead of a debate.

This also protects the budget. When a new feature request appears mid-build, the question becomes simple: does it help produce the evidence? If not, it goes on the later list.

A one-page scope you can share

By the end of this exercise you should have one page with five things on it:

1. The decision sentence.
2. The evidence and the success measure.
3. The user path, step by step.
4. What you will do by hand for now.
5. The later list.

That page is easier to estimate, easier to build, and easier to explain to a co-founder, an investor, or the team you hire. It is also the first thing we ask for when a founder brings us in: if it does not exist yet, writing it together is usually the most valuable hour of the whole project.

If you want a second pair of eyes before you commit, our Product Execution Audit turns your idea into a scoped first version, the main risks and a budget range in five working days. When the scope is clear, we can build the MVP with you.