The wish list keeps growing while the budget stays the same. It is tempting to remove individual features until the numbers fit. After launch, you may discover that users can start a task but cannot finish it, or staff must manually repair every case.
A first release should handle a smaller amount of work completely. That is a stronger basis for prioritisation than labelling ideas “important” and “less important”.
Follow one task from beginning to end
Consider an event booking service. A participant chooses a session, enters their details, receives confirmation and can cancel. A staff member can see the booking list and handle a fully booked session.
Sophisticated event recommendations may be able to wait. A clear message when a booking fails probably cannot: without it, people do not know whether they have a place. Judge a feature by its role in the whole journey.
Sort the scope into three groups
- What users need to complete the core task.
- What staff need to operate and support the service safely.
- Improvements that can follow once you understand actual use.
For each deferred feature, describe how work will happen without it. If the answer is “someone will do it manually”, estimate the effort and assign responsibility. Work does not disappear just because it is absent from the software.
Check the cost of adding more later
Ask which early decisions could make the next phase difficult. You do not need to build everything now, but it helps to understand the basic data model and how other systems will connect.
Finish with a short statement of who can complete which task, under what conditions, in the first release. Add the exceptions and deferred items. This is useful for pricing and acceptance. The label “MVP” alone leaves too much room for different interpretations of what will actually be delivered.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database