Minimum should mean focused, not unfinished
A minimum viable product is often treated as a smaller list of features. That misses the point. A first release is valuable when a real user can complete a meaningful journey and the team can learn enough to make a better next decision.
Removing essential steps creates an incomplete product. Keeping every imagined feature creates a slow and expensive experiment. Good scope protects the complete learning loop while postponing breadth.
Start with an outcome and one primary user
Write down who the release is for, what they need to accomplish and what should change for the organisation. If the statement contains several unrelated users and outcomes, choose the one that carries the most important assumption.
This is a temporary boundary, not a claim that other users do not matter. It gives design and engineering a stable centre for the first release.
Draw the smallest complete journey
Map the journey from trigger to outcome, including the work behind the interface. A product that accepts a request may also need identity, routing, review, status, notification and a way to resolve exceptions. Those supporting steps belong in the scope if the journey cannot work without them.
Use a vertical slice: one narrow path through interface, data and operations. Avoid building broad layers that do not yet connect into something a user can finish.
Separate essential, later and unknown
A useful prioritisation conversation distinguishes three types of scope. Essential work completes the chosen journey or protects a non-negotiable boundary. Later work expands value but is not required to test the first proposition. Unknown work needs research or a proof before it can be estimated responsibly.
- Essential: without it, the core user cannot reach the intended outcome safely.
- Later: valuable once the first journey is working, but not required to learn from it.
- Unknown: an assumption about behaviour, data, integration or technology that must be tested.
Put the highest risk early
Teams naturally begin with the easiest visible work. A better plan investigates the assumption most capable of invalidating the product: access to required data, user willingness, an unfamiliar integration, model quality, performance, regulation or the operating process behind the service.
A short prototype or technical spike may answer that question without building the whole release. If the result changes the direction, it has saved work rather than delayed it.
Define done in observable terms
Each part of the scope should have a result that a person can observe. Replace 'build a dashboard' with the decisions the user must make, the data required, the states that need explanation and the action that follows. Acceptance criteria align product, design and engineering around behaviour rather than interpretation.
Include quality boundaries such as accessibility, security, privacy, performance, auditability and recovery. They are not optional polish when they determine whether the product can be used responsibly.
Make the release answer a question
Choose a small set of measures before launch. Completion of the core journey, time to outcome, repeated use, exception rate, support burden or a changed operational measure may be more useful than traffic alone. Decide what result would support continuing, revising or stopping.
A concise first-release brief can contain the problem, primary user, outcome, complete journey, essential scope, exclusions, major risks, dependencies, quality boundaries and evidence plan. That document is enough to begin discovery without pretending every detail is already known.