MVP Scoping Guide: How to Decide What to Build First

Scoping an MVP means choosing one user, one problem and one measurable outcome, then building only what is needed to learn whether that outcome happens. Everything else goes on a backlog. Done well, scoping takes days, not weeks, and it decides whether your first release teaches you something or just burns runway.

This guide walks through the process we use with founders in Zurich and across Switzerland: from the assumption you need to test, to the feature cut, to the budget conversation, to the metrics that tell you what comes next.

TL;DR

• Scope around one user, one job to be done and one outcome you can measure. Anything that does not serve it waits.
• Write down the assumption that would sink the business if it were false, and design the MVP to test that assumption first.
• A prototype tests whether people understand the product. An MVP tests whether they get enough value to come back or pay.
• Estimate time and budget from the feature list, the integrations and the unknowns, not from a generic number. Fix the scope, and let the learning decide the next phase.
• Set success thresholds before launch, so the result cannot be argued away afterwards.

What an MVP is, and what scoping is for

An MVP is the simplest version of a product that puts your idea in front of real users and tests your core assumptions. The point is risk reduction: you want to find out early if you are building something nobody wants. The Innosuisse and Founders Hive guide to business model testing frames it as scientific testing: replace assumptions with facts as cheaply and quickly as you can. The goal is not to prove the founder right.

That framing changes how you scope. If the MVP is an experiment, scope is whatever the experiment needs. If it is a “version one” of the full vision, scope grows with every meeting. Most overruns we see come from the second mindset.

Venture firm CRV puts the same idea another way: the unit of progress in an MVP is validated learning, not feature count or lines of code. Keep that sentence on the wall while you scope.

MVP or prototype: which one do you need?

Founders often ask whether they need a prototype or an MVP. They answer different questions.

	Prototype	MVP
Question it answers	Do people understand how to use this?	Do real users get enough value to keep using or paying?
Typical form	Paper sketches, clickable Figma screens, sometimes a coded demo	A working product with a narrow feature set
What you measure	Task completion, confusion, comprehension	Activation, retention, willingness to pay
Backend	Usually none or faked	Real, even if small
Cost and speed	Days to a few weeks	Weeks to a few months

The rule of thumb: match the fidelity to the question. If you need to know whether users can find the booking button, a clickable model is enough. If you need to know whether clinics will actually switch from their paper diary, you need something that books real appointments.

One caution from BYU’s product management course: an MVP has to deliver the experience well enough that feedback is an honest signal. Broken prototypes draw polite responses that teach you nothing. Small does not mean sloppy. A narrow product that works beats a wide one that half works.

The cheapest path is often a sequence: prototype to test comprehension, a manual test to test demand, then a coded MVP once you know what deserves code.

Step 1: Name the user, the problem and the assumption

Before you list a single feature, answer three questions in writing.

1. Who is the user? Not “small businesses”. A specific segment: for example, independent physiotherapy practices in German-speaking Switzerland with one to three practitioners.
2. What is the job they need done? Describe it as something that happens, not something they might want: what they did last time, how often, which workaround they use and what it costs them in time, money or frustration.
3. What is the riskiest assumption? The one whose failure invalidates the business. Often it is not technical. It is “people will pay for this” or “they will change their current routine”.

The Innosuisse guide recommends treating each element of your business model as a hypothesis, then ranking assumptions by how critical they are and how uncertain you are about them. It also asks for falsifiable success metrics defined before the experiments run. It suggests 10 to 20 structured problem interviews to validate the customer segment and problem.

In those interviews, ask about past behavior, not future intentions. “Would you use an app that does X?” gets you a polite yes. “Tell me about the last time this went wrong” gets you facts. The Lean Startup team described how a founding team found its original problem hypothesis was wrong only after talking to users, which saved them from building the wrong thing.

First Round Review goes one step further and recommends minimum viable tests on individual risky assumptions before you build an MVP at all. A landing page can test the value proposition. If your assumption is about willingness to pay, a manual version of the service can test that for a fraction of the cost.

