How to Prioritize MVP Features Without Breaking the Core Journey
Prioritize MVP features with a dependency worksheet that shows which cuts remove optional polish and which cuts break the first usable outcome.
Luka Abramovic3 min read
To prioritize MVP features, remove a proposed feature and walk the user’s task again. If the user can still achieve the promised outcome through an explicit, supported route, the cut may be viable. If the cut removes required evidence, permissions or recovery, a smaller feature list may simply describe a broken journey.
Domain-expert founders often see many valuable uses for the same knowledge. Choose one outcome for the first release and make every candidate explain its relationship to that outcome. Keep attractive adjacent use cases in a separate list.
Map dependencies before assigning priorities
Write the outcome at the right of a page and work backwards. For a supplier brief, the user must approve an output, which requires a draft, which requires confirmed inputs. Draw only dependencies needed for correctness. Put convenience features such as alternate layouts to the side.
Ask what happens if each dependency is absent. A missing export style may have a manual substitute. Missing ownership rules do not become optional because fewer users are invited. Identify the route that would actually carry the task through the pilot.
Use a cut decision table
| Candidate | What fails without it? | Supported substitute | Decision |
|---|---|---|---|
| Multiple export layouts | Preferred formatting | One usable standard export | Defer extra layouts |
| Draft recovery | Work can disappear on return | None for a long task | Keep in core journey |
| Automated provider matching | Operator must choose | Named matching queue | Manual during pilot |
| Account separation | Wrong user can access work | None in a shared customer product | Release gate |
These are illustrative decisions, not universal requirements. Replace the task and substitutes with your own. A substitute needs an owner, available time and a way to record completion. Otherwise it is an omission wearing a reassuring label.
Find the decision with the largest dependency chain
Mark which unresolved question changes several features. Whether customers collaborate inside one organization may affect invitations, ownership, permissions and billing. Resolve that before refining four separate screen estimates.
In an illustrative plan, six features each appear to take one work unit. Three depend on the same undecided approval rule. You do not have six independent units ready to build. You have three blocked units and a design decision whose answer may change their scope. Keep that distinction in the plan instead of adding a general uncertainty percentage.
Rehearse the smaller release before accepting the cut
Walk the complete task with the proposed reduced scope. Include a first-time user, a returning user and an interrupted attempt. Write any new manual steps created by the cuts. This rehearsal can reveal that deleting one screen has added several support operations elsewhere.
Finish with a short release boundary. Name the user, the output, the included route, the supported exceptions and the excluded alternatives. Give future ideas a separate heading so they cannot quietly become acceptance conditions for the current build.
Review a new feature request by asking which failed task it changes. If it changes no task in the agreed release, record it for the next decision point. If it reveals that the promised outcome cannot be achieved, revisit the boundary explicitly rather than hiding the change inside a cosmetic revision.
Bring the feature list and one complete customer task. We can identify viable cuts and the dependencies they must preserve. Discuss the first release with Adamant Code.