Prioritise MVP features around one complete user outcome. Keep what makes that outcome possible, understandable and dependable enough to test. A request list is not a prioritised scope.
Map the journey
Describe the trigger, data input, main action and useful output. Connect each feature to a step. If it does not support the outcome, learning objective or a necessary protection, question its place in the first release.
Reduce variants intelligently
One workflow can become complex through many roles, formats and business cases. Reducing variants is often more coherent than removing an entire step. Supporting one import format can preserve a complete journey without implementing every connector.
Make tradeoffs explicit
For each request, record its contribution to the hypothesis, risk of omission, estimated effort and dependencies. Scores should expose reasoning rather than pretend to produce an indisputable mathematical answer. A security requirement should not lose to a visible feature merely because it receives fewer votes.
Document exclusions
State what is postponed and what would trigger reconsideration: observed usage, a confirmed integration or a recurring problem. This prevents deferred ideas from returning as fresh emergencies at every meeting.
Who makes the decision?
A product owner should arbitrate with business, design and engineering input. Record consequential decisions and their rationale. Priorities remain revisable when new evidence appears; a clear decision log makes that revision intentional rather than chaotic.
Prioritise exceptions as well as screens
For a fictional equipment-booking tool, the essential workflow includes availability, request, confirmation and return. Double booking or cancellation can break that workflow even when every planned screen exists. Detailed utilisation charts may be postponed without preventing a useful reservation.
For each feature, ask what happens if it is absent during the pilot. “The user cannot finish the task” or “records become inconsistent” suggests immediate importance. If an explicit manual operation is acceptable, name its owner and capacity limit rather than pretending the feature is unnecessary forever.
Use a practical review grid
- Value: which user outcome does this enable?
- Dependency: what other behaviour relies on it?
- Risk: which failure does it prevent?
- Alternative: can a manual step answer the experiment?
- Evidence: what observation makes it necessary now?
Numerical scoring can structure a discussion, but uncertain judgements do not become precise simply because they have numbers. Preserve the reasons behind each score. Revisit the grid after the pilot when observations replace assumptions, and keep an explicit deferred list to prevent scope from quietly expanding during implementation.
From this guide to your project
Product ↗
The experience connects your promise to the job your user needs to get done. We design that journey before adding more screens.
Tell us about your ideaExamples are educational and do not describe client results. Content prepared with AI assistance; see our editorial policy. Our method ↗