Concierge and Wizard of Oz: MVPs without much code

Two patterns are worth knowing. In a Wizard of Oz test, the user sees a real front end while people do the work behind it by hand. In a Concierge test, a human delivers the service directly to the user. Mind the Product explains the difference between the two well. Both let you learn about demand before you invest in automation, and both are legitimate MVPs.

A founder who wants an AI-driven matching tool, for example, can often run the matching by hand for the first 20 customers. If nobody pays, you have saved the build. If they do, you now know exactly which parts to automate first.

Step 2: Turn the outcome into a feature list

Now you can write features, and the test for each one is simple: does the core user need this to reach the core outcome in the first release?

Take a booking tool for clinics as an example. If the outcome is fewer missed appointments, the essentials are a booking page, availability settings, a calendar, confirmation, reminders and cancellation. Online payments, patient history, reports and a native mobile app are supporting features. They are useful, and they can wait until the core flow proves itself.

A simple cut: must, should, later

List every feature the team has mentioned, then sort them.

• Must: without it, the user cannot reach the outcome. If you remove it, the experiment fails.
• Should: it makes the experience better, but a user can still reach the outcome without it. Usually a manual workaround exists.
• Later: a good idea, but it does not test the main assumption.

Be strict about the “must” column. A good sign is when it fits on one screen and you can describe the whole product in two sentences. If you cannot, you are scoping a product, not an MVP.

For each “should”, ask what the manual workaround is. Sending reminders by email from a spreadsheet for the first 30 users costs nothing. Building a notification engine costs weeks.

Adjust the bar to your market

The right level of polish depends on competition. In a crowded market, users compare you with established alternatives, so the minimum is higher. In a new market, the first job is to show the problem exists, and a rougher product can do that. Be honest about which situation you are in. It changes the “must” column more than any framework does.

Decide on the platform last

Founders often start with “we need an iOS and Android app”. Ask whether a responsive web app would deliver the same learning. It usually can, at lower cost and with no store review in the way. If a native app is truly needed, plan the store listing early. Getting indexed correctly on launch day matters, because a new app with weak metadata is invisible to the people you want to test with.

Step 3: Estimate time and budget in Switzerland

We will not give you a single universal number, because it would mislead you. Swiss prices vary widely with who builds, what is built and how much is unknown. What we can do is tell you what drives the estimate, so you can judge any quote you receive.

The four drivers of an MVP estimate

1. Number and complexity of core flows. Each user journey (sign up, book, pay, manage) has screens, logic, edge cases and tests. Three well-defined flows are a very different project from ten.
2. Integrations. Payment providers, CRM, ERP, shop systems, identity and email each add work, and often unknowns. Connecting to a legacy system is the classic source of surprise.
3. Compliance and data. Personal data handled under the Swiss data protection act, or sector rules in health or finance, add design and hosting decisions. Raise these in the first conversation, not the fifth.
4. Unknowns. If the problem is not yet validated, or the design is not settled, the budget must absorb change. A fixed scope with fixed price only works when the scope is actually fixed.

How to get a trustworthy quote

• Bring the one-page scope: user, outcome, assumption, must-have list, and what is explicitly out.
• Ask who will actually do the work, and whether the same people will be there from kickoff to handover. Mid-project staff changes are one of the most common causes of rewritten requirements.
• Ask what you own at the end: code, repository, hosting accounts, documentation. You want to be able to move on without the studio if you choose.
• Ask for a phased plan: a first release scoped to the experiment, then a decision point, rather than one large estimate for the whole vision.

As a rough planning principle, a well-scoped MVP is measured in weeks to a few months, not a year. If a quote runs well beyond that, the scope has probably grown past an MVP.

Step 4: Set success criteria before you build

The most useful scoping artifact is not the feature list. It is the sentence that says what result would convince you to continue and what would convince you to stop.

