Begin with the decision
Write the decision the release must help the team make. “People like the idea” is too vague. “A restaurant manager will publish an offer and receive a qualified booking without staff intervention” gives the product something testable. The decision becomes the filter for every proposed feature.
Choose one actor and one outcome
List the people in the system, then choose the first actor whose successful outcome creates the evidence you need. Map the shortest honest path from arrival to that outcome. Keep supporting roles only when the journey cannot work without them.
Separate the promise from the machinery
The user sees a promise; the team needs machinery to deliver it. Authentication, data, notifications, content, admin review, and support may be invisible but essential. Mark which parts can be manual during the first phase and which must be reliable in software.
Use four scope buckets
Put each item into: required for the core journey, required to operate safely, useful after evidence, or unrelated to the current decision. The first two buckets define the release. The third becomes a measured next step. The fourth is removed.
Write acceptance as behavior
Replace “build dashboard” with concrete behavior: who can see it, which data appears, how fresh it is, what happens with no data, and which action follows. Behavioral acceptance reveals missing decisions before they become rework.
Leave room to learn
Do not spend the full budget reaching launch. Reserve time for real-user friction, operational gaps, and the one assumption the release proves wrong. An MVP that cannot change after learning defeats its purpose.