How to Scope an MVP in 6 Steps

Most first builds do not fail on the idea. They fail on scope. Nine months in, the budget is gone, the team is still three features away from the version it promised itself, and no customer has used any of it.

Scoping an MVP is the work that prevents that, and it is a set of decisions rather than a set of techniques. Who are the first users? What goes in the first few weeks? What gets deliberately left out? When are you allowed to call it launched? This guide walks through those decisions in six steps, in the order you have to make them.

MVP is jargon, and jargon hides things. The idea underneath is small: the first thing you can give the very first set of users you want to reach, to find out whether you can deliver them any value at all. That is the entire definition. Every scoping decision below follows from it. For a founder or a CTO about to commission a first build, what this exercise should produce is a spec short enough to build in weeks and specific enough for someone to quote.

Step 1: talk to a few users before you write any code

Before anyone opens an editor, some understanding of the problem is worth having. That does not mean three years of research, or a decade spent inside the industry first. It means conversations, and not many of them.

1. Name the people who have the problem. Write five real names down: not a persona, not a market segment. With an empty list, the rest of this exercise has nothing to anchor to.
2. Ask about the problem, not about your product. What they do today, and what it costs them, tells you what the first version has to beat. Their view of your idea tells you far less.
3. Check whether you are your own user. Being your own user gives you the fastest feedback loop available, because day to day you can tell whether the thing works for you.
4. Question a mysterious audience. Founders often ask how to get their first users, and it is an odd question. You picked a problem because you knew somebody had it. That person is the first user. If you cannot say who they are, it is worth pausing before anything gets built.

None of this is a substitute for building. It only keeps the first build aimed at a person instead of a market.

Step 2: write down what the pre-launch phase is for

A pre-launch startup has four jobs, in this order: launch quickly, get initial customers, talk to those customers and gather feedback, then iterate. Anything else competing for the next three weeks is optional. Most of it is a way to put off the first job.

More teams stumble on the third job than on the other three combined. Founders carry a finished product around in their heads, which makes feedback on the rough version feel pointless: of course it does not work yet, since the real thing needs a year and a team. That logic runs backwards. The version in your head is a hypothesis, and the rough version is how you test it. Keep the vision, but hold it loosely and let the feedback move it.

Iterating is not pivoting, and the difference deserves precision. Picture a screwdriver that does not turn screws. The mechanic still needs to turn screws, so neither the mechanic nor the screw is the problem. Looking for other uses for a broken screwdriver (cooking, maybe, or cleaning) is how teams end up solving nothing for nobody. Keep a tight grip on the problem and on the customer, a loose one on the solution, and fix the tool. To carry those conversations into the build, turn them into user stories instead of a feature list.

Step 3: cut the scope until the build takes weeks, not months

Usually the right answer is a lean MVP. A lean MVP has three properties. It is very fast to build: weeks, not months. Its functionality is very limited. Rather than appealing to everyone you eventually want, it appeals to a small set of users.

Run the feature list through those three as a filter. A feature either survives a few weeks of build time for a handful of named users or moves to a later list. Software is not required, either. Plenty of first versions are a landing page and a spreadsheet, with the founders doing by hand what the product will eventually automate.

What makes the cutting bearable is remembering what the MVP is: a base to iterate from. It is not the company. Nor is it the vision, and there is nothing special about it in any way. Your vision should cover everyone, while your MVP should cover very few.

When the MVP has to be heavy

A small group of businesses cannot ship in three weeks, and pretending they can wastes a quarter. Significant regulation is the common case: insurance, banking, and anything that must clear a regulatory body before it can touch a customer. Hardtech is another, because you cannot build a rocket in a fortnight. Biotech belongs here too, since the timeline belongs to the science, and so do moonshots generally.

Even in that situation, the MVP is not a year of silent building. It starts as a simple website explaining what you do. That takes days rather than weeks, and it gives everyone you talk to something concrete to refer back to while the real thing is in progress.

Step 4: benchmark your scope against first versions that worked

The quickest check on whether your spec is still too big is a comparison with what some very successful products shipped on day one.

