How to define and
prioritise your MVP

The hardest part of building a new app is often deciding what belongs in the first version.

Every feature has a reason to exist. Customers want convenience, the team wants automation, and investors may want to see a bigger vision. Without clear boundaries, a first release can become an attempt to build the entire business at once.

A minimum viable product, or MVP, is a usable version of the product that solves a specific problem and helps you test the assumptions behind the business. Defining it means choosing who it serves, what they must be able to accomplish, and what you need to learn from their behaviour.

This guide turns that into a practical scope, using an illustrative booking app throughout. The example is not a client result.

Start with one customer and one important problem

“An app for sports coaching” describes a category. It does not tell a development team what to build.

Parents booking local football coaching struggle to find available sessions and confirm a place without exchanging messages with the organiser.

That statement identifies a user, a task and a source of friction. It gives you something to investigate before committing to features.

Speak to prospective users about the last time they completed the task. Ask how they did it, where they got stuck and what happened afterwards. Existing spreadsheets, messages and workarounds can reveal more than a list of hypothetical feature requests.

The GOV.UK Service Manual’s guidance on understanding user needs makes a useful distinction: investigate the problem people need to solve before deciding on the solution.

Write down your starting hypothesis:

For [specific user], we will make it easier to [complete a task], replacing [current workaround]. We will know it helps when [observable outcome].

If the statement contains several unrelated audiences or outcomes, narrow the first release.

Decide what you need the MVP to prove

A product can work technically without proving that anyone wants it. Separate those questions before choosing the scope.

For the booking example, the important assumptions might be:

• Parents will book through the product without needing a conversation first.
• Organisers will keep session availability accurate.
• A confirmed booking will require less administrative work than the current process.
• Organisers will pay for the service if it produces enough value.

Each assumption needs a different kind of evidence. A completed booking tests part of the customer journey. It does not prove willingness to pay or long-term retention.

Choose the most consequential uncertainty for the first release. If the biggest risk is whether organisers will adopt the process, building an elaborate parent-facing app will not resolve it alone.

Choose the right test before building a live product

You may be able to answer an early question with something smaller than an MVP.

A waiting-list signup is evidence of interest, not proof that someone will pay. A prototype can reveal usability problems without demonstrating that the underlying technology works.

The GOV.UK guidance on prototyping recommends choosing a prototype appropriate to what you need to learn. Apply the same principle to your development spend: build enough to answer the next important question.

Map a complete user journey

An MVP should let someone finish a meaningful task. A collection of partly implemented features makes behaviour difficult to interpret.

For the coaching app, the parent journey could be:

1. Find an appropriate session.
2. Check the date, location, availability and price.
3. Provide the necessary booking details.
4. Complete payment if prepayment is required.
5. Receive a clear confirmation and know how to get help.

There is also an organiser journey: create sessions, manage capacity, see bookings and handle changes. You might operate those organiser tasks through a basic admin interface during the pilot. They still need an owner and a reliable process. Omitting them from the design does not remove the work.

Start with one location, one booking type or a small group of organisers if that makes the first test manageable.

Prioritise features with clear rules

The MoSCoW method groups requirements into Must Have, Should Have, Could Have and Won’t Have this time. Its value comes from agreeing what qualifies for each category.

• Must Have: Would the core task fail, or the release be unacceptable, without it?
• Should Have: Is it important, but manageable through a temporary workaround?
• Could Have: Would it improve the experience without changing the pilot’s essential value?
• Won’t Have this time: Are we explicitly excluding it from this release?

For the illustrative booking app, the decisions might look like this:

Priorities depend on context. Cancellation automation could become essential at higher volumes. Accessibility, appropriate security and reliable data handling belong in the release criteria wherever needed, even when customers never request them as features.

Consider effort, dependencies and uncertainty

Ask your development lead to review the proposed scope before treating it as a delivery commitment. A short feature label can hide substantial work. “Take payments” may involve confirmation, failed transactions, refunds and reconciliation. “Connect the calendar” may depend on access permissions and inconsistent external data.

Investigate a critical unknown early. A small technical experiment can establish whether an integration is feasible before the rest of the product depends on it.

Avoid making every decision through a numerical score. Scores can help compare discretionary features, but an essential access control cannot be traded away because a cosmetic improvement looks cheaper.

Set a measurable pilot goal

Define success before launch, while the team can still agree on what would count as useful evidence.

For example, a pilot might aim to have 20 participating families attempt a booking, with at least 15 completing it without staff assistance over four weeks. Those are illustrative targets, not industry benchmarks. Set your own thresholds using your audience, baseline and business model.

Measure the steps that explain the result:

• How many eligible participants started and completed the booking journey?
• Where did people stop or request help?
• How much staff time did each completed booking require?
• Did people return when they next needed the service?
• Would organisers continue using it at the proposed price?

Combine product events with interviews and support notes. Small pilots can reveal useful patterns, but they do not provide precise forecasts of a wider market. Agree what you will do if the evidence is weak: change the journey, narrow the audience, test the pricing or reconsider the problem.

Write a brief that controls the first release

Your MVP brief should be concise enough to use during everyday decisions. Include:

• The target user and problem.
• The assumption being tested.
• The complete journey in scope.
• Must Have requirements and explicit exclusions.
• Dependencies and unresolved questions.
• Acceptance criteria and operational responsibilities.
• Pilot participants, success measures and review date.
• The person responsible for approving scope changes.

Make acceptance criteria observable. For booking confirmation, specify that a successful booking records the correct session and participant, reduces capacity appropriately and gives the parent an unambiguous result. Decide how failures will be detected and handled.

When a new feature is proposed, ask what evidence makes it necessary now and what changes to accommodate it. It may replace another feature, require more time or belong in a later release.

Keep the build focused, even when AI makes development faster

AI can help teams explore designs, generate code and accelerate parts of delivery. It does not establish customer demand or remove the cost of operating extra features.

Every added feature still needs a coherent user experience, appropriate permissions, testing, support and maintenance. Faster implementation makes disciplined scope decisions more valuable: use the time saved to test assumptions and improve the core journey.

For the first release, choose technology based on the actual task. A mobile-friendly web product may be enough for some booking services. Other products need device capabilities or usage patterns that justify a mobile app. Make that decision during discovery.