How to launch a product: from idea to MVP / Decide what to build
How to scope an MVP
Scope is the most important decision in your launch, and it is where most MVPs go wrong. The fix is to scope around one question, not your whole roadmap. Define the single core action that tests your riskiest assumption, build only what is needed for it, and let everything else wait.
Published July 27, 2026. Editorial.
Key takeaways
- Scope around the riskiest assumption, not the full vision. One question, not one roadmap.
- Define the single core action a user must complete, then build only what supports it.
- Everything that is not needed to test the assumption goes on a later list, not in version one.
- A tight scope is the founder's job. If you cannot cut, the team cannot release fast.
An MVP fails in the scoping far more often than in the building. A scope with too many features guarantees a slow, expensive launch no matter how good the team is. A tight scope makes the build feel calm. Scoping is the most useful hour you will spend on the whole project, so it is worth doing with care.
Start from the riskiest assumption
Do not start from the vision and trim. Start from the one assumption that scares you most, the assumption that, if wrong, ends the product. Your MVP exists to test that assumption. Everything you build should serve that test, and everything that does not serve it is out of scope by default. This is the same idea that runs through the main guide and what is an MVP: an MVP is an experiment aimed at one question.
If you have done the work in how to validate a product idea, you already know which assumption is riskiest and least tested. That is your target.
Define the single core action
Every product has one core action that delivers its main value. On a marketplace it might be completing a first transaction. On a productivity tool it might be finishing the main task the tool exists to make easier. Name that single action for your product.
Now scope becomes a clear question: what is the least a user needs to complete that core action and get value from it? That is your MVP. Onboarding beyond what the core action requires can wait. Settings, integrations, unusual cases, admin panels, and the second and third use cases can all wait. If a feature is not needed for the user to complete the core action, it is not in the first version.
Cut firmly, and put the rest on a list
The reason MVPs grow too large is that every feature has a reason to exist and a supporter who wants it. Cutting feels risky. So make cutting safe: keep a clear "later" list. Nothing is being deleted, it is being scheduled for later. This turns every scoping argument from "in or out" into "now or next," which is a much easier conversation.
Be strict. For each feature, ask whether the core action works without it. If it does, the feature is later, not now. Most features fail this test, which is uncomfortable and correct. The how to prioritize features page gives you a repeatable way to run this when the list is long and opinions differ.
Handle the "but users will expect it" objection
Someone will argue that users expect a feature, so it has to be in the first release. Sometimes true, usually not. Users expect the core action to work well. They forgive a missing settings page or a manual step far more than they forgive a core experience that is broken or confusing. When in doubt, protect the quality of the core action and cut other features. A narrow product that does one thing well beats a wide product that does everything poorly.
Fix the outcome, keep the details flexible
Write down the outcome you want and the core action clearly. Keep the exact feature details flexible, because building always reveals that some of your first plan was wrong. A good scope is firm on direction and flexible on detail. This is why rigid, fully-specified scopes tend to cause problems: they fix guesses in place that discovery will prove wrong. If you are working with an outside team, a full product build is built to take responsibility for this kind of scoped first version from start to finish.
The founder's job
Cutting scope is the founder's job, and it is a real one. A team cannot release fast against a scope that keeps growing. Every feature you refuse to add now is speed you give the team. As we put it in the founder's job is to remove ambiguity, a clear scope is one of the clearest ways you make the team faster. Do this well and the build is the easy part. Do it badly and no amount of engineering can fix the launch. Then return to the main guide for the next steps.
Best for
- An MVP scoped around a single riskiest assumption and one core action
- A firm outcome with flexible feature details, so the team can adjust as it learns
- A clear "later" list that schedules features for later instead of deleting them
Avoid if
- Do not scope your whole roadmap into version one: that is a full product, not an MVP
- Do not fix every detail up front, because discovery will prove part of the plan wrong
- Do not keep a feature just because someone expects it, if the core action works without it
Check before you decide
- Confirm you can name the single core action a user must complete to get value
- Confirm every feature in scope is needed to test the riskiest assumption
- Confirm you have a written definition of done both sides judge the work against
Common questions
How do I decide what goes in an MVP and what does not?
Name your riskiest assumption and the single core action that tests it. Build only what a user needs to complete that action and get value. Everything else goes on a later list. If the core action works without a feature, that feature is not in version one.
How do I stop my MVP scope from growing?
Keep a clear later list so cutting feels like scheduling for later, not deleting. Turn every scoping argument from in or out into now or next. For each feature, ask whether the core action works without it, and if it does, move it to later. Cutting scope is the founder's job.
What if users expect a feature I want to cut?
Users expect the core action to work well. They forgive a missing settings page or a manual step far more than a broken core experience. When unsure, protect the quality of the core action and cut other features. A narrow product done well beats a wide one done poorly.
What is scope in the context of an MVP?
Scope is the set of features and work included in the first version of a product. For an MVP, scope should be defined by the single core action a user needs to complete to get value and test the riskiest assumption, not by the full list of things the product will eventually do. Everything not required for that core action belongs on a later list.
How do I write down the scope of an MVP?
Name the riskiest assumption you are testing, then define the single core action that delivers the product's main value and tests that assumption. List only what a user needs to complete that action. Write the outcome and the core action clearly, but keep the exact feature details flexible, since building usually reveals that part of the first plan was wrong.
How long does scoping an MVP take?
Scoping itself is a short exercise, often a matter of hours or days, not weeks. It is also the most useful time spent on the whole project, because a tight scope makes everything after it faster and cheaper. Teams that spend weeks scoping are usually trying to plan around every feature instead of committing to the one riskiest assumption.
What happens if I skip scoping and just start building?
Skipping scoping usually means the team builds whatever features come up during development, which is how an MVP with too many features happens by accident. Without a defined core action and riskiest assumption, every feature feels equally important, cutting becomes political, and the build stretches toward a full product before anyone tested whether the idea deserved one.
How does MVP scope differ from a full product roadmap?
A full product roadmap lists everything the product will eventually do, ordered over time. MVP scope is narrower and different in kind: it is the single core action needed to test one riskiest assumption right now. A roadmap plans for the final product. MVP scope plans for the one experiment that tells you whether that final product is worth building.
How a build like this runs
Related reading
You cannot measure engineers by how much they produce
Lines of code, tickets closed, and hours logged all measure activity rather than progress. Here is how we think about engineering output without numbers that only look good.
Knowing what to build is now the most important decision
AI made writing software cheap. That moved the hard part earlier, to deciding what deserves to be built and having the discipline to cut the rest.
More in Decide what to build
How to validate a product idea before you build
The cheapest MVP is the one you never had to build. Before you commit engineers, you can test most of your assumptions with conversations, a landing page, a clickable prototype, or a service you run by hand without the user seeing it. Validation is how you find out the idea is wrong while it is still cheap to be wrong.
How to prioritize features for a first version
When the feature list is long and everyone involved wants their idea in version one, prioritization gets political. The fix is a shared rule that ranks features by how much they serve the one thing your MVP tests, not by who argues hardest. Make the rule explicit and the arguments get easier.