MVP feature prioritisation starts with the smallest complete task a useful first release must support. It is not the process of choosing a few attractive screens from a larger product idea.

For a web app, the first release should let a defined user complete a meaningful action, preserve the result and let the business handle what happens next. Account access, error handling and operational ownership may be necessary even when they are not the features people notice in a demo.

This guide helps a small business or early product team define that release. It includes a first-release planning worksheet and an editable feature decision register.

Start with the user problem

Describe who has the problem, what they are trying to do and how they currently do it. Collect evidence before turning assumptions into mandatory product requirements.

A team might observe that requests are lost between messages, or that customers cannot identify the latest approved item. Those are concrete problems to investigate. “We need a platform” is not yet an explanation.

Speak to the people who do the task and the staff who support it. A useful understanding includes the conditions under which the current process works and the exceptions that cause difficulty.

GOV.UK's user-research guidance is a useful reference for distinguishing user needs from assumed solutions. It is written for public services, not as a requirement that every business adopt the same delivery process.

Choose one end-to-end task

Write a start and an observable finish. For a request-tracking app, a user submits a request, staff review it and the user can see the resulting status.

Identify the minimum information and decisions needed along that path. A screen for entering data is incomplete if there is no reliable way to find, review or act on the record.

The task should be meaningful to the intended user. Reducing the release to something technically small but practically unusable does not create a useful test.

If the product involves a client portal, use the portal planning guide to clarify the customer journey and access model before adding more dashboard components.

Name the uncertainty

Ask what you need to learn from the first release. Are you uncertain about the need, the workflow, user comprehension, an integration or whether the business can operate the service?

Different uncertainties need different tests. A prototype can help investigate an interaction, while an integration demonstration can answer a narrower technical question.

Do not build a full production system merely to test whether someone understands a proposed sequence. Conversely, a clickable screen cannot establish that a live workflow handles real accounts and data correctly.

The GOV.UK alpha guidance discusses using prototypes to explore risky assumptions. Use it as a reference for disciplined learning, not as proof that a prototype is a production release.

Define the first-release outcome

Write a concrete statement the team can evaluate. For example: “An authorised customer can submit a request, staff can assign it and the customer can identify its current status.”

Add acceptance conditions that explain what happens to the record and who can act on it. Avoid treating “the app works” as a shared definition.

Separate this product outcome from a business prediction. A first release may demonstrate a functioning workflow without proving a revenue forecast or productivity improvement.

If a commercial outcome matters, explain how evidence will be collected over time. Do not declare it validated simply because the application has been launched.

Group features by their purpose

For each proposed feature, record which part of the core journey it supports. Useful groups include completing the task, keeping records correct, controlling access, operating the service and improving convenience.

An essential background function may deserve priority even if it is not visible on the homepage. A clear record of a decision can matter more than another chart.

Some ideas will not connect to the chosen first-release outcome. Keep them in a later-ideas list until there is evidence for a separate journey.

This grouping makes the scope discussion more precise than a competition between stakeholders' favourite features.

Use a decision record, not a magic score

A scoring method can organise a discussion, but its inputs are estimates and judgments. A high total does not turn an uncertain benefit into a measured fact.

Record the user need, available evidence, expected value, uncertainty, dependencies and likely effort. Then make a release decision with a written reason.

A critical access or recovery requirement should not disappear because a cosmetic feature scores well on a simple formula. Dependencies and unacceptable failure modes can override the ranking.

The downloadable decision register includes illustrative rows. Replace them with your product's actual requirements rather than inheriting their priorities.

Separate essential from convenient

Ask whether the user can complete the agreed task without the feature. If the answer is yes, ask whether the remaining process is still understandable and operationally manageable.

A manually reviewed request can be a valid early workflow if the team has agreed to own that work. An unassigned request that nobody can find is not a sensible shortcut.

Convenience features can still be valuable. They simply need a reason to enter the first release instead of a later iteration.

State the tradeoff in ordinary language: what the user experiences, what staff do manually and what limitation remains visible.

Surface the dependencies

Features depend on data, permissions, provider accounts and other decisions. Record those dependencies before promising a date or treating the feature as a small addition.

A notification may depend on a recorded event, a reliable sending service and the correct recipient relationship. A payment feature may require provider eligibility, configuration and safe testing.