Your thresholds should be specific. One example from Unlock Labs is a target conversion rate of 25% for waitlist signups. Your number will depend on your channel and price, so check it against realistic conversion rate benchmarks for similar offers rather than picking one that feels good.

A workable set of signals, according to Microsoft for Startups, covers three things read together: activation, retention and conversion. Their validation framework also tests product feasibility, technical scalability and market demand in parallel, instead of one after another.

A scoping template you can copy:

Field	Example
User	Solo practitioners, 1 to 3 staff
Outcome	Reduce missed appointments
Riskiest assumption	Practices will send reminders through a new tool
Core features	Booking page, availability, calendar, confirmation, reminders, cancellation
Deferred	Payments, patient history, reports, native app
Success threshold	Defined before launch: activated practices, 4-week retention, paid conversions
Review date	Set at kickoff

Step 5: Launch small, then decide what to build next

Put the MVP in front of real users in structured sessions and track the numbers at the same time. Watching someone try to complete the core flow tells you why the metrics look the way they do. The metrics tell you whether what you saw in sessions is typical.

Then compare the results with the thresholds you set. Three outcomes are possible:

• Threshold met: build the next most valuable item from the backlog, not the loudest request.
• Partly met: find where users drop off and change one thing at a time.
• Not met: go back to the assumption. Maybe the segment, the problem or the price was wrong. Changing direction at this point is the MVP working, not failing.

The MVP is the beginning of a learning loop of release, measure, learn and improve. Real behavior should guide the next product decisions, more than opinions in the room.

Common scoping mistakes

• Scoping from the solution. “We need a dashboard” is not a user need. Start from the job.
• Building for three user types at once. Choose one. The others come later.
• Treating every stakeholder request as a must. Use the sort above and make the trade-off visible.
• Skipping the manual test. If you can fake it by hand, do that first.
• No stop criteria. Without a threshold, any result can be read as encouraging.
• Underestimating integrations. Anything touching an existing shop, CRM or ERP needs its own discovery.
• Choosing a builder who changes the team mid-project. Continuity matters more than a polished pitch.

How we help at Ampersand

We are a small Zurich studio, and senior engineers stay on your project from the first consultation to handover. That matters most in scoping, where a wrong decision quietly becomes a rewrite three months later. We build websites, web and mobile apps and MVPs, and platforms, and we can help you shape the scope before any build begins through our advisory plans: Guidance is 799 CHF per month. Once your product is live, Run & monitor support is 750 CHF per month. Other offers are scoped to your project; see the services and plans or our recent work.

FAQ

What is the difference between an MVP and a prototype?

A prototype tests whether people understand how to use the product, often through a clickable design. An MVP is a working product that tests whether real users get enough value to keep using it or to pay. Many teams do both, starting with the prototype.

How many features should an MVP have?

As few as it takes to deliver the core outcome for one user. If you cannot describe the product in two sentences, the list is probably too long. Move everything else to a backlog and revisit it after you see real behavior.

How long does it take to build an MVP?

A tightly scoped MVP typically takes weeks to a few months, depending on the number of core flows, integrations and compliance needs. Time grows quickly when the scope is unclear or the design keeps changing. A phased plan with a decision point after the first release keeps the commitment manageable.

Do I need to talk to users before scoping?

Yes. Problem interviews about recent real experiences are the cheapest way to check that you are solving something people care about. The Innosuisse guide suggests 10 to 20 structured interviews to validate the customer segment and the problem.

Sources

• Guide to Business Model Testing, Innosuisse and Founders Hive
• MVP Methodology, CRV
• Finding and Validating the Problem, BYU Strategy
• How to Test Your Product Before You Build It, Lean Startup Co.
• The Minimum Viable Testing Process, First Round Review
• Wizard of Oz vs. Concierge testing, Mind the Product
• What Is a Minimum Viable Product, Microsoft for Startups
• The Ultimate Guide to Designing and Testing MVPs, Unlock Labs
• Conversion rate benchmarks
• App launch and store indexing