How to scope a useful first version of your product

1. Start with the problem and the evidence

Describe who has the problem, what they do today, and why the current approach falls short. Use interviews, existing workflows, support requests, or observed behaviour where available. Avoid treating a list of features as proof of demand. A useful product hypothesis connects a user, a task, and a proposed improvement. It might be helping retailers publish a shareable storefront or helping a team review incoming requests consistently. Write down the assumption that most needs testing, because the first release should generate evidence about that assumption.

2. Choose one complete journey

A first version should let someone achieve a useful result from beginning to end. A marketplace might need a retailer to create a catalogue and share a store link before it needs advanced analytics. A community product might first test member discovery and meaningful interaction. Map the starting input, the necessary steps, the completed result, and the supporting administrative work. Then remove optional branches. “Minimum” does not mean leaving the core journey broken; it means choosing a narrow journey and making its important parts work together.

3. Make hidden requirements visible

Even a small product may need authentication, permissions, persistence, validation, notifications, and a way to handle failed actions. State which of these are required for the chosen journey. Consider who may view or change data and whether external providers are involved. Define representative records and examples of difficult cases. A technical prototype can demonstrate an architecture or interaction without being ready for public use. Label that distinction clearly so a successful demonstration is not confused with operational readiness, account security, or a complete support process.

4. Agree acceptance criteria and learning goals

Write observable criteria for the release. For example, a user can submit a request, an authorised team member can review it, and both can see the current status. Include the failure behaviour that matters: invalid inputs, unavailable services, or an interrupted session. Separately define what you want to learn from use, such as whether customers finish the journey or whether the workflow removes a recurring manual handoff. Avoid vanity metrics without a decision attached. The evidence should help determine what to improve, remove, or build next.

5. Plan iteration and operational ownership

Agree the target environment, release process, and people responsible for running the product. A local trial, internal rollout, and public launch require different support and readiness decisions. Keep a prioritised later-feature list, but allow actual user feedback to change it. Identify expensive architectural decisions early without building every imagined future capability. After the first release, review incomplete journeys, repeated support questions, and exceptions. A good MVP is a starting point for informed development, with a clear scope and honest limitations, rather than a promise that every future feature already works.

Relevant EidenTech services