In this article 12 sections
Include the smallest complete journey that gives a real user a useful outcome, plus the essentials needed to operate it responsibly. Cut breadth before cutting reliability, access control or the ability to help a user who gets stuck.
Start with the outcome, then work backwards#
Describe what someone should have achieved at the end of a session. For a booking service, that might be a confirmed appointment. For a reporting tool, it might be a report they can use in a meeting. Work backwards through the steps, information and decisions required. Features earn their place by supporting that outcome or testing a material assumption.
Choose a specific first audience. A system for independent tutors does not need all the permissions and procurement processes of a national education provider. Narrowing the customer makes it easier to define a useful first release without pretending that every customer has the same needs.
Separate the journey from the operating essentials#
| Layer | Include when needed for the first release | Often safe to defer |
|---|---|---|
| User journey | Entry, the main action, confirmation and status | Extra use cases and alternative journeys |
| Accounts | Appropriate access controls and recovery | Large permission hierarchies |
| Operations | A way to inspect and resolve failed work | Automation for rare exceptions |
| Learning | Outcome events, errors and user feedback | Extensive reporting dashboards |
| Delivery | Deployment, monitoring and recovery ownership | Infrastructure for hypothetical future scale |
These are prompts, not a mandatory feature list. A public calculator may not need accounts. A marketplace handling payments needs a more substantial operational layer than a read-only directory. The right scope follows the product’s actual risks and responsibilities.
A booking MVP, worked through#
Imagine a service that matches customers with a small group of local tutors. The first release could let a customer describe their need, view a suitable tutor, request a lesson and receive confirmation. A tutor needs to accept or decline. An administrator needs to spot unanswered requests and help resolve cancellations.
Advanced recommendations, referral rewards, multi-country pricing and a full tutor analytics suite can wait. Confirmation, clear pricing and a way to get help cannot. The smallest useful product connects the whole transaction; it does not stop at attractive tutor profiles.
Use four questions to challenge every feature#
- Does the core outcome fail without it?
- Does it test an assumption that could change the next investment decision?
- Does it reduce a material operational, security or user risk?
- Could the team do this manually for the first cohort without misleading or burdening users?
If the answer to the first three is no, the feature needs a stronger argument. If a manual process is acceptable, document who will do it, how quickly and at what volume it stops being practical. Manual work is still work that needs capacity.
Write exclusions as carefully as inclusions#
A release brief should state supported users, devices, geography, payment methods and integrations. Give each included journey an acceptance criterion. Record deferred features separately so stakeholders know they are deliberate decisions. See the build process for turning that brief into delivery milestones.
Keep a launch gate#
Before release, check the happy path and likely failures with realistic users and data. Confirm that permissions work, important actions produce clear feedback and support can recover from mistakes. Privacy decisions belong in product design; the ICO’s guidance addresses data protection throughout the lifecycle. A smaller scope should make these checks easier to complete.
Different products need different minimums#
| Product | Complete first outcome | Can often wait |
|---|---|---|
| Internal reporting tool | Import a supported file, identify errors and produce a usable report | Custom report builders and dozens of integrations |
| Booking service | Request, accept, confirm and handle cancellation | Automated price optimisation and loyalty programmes |
| SaaS workflow | Complete a repeatable job with correct account access | A large permissions hierarchy and marketplace of extensions |
| Transaction marketplace | Match, confirm, record payment and resolve exceptions | Automated matching for every category and geography |
The examples are editorial starting points, not universal specifications. A reporting tool for sensitive data may need stronger controls than a public booking page. A feature can be essential because of a user need, an operating constraint or an applicable requirement, even if customers never see it directly.
Use a feature decision record#
For each proposed feature, write the user outcome, evidence that it is needed now, the cheapest workable alternative and the consequence of deferring it. Choose include, handle manually or defer. Assign an owner and a condition that would reopen the decision.
For example, an early marketplace might handle supplier onboarding manually because the operator can review every applicant. The record should say who performs that work, how the decision is recorded and what volume or error rate would make automation necessary. “Manual for now” without those details is just an unassigned task.
Give an excluded feature the same clarity as an included one. “No self-service refunds in this release; staff can issue permitted refunds through the agreed provider process and record the outcome” is a usable boundary. “Refunds later” leaves the first customer’s problem unanswered.
Write acceptance examples for the core journey#
Describe the starting state, action and observable result. Add at least one awkward case to each consequential step. For a booking: when a provider accepts, the customer sees confirmation; when a second request arrives for the same unavailable slot, the system prevents a second confirmation and explains the next step.
Acceptance criteria should cover the outcome, not only a screen’s appearance. Include who can see the resulting record, whether an action can be repeated, and how staff resolve a failure. Use the brief template to send these criteria to a delivery partner.
Put this guide to work#
Frequently asked questions#
How many features should an MVP have?
There is no useful universal count. One feature can conceal a complex payment system; several small features may together create a simple complete journey. Scope around the first outcome, the roles involved and the evidence you need.
Does an MVP need an admin dashboard?
It needs a workable operating process. A dedicated dashboard is appropriate when staff must inspect records or take controlled actions regularly. An existing tool may suffice initially, but routine support should not depend on someone making undocumented database edits.
Can security and accessibility wait until after validation?
The safeguards and access needs that apply to real users belong in the first usable release. Reduce the scope and exposure if needed. A pilot label does not prevent harm from broken account isolation or an unusable core task. The depth of review should match the actual product and risks.
Should analytics be in the MVP?
Include a proportionate way to observe the key outcome and failures. A small set of meaningful events and a feedback route may be enough. Do not build a large reporting dashboard before defining which decisions the data will inform.
What if every stakeholder says their feature is essential?
Ask each to connect it to the same release goal and explain what happens if it is deferred. Surface conflicting goals rather than combining every request. A named product owner must choose a coherent first release within the available budget and support capacity.
Sources and methodology#
This guide combines editorial analysis with the linked primary sources. Decision frameworks, worksheets and worked examples are our own; examples are illustrative unless explicitly identified as supplier claims or published research. We have not conducted original interviews, comparative supplier testing or a controlled experiment for this article.
- GOV.UK Service Manual: learning user needs ↗
Primary reference for the platform or practice discussed. Editorial examples and decision frameworks are our own.
Accessed 16 October 2026 - ICO: data protection by design and by default ↗
Primary reference for the platform or practice discussed. Editorial examples and decision frameworks are our own.
Accessed 16 October 2026 - NCSC secure development guidance ↗
Primary reference for the platform or practice discussed. Editorial examples and decision frameworks are our own.
Accessed 16 October 2026
Source check: 16 October 2026. Platform documentation can change. Published as part of our editorial collection.
Expanded 16 October 2026 with practical decision material, downloads and topic-specific answers. Supplier and platform claims are identified by their linked sources.
MVP Build Editorial. “What should an MVP actually include?.” MVP Build, 9 September 2026.
https://mvpbuild.xyz/mvp/what-should-an-mvp-include/