The scoping question is what to remove
Every list of features for a first version is a list of things somebody would like. The useful exercise runs the other way: what can come out and still leave something a customer would use. Teams that build the whole list launch late, learn nothing until the budget is spent, and find that the feature they argued about for three weeks gets used by nobody. MVP scope is a set of deletions, and the discipline to make them is worth more than any estimate.
One user, one job
Pick a single kind of user and a single thing they are trying to finish, then build the shortest path between the two. The moment you add a second role, you inherit permissions, an admin view, and a set of decisions about what each role can see, which multiplies the work before anyone has used the thing. Most first versions that never launched were trying to serve three audiences at once. Serve one completely. The second is easier to add once you know the first was right.
What gets built too early
A predictable list shows up in nearly every over-scoped first version: fine-grained roles and permissions, a reporting dashboard, a settings page full of options, a notification system, integrations with tools the customer might use, and an architecture chosen for a scale that is years away. Each is defensible on its own. Together they consume the whole budget before a customer has touched anything. If a feature exists because of a user you do not have yet, it belongs in the next version.
What you cannot cut
Minimal does not mean unfinished. Anything touching money, identity or customer data has to be right on day one, because those are the failures people do not forgive and do not report politely. Log in has to be secure. Data has to be correct and recoverable. The core action has to work every time, on a phone, at the speed people expect. Cut breadth, never the quality of the narrow thing you built. A small product that works beats a broad one that mostly does.
Assume the MVP becomes the product
Teams tell themselves they will rewrite it properly once the idea proves out. That rewrite rarely happens, because by then there are customers, a roadmap and a reason not to stop. Plan for the first version to still be running in three years. That does not mean building for scale you do not have. It means naming things carefully, keeping the data model clean, and avoiding the shortcuts that are cheap now and structural later. The difference costs little at the start and a great deal afterwards.
Do it by hand before you build it
Plenty of what looks like a feature is a process a person can run for the first fifty customers. Onboarding, approvals, matching, reporting, anything that happens a few times a day. Run it manually, watch how it behaves, then automate the version you learned rather than the version you imagined. This is the cheapest research available and it routinely removes entire modules from the plan, because the manual step turns out to be either unnecessary or nothing like what was specified.
Decide what you are measuring before you launch
A first version exists to answer a question. Write the question down and the number that answers it: do people finish the core action, do they come back next week, does this cut the hours the process currently takes. Without that, launch produces opinions, and the team argues about the next version from taste. With it, the roadmap writes itself from what people did rather than what they said in a call.
Give it a deadline that forces the choices
Set a launch date close enough that the scope has to shrink to meet it, then hold the date and let the features move. Around three months is the point where teams stay honest; past that, the plan absorbs everything anyone thought of and the launch stops being real. A short deadline is not about speed for its own sake. It is the mechanism that makes people decide what actually matters, which is the entire job of scoping.
Written by
Idennex
Strategy-first agency, Istanbul