Choose one valuable user journey and the smallest dependable set of capabilities needed to complete it. Prioritise the assumptions that could invalidate the product, include the operational and security work required to run it, and postpone features that do not change the first learning decision.
Put this guidance into practice
Explore our custom CRM and ERP development, software development, application launch, premium website development and business automation services. We scope the work around your existing tools, team and goals.
Start with the decision the MVP must help you make
An MVP is not a smaller version of every idea in the roadmap. It is a release designed to create evidence for a specific product decision. Before listing screens, write down the user, the problem, the behaviour you expect and what you will do if that behaviour does or does not happen.
For example, a field-service product might need to learn whether technicians will complete a structured visit record on a phone. That decision calls for assignment, offline-tolerant data entry, submission and review. It does not automatically require team chat, advanced forecasting or a marketplace.
The Scrum Guide describes the Product Goal as the future state that gives the team a target, while the Product Backlog is an ordered and evolving list. Use that distinction: keep one clear first-release objective and allow the wider backlog to change as evidence arrives.
- Name the first user segment and the situation in which they will use the product
- Define one behaviour that would demonstrate useful value
- State the decision the team will make from the result
- Agree the evidence window and the person who owns the decision
Map one complete journey from trigger to outcome
Users do not experience a feature list; they experience a sequence. Map the trigger, entry point, essential steps, successful result and recovery route. A complete narrow journey teaches more than several polished screens that cannot deliver an outcome.
Include the work behind the interface. If an application accepts a booking, someone or something must validate availability, handle exceptions, notify the right people and keep a reliable record. Leaving those steps to an undocumented manual workaround can make the MVP appear simpler while moving the risk into daily operations.
Separate capabilities into three groups: required to complete the journey, required to operate it responsibly, and useful later. A capability stays in the first release only when removing it breaks the outcome, prevents safe operation or stops the intended learning.
- Entry and onboarding needed for the first task
- Core action and confirmation of the result
- Admin or staff workflow that fulfils the promise
- Error, cancellation and support routes
- A reliable record of what happened
Test the assumptions that could stop the product
Some uncertainties are about desirability, others about usability, feasibility, compliance or commercial viability. Rank assumptions by the damage they would cause if wrong and how little evidence you currently have. Test the most dangerous uncertainty before investing in breadth.
GOV.UK's alpha guidance recommends doing the minimum needed to test the riskiest assumptions and using prototypes that are only as complex as the question requires. A clickable prototype can test comprehension; a technical spike can test an integration; a concierge trial can test whether the promised service is valuable before automating it.
Do not force every experiment into production code. Record the assumption, test, observed result and decision. This keeps the team from treating opinions as validated requirements or preserving prototype shortcuts as permanent architecture.
- Desirability: will the intended user choose and complete the journey?
- Usability: can they understand it without continuous help?
- Feasibility: can critical integrations and device conditions work?
- Viability: can the business deliver and support the outcome?
- Risk: are legal, privacy or safety constraints understood?
Keep quality, security and operations inside the scope
Minimum does not mean careless. Authentication, authorisation, data protection, accessibility, monitoring and recovery may be invisible to a user, but they determine whether the release can be trusted. The required depth depends on the information processed and the consequence of an error.
OWASP's Application Security Verification Standard provides a structured basis for defining and testing web-application security controls. Use an appropriate subset as acceptance criteria rather than promising to add security after traction. For mobile products, Apple also requires accurate disclosure of the application's data practices, including relevant third-party code.
Define who will answer support questions, correct data, review failures and deploy a fix. If the team cannot observe and recover the core journey, the product is not ready for real users even if the happy-path screens look complete.
- Risk-appropriate sign-in and server-side access controls
- Privacy decisions and only the data the journey actually needs
- Accessible labels, focus, contrast and touch behaviour
- Logs, alerts and analytics without exposing sensitive information
- Backup, rollback and named support ownership
Choose measures before choosing the dashboard
Measure the behaviour connected to the product decision. Useful first-release signals often include activation, completion of the core journey, time to outcome, repeat use, support demand and the reasons users stop. Downloads or registrations alone may say little about whether the product solved the intended problem.
GOV.UK's service guidance recommends defining performance measures from the start and combining digital analytics with user research and operational information. The same principle applies to a commercial MVP: events show where something happened, while interviews, support conversations and observation help explain why.
Write event names and success conditions into the acceptance criteria. Check that internal staff and automated tests can be excluded where appropriate. Review privacy requirements before collecting behavioural data, and avoid gathering information merely because an analytics tool makes it available.
- Core-journey start and successful completion
- Time, steps and errors before the outcome
- Return use that indicates continuing value
- Support contacts and manual interventions
- Qualitative evidence from representative users
Make the first-release boundary visible
Create a one-page release boundary that lists the target user, core journey, included operational controls, assumptions being tested, measures and explicit exclusions. This gives founders, designers and engineers the same basis for trade-offs when new requests appear.
Order the remaining backlog by expected value, risk reduction and dependency rather than by who asked most recently. A deferred feature is not rejected forever; it simply has not earned a place ahead of the current product decision. Revisit the order after every meaningful test or release review.
DigiStartup India can help turn an application idea into a testable product scope, prototype, production-ready first release and measured launch. Bring one user problem and the current workaround to the first discussion; the feature list can follow the evidence.
- One first-release goal and user segment
- One complete journey with staff and exception handling
- Security, privacy, accessibility and support acceptance criteria
- A small set of decision-linked measures
- Named exclusions and the next review point
Further reading
Frequently asked questions
How many features should an MVP have?+
There is no universal number. Include the smallest set that lets one target user complete a valuable end-to-end journey, lets the team operate it safely and produces evidence for the next product decision.
Should an MVP include admin tools?+
Include the staff capabilities needed to fulfil, review and correct the core journey. A simple controlled admin workflow may be enough at first, but relying on undocumented database edits is not a dependable operating model.
Can security and accessibility wait until after the MVP?+
No. Their scope should be proportionate to the release and its risks, but relevant authentication, authorisation, privacy, accessibility, monitoring and recovery requirements belong in the first release's definition of done.
What should be postponed from an MVP?+
Postpone capabilities that do not affect the core outcome, safe operation or the assumption being tested. Common candidates include broad customisation, secondary user segments, advanced reporting and integrations without a first-release dependency.