Choose a question the first release can answer
A minimum viable product becomes easier to plan when the team agrees on what it needs to learn. Perhaps the question is whether independent tutors can manage lesson requests through one workspace. That is specific enough to guide feature choices and broad enough to test a useful experience.
Write the question, the intended user, and the main task in plain language. Then record the assumptions behind the idea. GOV.UK's user research guidance recommends treating suggestions unsupported by user evidence as assumptions to investigate. This is a helpful discipline for any early product. Read the user needs guidance.
Map one complete journey
For the tutor example, the journey could be: create availability, receive a request, accept a time, and confirm the lesson. Sketch the steps before compiling a feature list. A calendar full of settings contributes little if the student cannot tell whether a booking succeeded.
Include the operating side of that journey. Someone must be able to correct an availability error, respond to a cancellation, and help a user who gets stuck. These tasks may use a simple internal workflow at first, but they need an owner and a workable process. An MVP should let a user finish its core task with clear expectations.
Sort features by necessity and uncertainty
Use three questions to review each proposed feature: Does the core journey fail without it? Does it help test a central assumption? Is there a simpler way to support the same outcome? Record the reason for each decision so the team can revisit it when evidence changes.
For our hypothetical booking product, accepting a lesson request belongs near the top. A custom profile theme may wait. Automated reminders might be useful, but the first pilot could use a clearly managed manual reminder process if its size makes that practical. Estimate that operational work as carefully as development work.
- Build now: steps required to complete and support the main task.
- Investigate first: expensive features whose value or feasibility remains unclear.
- Consider later: improvements that add convenience after the basic journey works.
Keep essential quality inside the scope
Reducing the feature list should not remove the safeguards needed for the chosen use case. If people have private accounts, account access and data boundaries are part of the product. If the interface accepts a booking, it needs a clear confirmation and an understandable recovery path when something fails.
Write acceptance criteria around observable behavior. For example: after accepting a lesson, the tutor sees its confirmed time and the student receives the agreed confirmation. Include realistic edge cases, such as a time slot becoming unavailable during the request. Review those criteria with design and engineering before implementation.
Decide how you will evaluate the release
Choose a small set of questions that connect directly to the goal. Can participants complete the booking? Where do they ask for help? Do they return when they need another lesson? Combine observed behavior with conversations about what happened. A sign-up count alone cannot explain whether the core task was useful.
Set a review point and decide who will collect the evidence. A pilot with limited participation may reveal usability problems while leaving commercial demand uncertain. Record those limits so the next decision reflects what the release actually demonstrated.
Reorder the backlog as you learn
Treat the remaining feature list as a set of options. The Scrum Guide describes the product backlog as an ordered list that evolves as the product develops. You can use that principle without adopting every part of Scrum. Read the Product Backlog section.
After each review, promote the work that solves a demonstrated problem, revise weak assumptions, and remove ideas that no longer serve the goal. A useful first release gives the team both a working product and better reasons for its next investment.