Identify work that the business must supply: content, sample records, access approvals or a decision about roles. Development capacity cannot remove every external dependency.

A simple dependency note can prevent a later-phase item from blocking the basic workflow unexpectedly.

Keep operational requirements in scope

A first release still needs an appropriate way to manage accounts, investigate failures and recover necessary information. The exact controls depend on what the application does and the data it handles.

Discuss who receives alerts, who can change access and how the service is supported. These are product responsibilities, not optional decorations to consider only after launch.

If you use a manual workaround, document it and identify the owner. A workaround without a defined process becomes a hidden dependency.

For a production system, ask the implementation team to design and test the relevant security and operational controls. The feature-prioritisation worksheet is not a substitute for that work.

Choose a representative exception

An ordinary journey is only part of the first-release test. Select an exception likely to expose an important assumption.

For a request app, that could be missing information or an item returned for clarification. For a client review flow, it could be a change request instead of approval.

Describe what the user sees, what staff see and what happens to the record. This helps prevent a demonstration from succeeding only when every input is ideal.

You do not need to solve every imaginable edge case in the first release. You do need a deliberate approach to the exceptions that matter to the selected task.

A worked scope-cutting example

Imagine a small service team proposing an application with requests, live chat, invoicing, project timelines, dashboards, appointment booking and document approvals.

Their observed problem is narrower: requests arrive through several messages, nobody can reliably identify the owner and customers repeatedly ask for status.

A possible first release could include an authenticated request form, a request list, an assigned staff owner, a small set of meaningful states and a customer view of the current result. The team would also need appropriate access rules, error handling and support ownership.

Live chat, invoicing and broad analytics can remain separate candidates unless evidence shows they are necessary for this journey. The example is illustrative, not a recommendation that every business use that exact feature set.

Define what a pilot can prove

Choose participants, tasks and evidence appropriate to the uncertainty being tested. Record whether people complete the journey, where they need help and which operational steps fail.

Use authorised accounts and suitable sample data when the implementation is not ready for broader use. Tell participants what is being tested and what remains a prototype or limited pilot.

A successful pilot can support a specific decision without proving every future use case. Be explicit about the limits of the evidence.

GOV.UK's beta guidance describes expanding a tested service through further learning and improvement. The useful principle here is to distinguish experimentation from a fully supported public service.

Compare scope with delivery capacity

Ask the team to explain the effort and uncertainty of the selected work. A single estimate cannot remove unknowns about an untested integration or unclear permission rule.

If timing is fixed, review the release boundary and dependencies. Avoid quietly assuming that testing, content or handover can be removed without changing the outcome.

If scope is fixed, discuss whether the schedule or delivery arrangement needs to change. The proposal should make these choices visible rather than promise all three constraints without explanation.

For choosing an implementation supplier, use the freelancer-versus-agency comparison to examine actual people and responsibilities.

Plan what happens after launch

A first release begins an operating phase. Decide who handles questions, records issues, approves changes and checks whether the service is still supporting its core task.

Keep separate lists for defects, usability observations, unverified ideas and confirmed new requirements. Otherwise every comment can become an urgent feature request.

Review the evidence against the original outcome. Add a feature because it addresses an observed need or a justified dependency, not merely because it was written down early in the project.

A product can remain focused while improving substantially. More features are not the only form of progress.

Questions before approving the MVP

Ask the team:

  • Which user and task does this release serve?
  • What evidence supports the problem?
  • What uncertainty are we testing?
  • What starts and completes the journey?
  • Which features are essential to that outcome?
  • What manual work remains, and who owns it?
  • Which dependencies could block delivery?
  • Which important exception will be tested?
  • What does the pilot demonstrate and leave unverified?
  • Who operates and supports the release afterwards?

If answers remain vague, a focused discovery step may be more useful than adding detail to a large development quote.

Brief a useful first release

Send the workflow, current problems, intended users, essential records and unresolved assumptions when asking for help. Include what you have already tried in existing tools.

The build-versus-buy guide can help assess whether custom development is needed at all. If it is, share your first-release requirements to discuss a scoped web application project.

Sources and editorial notes

References checked on 16 October 2026:

The feature framework, worksheet and worked example are editorial tools for discussion. They are not a mandated delivery method or a guarantee of validation, adoption or commercial success.