A minimum viable product is not a low-quality version of a large idea. It is the smallest useful release that can test whether the product solves an important problem for a defined group of users.
The hard part is deciding what not to build yet.
Begin with one user and one task
Describe the primary user in practical terms. Then complete this sentence:
When this person needs to achieve X, the app helps them complete Y with less delay, error or effort.
Examples might include a customer submitting and tracking a service request, a field team recording a completed visit, or a manager approving a purchase request.
A first release that tries to serve customers, administrators, suppliers and managers equally often becomes too broad to test well.
Map the current journey
Write down how the task happens today:
- What starts it?
- What information is needed?
- Where does that information come from?
- Who makes decisions?
- What causes delay or error?
- How does the user know the task is complete?
This reveals whether the problem needs an app, a simpler form, an automation or a change in process.
Define the product promise
Choose one measurable improvement, such as:
- submit a request in under three minutes;
- reduce manual re-entry of the same data;
- give customers a clear status without calling support;
- let a manager approve work from a mobile device; or
- create one reliable source of operational information.
The promise gives the team a way to judge every feature request.
Separate the core path from supporting features
The core path contains only the steps required to deliver the product promise. Everything else belongs in a later list until evidence shows it is necessary.
For example, the first version of a customer portal may need secure sign-in, a request form, document upload, status display and administrator updates. It may not need live chat, advanced dashboards, multiple languages, rewards or a native mobile app on day one.
Prioritise risk, not excitement
An MVP should test the assumptions most likely to make the product fail. Ask:
- Will the intended user adopt this workflow?
- Can we obtain the required data?
- Can the business respond quickly enough after a request is submitted?
- Does an integration provide the access and reliability we need?
- Will the process comply with security and privacy requirements?
- Does the improvement create enough value to justify further investment?
Build enough to answer these questions honestly.
Decide what can remain manual
Some behind-the-scenes steps can be performed manually during an early release. This is acceptable when it helps validate demand without creating unacceptable risk or an unsustainable workload.
The user experience should still be reliable. Do not pretend a manual process is automated, and make sure someone owns every handoff.
Include operational requirements
A usable MVP needs more than visible screens. Plan for:
- authentication and permissions;
- data validation;
- error messages and recovery;
- backups or export where appropriate;
- basic logs;
- accessibility;
- privacy and data retention;
- support ownership; and
- a way to measure use.
These are not decorative extras. They make the product safe enough to learn from.
Prototype before full development
A clickable prototype can test navigation, language and task order before engineering begins. Put it in front of representative users and ask them to complete a realistic scenario without coaching.
Observe where they hesitate, what they expect to happen and which information they cannot find. Change the flow before investing in the full build.
Plan the first release as an experiment
Define:
- who will use it;
- how many users are needed;
- how long the pilot will run;
- which measures will be reviewed;
- how feedback will be collected;
- what would justify expanding; and
- what would trigger a redesign or stop decision.
This prevents the MVP from becoming a permanent half-finished product with no decision point.
Use a simple feature test
A feature belongs in the first release when the answer to most of these questions is yes:
- Is it required for the core user to complete the main task?
- Does it test a major assumption?
- Is it needed for security, privacy, accessibility or reliable operation?
- Would its absence make the learning misleading?
- Can the team support it after launch?
When the answer is no, place it on the roadmap with the evidence that would cause it to move forward.
A focused MVP creates better evidence
The first release should be narrow enough to understand. When too many audiences, workflows and features launch together, it becomes difficult to know what caused success or failure.
One useful task, delivered reliably to the right user, gives the business a stronger foundation for the next investment decision.