Start with the assumption you need to test
An MVP is a reduced version of a product that can be used to test a business or behavioral assumption. Its scope is set by the question it needs to answer. A site with many screens can still leave the central question open; a single complete flow can yield more useful information.
For example, in a system for managing service requests, the initial question might be whether a small team can take in, prioritize and close a request without going back to the spreadsheet. This is an illustrative scenario. It helps you decide which capabilities are needed and what can wait, without assuming the whole product is already defined.
Choose a user and a flow that reaches an outcome
Describe a specific person: what they do today, where they get stuck and what the desired outcome would be. Then map the flow from start to finish. Sign-up, a welcome screen and a dashboard are not outcomes in themselves; closing a request or completing an order are outcomes you can test.
Choose the important failure cases as well. If a user enters invalid details, who explains how to fix them? If the external service is unavailable, what is saved and what is safe to retry? Handling these cases can be part of the first version even when the design is simple.
Write down what is in and what waits
Split the requirements into three groups: essential to completing the flow, essential to operating responsibly, and improvements that can be tested later. Permissions or backups are not necessarily embellishments for a later version. On the other hand, exporting to every format and tailoring to every type of customer can sit outside the initial scope.
- One user or a defined group, rather than every possible type of user.
- A core flow with a clear start and end, including meaningful error messages.
- A list of deferred capabilities and the reason each one was deferred.
- Acceptance criteria that can be demonstrated on safe data.
Decide how the next decision will be made
Define what you will collect during the experiment: task completion, points where people need help, reasons for drop-off and qualitative feedback. There is no need to start with a complex tracking tool. Conversations and documented observation can be useful, and any collection of personal data must be handled with appropriate privacy and consent.
Decide in advance what will lead to continuing and what will require a change. If everyone reaches the last screen but no one understands the result, adding more screens will not solve the problem. The purpose of measurement is to support a product decision, not just to produce a nice chart.
Leave a foundation others can build on
Before handover, make sure someone else knows how to run the product, deploy it and understand where data is stored. Document limitations, decisions and outstanding debt. A first version can be small, yet it still needs to be clear to the team that will keep developing it.
The recommended first step is a one-page document: user, problem, flow, boundaries and how the outcome will be tested. From it you can derive a specification and a focused development path, without committing up front to every idea that comes up along the way.