Scoping an MVP That Survives Contact With Real Users

Most failed MVPs were not built badly. They were scoped to prove nothing.

The pattern is consistent enough to be depressing. A founder spends four months and a meaningful share of their runway building a smaller version of the full product. It launches. A few hundred people look at it. Some sign up, fewer come back, and the founder is left holding a working piece of software and no clearer idea of whether the business works than they had at the start.

The build was fine. The scope answered no question.

This is the sequence we use to avoid that outcome. Eight weeks is the shape it usually takes, but the weeks matter far less than the order.

Week zero: write the falsifiable sentence

Before any scoping conversation, the founder writes one sentence in this form:

We believe [a specific group of people] will [do a specific, observable thing] because [a specific reason]. We will know we were wrong if [a specific thing does not happen].

The last clause is the one that does the work, and the one people resist. "We will know we were wrong if…" forces a commitment to what failure looks like before the emotional investment of building. Without it, every result gets read as encouraging, because there is always a story that makes a disappointing number sound like a promising start.

A weak version: We believe small businesses want better scheduling software. Nothing about that can turn out to be false.

A usable version: We believe independent salon owners will move their bookings off paper within two weeks of signing up, because reducing no-shows is worth more to them than the effort of switching. We will know we were wrong if fewer than a third have entered a full week of real appointments by day fourteen.

The second one tells you what to build and what to measure. It also tells you what not to build, which is the more valuable half.

Weeks one and two: find the spine

The spine is the shortest path a real user can walk from arriving to getting the thing they came for. Not the shortest path to seeing your product. The shortest path to the outcome that made them curious in the first place.

For the salon example the spine is roughly: owner signs up, adds their services and hours, gets a link they can share, a client books through it, the owner sees the booking. That is it. Every screen that is not on that path is a candidate for cutting, and the default answer for candidates is cut.

Finding the spine is a design exercise, not a technical one, and it usually takes two weeks of genuine conversation rather than two days of wireframing. What makes it slow is that founders arrive with a feature list and the job is to work backwards from the list to the assumption underneath it. Roughly half of any initial feature list turns out to serve a different assumption than the one being tested, worth building eventually, worth nothing now.

Two weeks also buys the architectural decisions that are expensive to reverse: the data model, how accounts and permissions work, whether you will need multi-tenancy. Those are cheap to get right at the start and painful at any point afterwards — the same reason our engineering process front-loads them.

Weeks three to five: build the thin slice

Three weeks of building is not much, and that is deliberate. The constraint is what stops the scope drifting back to the full product.

Two rules keep it honest.

Build the spine end to end before building anything well. A rough version of the whole path beats a polished version of the first third. You cannot learn anything from a beautiful signup flow that leads to a screen you did not finish, and this is the single most common way MVP timelines slip: the team builds in the order the screens appear rather than in the order that produces a walkable path.

Manual is a legitimate implementation. If your product concept involves matching, curation, moderation or scheduling, doing it by hand behind the interface is a valid MVP. The user cannot tell, and you learn whether they want the outcome before you spend six weeks automating a process nobody wanted. Automate in version two, once you have watched yourself do it forty times and know what the rules are.

This is also where the temptation to over-engineer is strongest, and where a senior team earns its cost, mostly by declining to build things. The discipline of an MVP is almost entirely subtraction.

Weeks six and seven: instrument it before you launch

This is the step that gets skipped, and skipping it is what turns an MVP into an expensive opinion.

Go back to the falsifiable sentence. It names an observable behaviour. Before launch, make sure you can observe it, which means, concretely:

• Event tracking on the spine. Every step of the path, so you can see exactly where people stop. "They did not convert" is not a finding; "sixty percent left on the service-setup screen" is.
• A cohort view by signup week. Aggregate numbers hide the only thing that matters, which is whether people who joined this week behave differently from people who joined last week after you changed something.
• One qualitative channel. A short in-app prompt, a scheduled call, anything that gets you sentences rather than counts. Numbers tell you where users stopped; only people tell you why.
• A way to contact users individually. Twenty conversations with real users beats any dashboard at this stage, and you cannot have them if you did not collect the means.

Two weeks sounds generous for this. It is not, because instrumenting properly usually surfaces gaps in the spine you did not notice while building it: the step with no clear success state, the flow that silently dead-ends. Better found now.

Week eight: launch small and deliberately

Launch to a specific, reachable group who have the problem, not to whoever happens to see a post. Fifty of the right people will teach you more than a thousand of the wrong ones, and a wide launch to an unqualified audience produces a low conversion number that means nothing at all, since you cannot tell whether the product failed or the audience was never right.

Then hold the scope still for two full weeks and watch. The instinct to start shipping fixes on day three is strong and it is wrong: changing the product while gathering the first signal means you learn nothing clean about either version.

You are looking for the answer to the falsifiable sentence. Not "do people like it": people are polite. Did the specific group do the specific thing?

The five things almost every MVP scope should lose

From the scoping conversations we have run, the same five items come up nearly every time and almost never earn their place:

• Admin panels. You have a database and someone who can query it. Build the admin tooling when the person needing it is not you.
• Settings and preferences. Every toggle is a decision you are asking users to make and a branch you are committing to support. Pick sensible defaults and ship one path.
• Onboarding tours. If the spine needs a tour, the spine is wrong. Fix the product rather than narrating it.
• Full account management. Password reset, yes. Team invitations, role hierarchies, billing tiers and seat management, only if the assumption you are testing is specifically about teams.
• The second platform. Web and native at MVP stage doubles the surface area to prove one thing. Pick where your users already are. When native is the right first move, mobile app development is a first-class MVP path, not a version-two consideration, but it is a choice, not a default.

What we never cut

Three things stay in every scope, however tight, because removing them costs more than they save.

Authentication done properly. Not elaborate, properly. Retrofitting a real account system onto a product that launched with a shortcut means migrating every user and every record you have accumulated.

A coherent data model. The MVP's schema is the one your product keeps. Almost nobody rewrites it, because by the time it hurts there is production data in it. An afternoon of care here is worth months later.

Deployability. You must be able to ship a fix in minutes. During the two weeks after launch you will need to, and a deployment process that requires a careful hour turns a small fix into a decision about whether it is worth the risk.

The question to ask before you start

Whoever builds your MVP, us, another team, or you — ask them this before any code is written: when this is finished, what will we know that we do not know today?

If the answer is a list of features, the scope is wrong and it is not too late to fix it. If the answer is a specific thing you will have learned about specific people, you are building the right thing.

It is the same question we ask ourselves at the start of every MVP build. Products like the Habit Tracker and AI Life Coach started as a narrow bet about one behaviour, proved out, and grew from there, which is the only order that reliably works.