Airbnb's early landing page, from 2008, had no payments whatsoever. Once you found a place to stay, you paid the host in person. Without a map view, you could not see where in the city a listing sat. Whoever wrote the code worked part-time. Each of those gaps would stop a feature review today, yet none of them kept the product from being useful to the first guests.

Stripe was not called Stripe. Its name was /dev/payments, which nobody was ever going to remember, and it launched with no bank deals and almost no features. Wanting to use it meant the founders came to your office and integrated it for you. That was half desperation for any user at all and half the best way to find bugs before customers did.

Twitch began as Justin.tv, an online reality show with exactly one channel. Either you followed one person's life or you left the site. The video resolution was low enough that faces were hard to make out. As for video games, there were none, unless somebody in the apartment happened to be playing one.

These teams were not careless. The pattern is that each first version had an obvious, embarrassing hole in it, shipped anyway, and used whatever came back to decide what to build next.

Step 5: treat launch as your first customer, not your press coverage

Founders watch large companies announce products and quietly take that as the model for their own launch. Keep the two words apart. A launch is the day any customer uses the thing, whereas a press launch is coverage, buzz, and a date somebody on the team is nervous about.

Ask a room full of people which day Google launched. Or Facebook. Or Twitter. Nobody knows, including the people who used all three that year. Launches are not the milestone they look like from outside, so push the press one back and pull the first customer forward.

Beyond timing, there is a practical reason. Customers are far easier to learn from when they have something to use. Talk to one all day and you can still not know whether your solution fixes their problem, since they are reacting to a description. Once the product is in their hands, a wrong answer arrives immediately. For the same reason, time spent on a polished pitch deck is worth less than time spent on anything a customer can actually open.

Step 6: time box the spec, write it down, then cut it

Three habits stop a scope from growing back. They sound obvious, yet most teams skip at least one.

1. Time box the spec. Choose the launch date first, and only then ask what can be built by that date. With a three-week box, the spec can hold only things that fit in three weeks, which ends the argument over whether a feature is important. It fits, or it waits.
2. Write the spec down. This is the one that gets skipped. An unwritten spec changes silently: a user says they would never use that, or an investor says it could never be a company, and the plan quietly shifts. Written down, you can at least see that you are changing it, and that the three-week plan has become a three-month one.
3. Cut the spec. Roughly a week into a three-week sprint, you will know you overcommitted. Start with the things that clearly do not matter. When those run out, cut things that do. Putting anything into the world is worth more than any single feature on the list.

That last trade is worth making because of momentum. When something is live, keeping it moving is close to automatic, since real usage produces the next decision. With nothing live, delay has no visible cost and tends to repeat. A written, time-boxed spec is also what makes the build quotable. That matters if the work goes to a contractor or a new hire: our guide to writing a software project brief explains how to turn this list into something a developer can price.

Mistakes that turn a three-week MVP into a three-month one

• Building for users you cannot name. When a product is aimed at a mysterious audience, there is no one to hand the first version to, and that is usually where the project stalls.
• Dismissing feedback on the rough version. Telling yourself it cannot work yet because it is not the full product shields the plan from the only information that would improve it.
• Pivoting when you should iterate. Searching for some other problem your product might solve keeps the broken part and discards the two things you got right.
• Waiting for the press launch. Your first customer needs no announcement. The announcement is worth more later anyway.
• Keeping the spec in your head. Scope creep stays invisible until it is written down, and by then the deadline has moved twice.
• Falling in love with the MVP. None of the products above ended up resembling their first version. Treat it as step one, not as the thing you are defending.

Ship the small version, keep the vision

The sequence is short. Talk to a few people who have the problem, and write down what the pre-launch phase is for. Cut the build to weeks, set your scope against first versions that shipped with obvious holes, count your first customer as the launch, then time box, write and cut the spec. Your vision stays in your head, where it is free to keep changing.

If the constraint is capacity rather than clarity, that is a different problem with a faster fix. Bring in a full-stack developer for the first build, scoped to the three-week spec you just wrote, and keep the feature list where it belongs.