How to Scope an MVP: What to Build First and What to Skip
Decide your MVP scope by picking one user, one job and one measurable outcome, then cut everything that does not serve them.
The founding team has a forty-item feature list and a launch date three months away. Every feature feels essential because a prospect once mentioned it. Six months later the product is still not live, the runway is shorter, and nobody has learned whether customers will actually use the core workflow.
Most MVPs fail not because they are too small but because they try to serve too many users and edge cases at once. The team spends its effort on login options, permission matrices and admin screens while the one workflow that creates value gets less attention than it needs.
How long should it take to build an MVP?
It depends on the problem, but if scoping produces a plan of many months, the scope is probably too broad. Aim for something a few real users can use for the core job within weeks, then extend.
Should the MVP include payments?
If willingness to pay is the main thing you need to prove, yes, even if it is a simple payment link or a manual invoice. A user who pays tells you far more than one who only says the product looks interesting.
What if a big prospect insists on a feature outside scope?
Ask what job the feature serves and whether a manual workaround would do for now. If the deal is truly strategic, add it consciously and remove something else so the scope does not keep growing.