Scoping
How to decide what not to build in an MVP
Use constraints to protect the core experience, make faster decisions, and give a first version a real chance to teach you something.
Most early product ideas can grow faster than a team can make decisions about them. Each requested feature sounds reasonable on its own. Together, they create a release that is harder to explain, slower to build, and less useful to learn from. The answer is not to become careless about ideas. It is to decide which ones belong to this release and which ones deserve to wait.
An MVP is not a promise to make a low-quality product. It is a commitment to make a small, complete experience. The work is deciding what “complete” means for one focused job, then defending that decision when the feature list starts to expand.
The cost of keeping everything
Every feature carries more than implementation time. It asks for a decision about the interface, the data, the edge cases, the language, and the support it will need later. It also makes the rest of the product harder to understand. A feature that is only slightly useful can still make the core path noticeably less clear.
This is why a roadmap is not a queue of equal requests. A first release needs a hierarchy. The primary job comes first. The details that let someone finish that job come next. Everything else should earn its place by proving that the experience fails without it.
Scope is not the list of everything a product could do. It is the set of choices that lets one person get a useful result now.
When a team feels uncomfortable cutting, it often means the product’s promise is still too broad. Return to the problem statement and name the single change a person should be able to make after using the product. That is the result the first version is responsible for.
Use a cut list
A cut list is a simple place to put good ideas that are not part of the current release. It does two helpful things: it keeps the team from repeatedly debating the same request, and it makes saying “not now” feel less like saying “never.”
For each item, write the user problem it addresses, the evidence behind it, and what would need to be true before it becomes important. This gives future work a better starting point than a vague backlog item. It also reveals patterns: several feature requests may be different attempts to solve the same missing need.
Questions to ask before a feature stays
- Does the primary user need this to finish the core job?
- What useful outcome disappears if it is removed?
- Can the need be handled manually for the first release?
- Will this make the product harder to explain or support?
The goal is not to make the cut list as long as possible. The goal is to make the release small enough that the team can learn where the product really earns its complexity.
Protect the core experience
Once you know the first version’s promise, design the smallest path that keeps it. A person should understand where to begin, make the key decision or input, and see a result that matters to them. The work around that path should support it, not compete with it.
That often means postponing customization, broad permissions, secondary workflows, reports, integrations, and automation. Those things can be valuable. They are simply different products until the core experience is working. A narrow release is easier to test because the team can see whether people are returning for the specific value it was meant to provide.
Make the tradeoffs visible to everyone involved. A clear “not in this version” list creates trust when it is connected to a real reason: protecting a date, reducing risk, making room for feedback, or keeping the main workflow understandable. Constraints create clarity when people can see what they are protecting.
Leave yourself room to learn
A focused MVP is a way to learn without creating unnecessary work. Keep the promise small, place good ideas on a cut list, and give the core experience enough attention to feel complete. You can always add more later; it is much harder to remove complexity after it becomes part of the product’s story.