# MVP scope brief

AppX Tech Group · https://appxgroup.uz/blogs/how-to-scope-an-mvp

Copy and adapt this template for your product. The completed example below is
hypothetical. It is not a client result, estimate, or universal benchmark.

## Your release

- Product and date:
- Decision the release must help us make:
- First user and their useful outcome:
- People invited and pilot duration:
- Core journey (arrival → action → confirmed outcome):
- Promise we make on the interface:
- What requires human confirmation:

## Scope buckets

| Required for core journey | Required to operate reliably | After evidence | Out of scope |
| --- | --- | --- | --- |
| | | | |

## Acceptance examples

For each important action, write:

- Given (user, state, permission):
- When (action):
- Then (visible result and persisted result):
- If sending or integration fails:
- If the user repeats the action:
- If the user leaves and returns:
- Evidence we will inspect before launch:

## Operations and delivery

- Owner of each manual step:
- Required provider/accounts and who controls them:
- Data collected and reason:
- Support and correction path:
- Decisions still unresolved:
- Budget boundary and explicit exclusions:
- Release reviewer and approval criteria:
- Events to measure (without unnecessary personal content):
- Pilot review date and next-decision rule:
- Time and budget reserved for changes after the pilot:

---

## Completed example: tutoring lesson requests

Decision: Will parents request a lesson after seeing a reviewed tutor profile?
First user: A parent seeking a maths tutor.
Useful outcome: A request submitted, acknowledged, and reviewed by an operator.
Pilot: 20 eligible parents, two weeks (example choice, not a benchmark).
Promise: Request a time; an operator will confirm availability.

| Core journey | Reliable operation | After evidence | Out of scope |
| --- | --- | --- | --- |
| Published tutor list and profile | Operator request list | Tutor self-service | Automated payouts |
| Subject filter and time request | Duplicate-request protection | Parent reviews | Native mobile app |
| Contact and acknowledgement | Accept/decline with reason | In-app chat | Multi-city launch |
| Request-status communication | Failed-delivery recovery | Subscriptions | Instant booking guarantee |

Acceptance: Given a parent selects a published tutor, submitting a valid request
creates one operator-visible record and an acknowledgement. Repeated clicks must
not create duplicates. An unconfirmed time must never appear confirmed. Declined
requests retain a reason. Failed notifications remain visible for operator retry.

Operational owner: Assign a named staff member before launch. They review each
request, confirm the proposed time with the tutor, and update its status. Do not
publish an automatic-confirmation promise while this step is manual.

Pilot evidence: profile views, request count, confirmed lessons, time to
confirmation, cancellations, and reasons people stopped. Review the flow if fewer
than five invited parents request a lesson (illustrative review trigger only).
Interview people who did not request before choosing the next feature. Avoid
reading a small pilot as a reliable revenue or conversion forecast.

Exclusions: native apps, automated payouts, tutor self-service, subscriptions,
reviews, and instant booking. Any addition needs a written scope tradeoff.