Your first product release should help a defined group of users complete a useful task and give your business evidence for the next decision.
That makes feature selection more specific than choosing the quickest items to build.
Start by asking:
“What does a user need to complete, and what do we need to learn from that experience?”
The answer helps separate essential functionality from features that can follow later.
This guide explains how to prioritise an MVP, using an illustrative business application example.
Define the Assumption You Want to Test
An MVP should help investigate a meaningful uncertainty.
For example:
Choose a clear first assumption.
A release built to test customer adoption may need different functionality from one testing technical feasibility.
If the main uncertainty is whether an integration works, a focused prototype or technical investigation may be appropriate before building a customer-facing product.
Our MVP development service explains how an initial scope can be planned.
Choose a Specific First Audience
“Small businesses” or “all customers” may be too broad for useful first-release decisions.
Identify a group with a shared task and enough access to participate in the trial.
Existing retail customers who regularly reorder a limited set of wholesale products.
Anyone who wants to buy online.
The first audience affects account access, product information, onboarding and support requirements.
You can broaden the audience after reviewing what the first group needs.
Map One Complete User Journey
Features become easier to prioritise when they support a complete task.
For the wholesale reorder example, the journey might be:
Authorised Sign-In
An authorised retailer signs in to the application.
Product Catalogue View
They view the wholesale products available to them.
Quantity Entry
They enter requested quantities for required items.
Request Submission
They submit the completed reorder request.
Staff Review
Internal staff confirm stock and product availability.
Status Confirmation
The retailer receives an operational confirmation or update.
This is an illustrative example, not a report from a client project.
The first release needs enough functionality to complete the agreed journey. A collection of disconnected screens would provide limited evidence about whether the process works.
Identify What Must Work Behind the Interface
Customer-visible features are only part of the scope.
The reorder workflow may also need:
These requirements may be less prominent in a demonstration, but they affect whether the workflow can be used reliably.
For account-based applications, our customer portal development page explains how customer and staff tasks connect. You can also explore our guide to Plan customer and staff portal workflows to structure document exchange, approvals and self-service records.
Put Features Into Four Groups
A simple classification can make the planning discussion clearer.
| Group | Meaning | Example |
|---|---|---|
| Essential to the first journey | Users cannot complete the agreed task without it | Submit a reorder request |
| Necessary to operate the trial | Staff cannot manage the first release appropriately without it | Review submitted requests |
| Needs investigation | Feasibility or requirements remain uncertain | Connection to the stock system |
| Can follow later | Useful, but unnecessary for the first test | Product recommendations |
Do not leave uncertain work hidden inside an estimate.
If an external system is essential, investigate its access and capabilities before relying on it in the launch scope.
Explore our API development and integration service for connected-system requirements.
Evaluate Each Proposed Feature Against the Same Questions
Use structured criteria to test whether every item truly earns its spot in release one.
Does It Support the Main Task?
Ask what happens if the feature is removed. If the first user can still complete the agreed journey, the feature may be a candidate for a later stage.
Does It Help Test the Product Assumption?
A feature can be attractive without producing evidence about the decision you need to make. For example, an advanced analytics dashboard may have little effect on whether retailers submit reorder requests.
Is It Needed for Responsible Operation?
Permissions, validation and suitable handling of information may be necessary even when they do not directly test demand. These requirements should not be dismissed simply because they are invisible to users.
Does It Depend on Unfinished Work?
A feature may require another service, design decision or operational process. Record those dependencies before promising a delivery date.
Can It Be Handled Manually During a Limited Trial?
Some operational steps can be performed manually at first. Assess the volume, effort and consequences before choosing that approach.
Where Manual Work Can Help
For a small reorder trial, staff might initially check stock and confirm availability manually.
That could allow the business to test whether customers use the request workflow before investing in a full inventory connection.
The manual arrangement needs boundaries:
A manual step is a planned operating decision. Document it so everyone understands the workload and limitations.
A Worked MVP Scope Example
The table below shows one possible scope for the illustrative wholesale reorder product.
| Proposed feature | First-release decision | Reason |
|---|---|---|
| Authorised customer access | Include | Restricts the trial to the intended audience |
| Limited product list | Include | Customers need to identify what they want |
| Quantity entry and validation | Include | Supports a usable request |
| Request submission | Include | Core customer action |
| Staff review interface | Include | Makes requests manageable |
| Status confirmation | Include | Completes the customer journey |
| Live inventory synchronisation | Investigate or defer | Depends on the trial’s operating requirements |
| Online payment | Defer if orders can follow the existing payment process | Not essential to this particular test |
| Recommendations | Defer | Does not establish whether the reorder workflow is useful |
| Loyalty programme | Defer | Adds scope beyond the first assumption |
| Native mobile apps | Defer if browser access meets user needs | Additional platforms are not required for this trial |
Another business could reach different decisions.
For example, if immediate payment is fundamental to the purchase process, it may belong in the first release.
The classification follows the workflow and assumption, rather than a universal list of MVP features.
Write Acceptance Criteria for Included Features
Once a feature is included, explain what it needs to demonstrate.
For request submission, criteria might include:
These are illustrative criteria. The actual checks should reflect the product and its risks.
Our developer brief guide explains how to make a scope easier to estimate.
Match the Release to Your Team’s Capacity
An MVP needs people available to operate and review it.
Consider who will:
A product with fewer features can still create substantial operational work.
Identify the people and time needed before launch.
Decide How You Will Learn From the Release
Choose measures connected to the original assumption.
For the reorder example, useful observations could include:
These are proposed measures, not performance forecasts.
Usage information can show what happened. Conversations with users can help explain why.
Agree on who will gather and review that evidence.
Change Scope Deliberately
New ideas will arise during design and development.
Before adding one, ask:
A change can be worthwhile. It still needs an explicit decision.
Keep a record of deferred ideas so they are not repeatedly reconsidered without new information.
What If You Already Have a Partly Built MVP?
Review the existing functionality against the first-release journey.
Identify what works, what is incomplete and what is no longer relevant to the agreed test.
Do not assume all existing work must be retained or discarded.
Our guide to taking over an unfinished application explains the initial checks.
An application technical assessment may help establish a dependable continuation scope.
Plan the Next Decision Before Launch
Agree on when the first release will be reviewed and what evidence will inform the discussion.
Possible decisions include:
If further work is required, prepare the next scope using what you have learned.
Ongoing fixes and improvements can be discussed through our application maintenance service.
Discuss Your First Product Release
DOT IT Services helps businesses define and develop focused web, SaaS and mobile releases.
Tell us who the first users are, which task they need to complete and what you want to learn. We will discuss a practical starting scope and the development support required.
Written by DOT IT Services.