How to decide what belongs in the first version of your product

The first version is a decision, not a feature count

Early product plans usually contain more ideas than a team can responsibly build at once. That is normal. The difficult work is not collecting features; it is deciding which combination creates a complete, useful experience for a specific person.

A first version should let a real user achieve one worthwhile outcome from beginning to end. It should also give the team evidence about an important assumption. A short list of disconnected features may be small, but it is not necessarily coherent. Conversely, a release can contain substantial engineering and still be appropriately scoped if those pieces are required for one dependable journey.

This framing changes the question from “How much can we fit?” to “What must be true for this release to create value and reduce uncertainty?” That is a much better basis for technical and commercial decisions.

Start by naming the outcome

Write one sentence that identifies the user, the situation and the result they need. For example: “A practice manager can see every new enquiry, assign an owner and confirm that a response has been sent.” This is more useful than “build an enquiry dashboard” because it describes completed work rather than an interface.

Then choose the assumption that makes the release worth building. You might need to learn whether the problem is frequent enough, whether people will change an existing habit, whether a third-party integration is reliable, or whether a paid offer is compelling. Pick the assumption that could most readily invalidate the current direction. A first release that avoids the important unknown may look polished while teaching very little.

Map the thinnest end-to-end path

List each step between the user's starting point and the completed outcome. Include the unglamorous operational steps: access, data entry, notifications, review, failure recovery and administration. These are often where a seemingly simple idea becomes a real product.

For every step, decide whether it must be implemented, can be handled manually during the learning period, or can wait. Manual support is legitimate when it is visible, safe and operationally realistic. It is not legitimate when it hides a core feasibility problem or asks the team to perform an unsustainable amount of invisible work.

Be especially careful with trust. Authentication, permissions, data protection, error states and basic accessibility are not optional polish when the product needs them to operate responsibly. “MVP” does not mean the release can mislead users, expose information or fail without a recovery path.

1. Describe the user's starting state.
2. Write the smallest sequence that reaches the promised outcome.
3. Mark the steps that protect trust or make the outcome dependable.
4. Identify manual steps and name who will perform them.
5. Remove anything that does not support the outcome or the learning goal.

Use a four-part test for every proposed feature

A useful scope conversation separates evidence from preference. Ask the same four questions about each proposed capability. First, does the user need it to complete the selected outcome? Second, does it reduce a material risk, such as unauthorised access or an unrecoverable failure? Third, is it required to test the key assumption? Fourth, is it expensive to add later because it affects the underlying architecture or data model?

A “yes” does not automatically force the item into scope, but it gives the team a concrete trade-off to discuss. An item that answers “no” four times is a strong candidate for the backlog. An item that protects trust may outrank a more visible feature. An architectural decision may deserve early exploration without requiring its entire future interface to be built.

Avoid broad labels such as “analytics”, “AI” or “admin”. Break them into the actual decision or action required. Basic event capture may be essential to learn from the release while a comprehensive reporting suite is not. A simple internal correction screen may be necessary while a fully configurable administration platform can wait.

Make the “not now” list explicit

Scope becomes unstable when deferred ideas remain implicit. Record what is excluded, why it is excluded and what evidence might bring it back. This protects the first-release goal without pretending the other ideas have no value.

Also record dependencies and assumptions. If the release relies on manual onboarding, state who owns it and how many users the team can support. If an integration is uncertain, schedule a technical spike before treating it as solved. If the product handles sensitive information, identify the required specialist review rather than leaving it as a late surprise.

A good scope document should help a designer, engineer and business owner make the same trade-offs when new requests arrive. It is not a frozen promise. It is a shared decision tool that can change when evidence changes.

Decide how the first version will be judged

Choose a few measures connected to the user outcome and learning goal. Relevant evidence might include whether users complete the journey, where they stop, how much assistance they need, whether the output is correct enough for its purpose, or whether they return for the same task. The right measure depends on the product; a generic dashboard of activity will not answer every question.

Combine behavioural evidence with direct conversations. Usage can show what happened, while a careful interview can help explain why. Neither should be treated as certainty in isolation, particularly with a small early group. Record unexpected failures and workarounds as seriously as successful completion.

A final scope check

Before development begins, walk through the release as the user, the operator and the person accountable for risk. Confirm that the journey is complete, manual work is owned, important failures have a response and the team can observe the intended evidence.

The best first version is not the one with the fewest screens or the longest feature list. It is the smallest responsible system that delivers a real outcome and creates a sound basis for the next decision.