Start condition
State what is true when the user begins: their role, need, access, and the input they bring.
MVP scoping guide
How to scope an MVP around one complete user journey
A credible MVP is a complete path through one important problem, not a thin sample of every future feature. The user should be able to reach a meaningful outcome without the product pretending to be finished everywhere.
Write the journey before the feature list
Describe the user, starting situation, action, and completed outcome in one sentence. Features enter the release only when the journey cannot work without them.
Critical path
List only the decisions and system responses required to move from that start to the intended result.
Completed outcome
Define what the user can now do, see, receive, or hand off that was not possible before the journey.
Protect the boundary of the first release
Every requested capability should be classified as required for the journey, required for safe operation, or deferred. This keeps the release small without hiding operational work.
Required for value
The journey cannot produce its outcome without this capability.
Required for operation
The product needs it to be supportable or safe: access control, validation, logs, backups, moderation, or an admin path.
Deferred by evidence
The capability may matter later, but the first release can test the core assumption without it.
One-journey MVP worksheet
Complete the rows in order. If the success evidence cannot be named, return to the problem statement before estimating development.
- Primary user
- Who experiences the problem and has permission to complete the journey?
- Problem moment
- What event or situation makes the user start this journey now?
- Journey statement
- As this user, I can move from the starting situation to a specific useful outcome in one coherent flow.
- Acceptance criteria
- Which observable behaviours prove that the normal path and its important failure states work?
- Operational path
- Who handles support, approvals, failed jobs, content, refunds, or data corrections behind the interface?
- Release boundary
- Which roles, platforms, integrations, and secondary journeys are explicitly outside the first release?
- Decision evidence
- What usage, completion, enquiry, retention, or operational evidence will decide the next iteration?
Test the scope
The release contains several unrelated primary users
Choose the user whose completed outcome tests the most important assumption first.
A feature does not change the primary journey or safe operation
Move it to a later-release list with the evidence that would justify bringing it back.
The happy path works only through hidden manual intervention
Document that operation explicitly and decide whether it is an acceptable first-release process.
Success is described only as shipping the product
Define the user or business evidence the release is intended to produce.
Turn the worksheet into a delivery scope
The guide is a planning aid, not an estimate. The related service page explains the normal deliverables, process, and baseline boundaries for this kind of engagement.
Explore MVP development →Discuss a similar project
Describe the problem, current situation, and outcome you need. I will suggest a sensible first step.
Send a project enquiry