Almost every first release we are asked to scope arrives with a feature list that describes the product in two years. The list is not wrong, it is just not a first release, and building it takes long enough that the market has moved by the time anyone can use it.
Name the one user and the one job
An MVP that serves three user types serves none of them well. Pick the single user whose problem you understand best and the single job they need done, and scope to that.
Everything else becomes a decision you get to make later with real information instead of now with a guess.
Ship the unglamorous parts
Authentication, billing, error states and a way to export your data are not features to cut. They are what makes the difference between a product and a prototype, and they are what a paying customer notices missing on day one.
The parts to cut are the second and third ways of doing something, the configuration options nobody has asked for, and the administrative interface you can replace with a database query for the first few months.
Instrument the activation path
Before launch, decide what the first moment of value is and measure how many people reach it. Sign-ups are a vanity number. The percentage of sign-ups who complete the job they came to do is the number that tells you whether to keep building.
Write down what you deferred
A visible list of what was deliberately left out, and the reason, prevents the same discussion happening every sprint and makes it obvious when a deferred item becomes urgent.
It also protects the team. Scope that is cut silently gets remembered as scope that was forgotten.
Working on something this touches on? Tell us about it — we are happy to talk it through whether or not it turns into a project.