Start with one question, not a feature list
An MVP exists to answer a question you cannot answer by talking. Will people use this to do the task? Will they come back? Will they pay? Pick one. A first release that tries to answer three questions at once usually answers none, because every feature competes for the same weeks.
Then name the person and the task. Who opens the app, what do they have in hand, what do they want to be true ten minutes later? Writing this in two sentences does more for scope than any backlog tool. If you cannot name the person, the scope is not ready.
Sort every feature by what it tests
Put each proposed feature in one of three groups. Must: the question cannot be answered without it. Should: it makes the answer cleaner or the test fairer. Later: a good idea that does not change the answer. Only the first group is the MVP. The other two groups are not lost; they are the plan for the second release, written down on the first day.
A common surprise is how small the must group is. Sign-up, password reset, settings, an admin panel and a second platform often land in should or later. Many first releases run on one platform, use a shared link instead of accounts, and let a person do one step by hand behind the scenes. That is what a well-cut scope looks like.
Decide what “it worked” means before you build
Choose the signal in advance: a number, a behaviour, a sentence a user says. “Ten of the thirty people we invited finished the task without help” is a scope statement, because it tells you which parts of the product have to be solid and which can stay rough. Without it the release date slides, since nothing tells you when to stop.
The same signal protects the team after launch. When the result comes in, the conversation is about the question you set out to answer, not about the features someone wishes had been included.
Write the scope on one page, and date it
Goal, person, task, the must list, the not-now list, the success signal and the date you will look at the result. One page, dated. Scope will change while you build; that is normal. A change to a dated page is visible, while a change to a verbal agreement is not.
That page is also what a studio needs to quote the work. ECHO sends a written quote after a first conversation, and that conversation is mostly this page, written together; the services page shows how a project runs from there. A first release that answers one question is the kind of product we described in Why Useful Beats Impressive.