Choosing the smallest useful product release

MVP planning starts with one outcome, not a feature list

MVP planning goes wrong most often at the very first step: teams write a list of features they believe a product needs, then look for ways to trim it. This produces a smaller version of everything rather than a working version of the one thing that matters. A more reliable starting question is: what single outcome, if achieved, makes this release worth using at all? Everything else is either in service of that outcome or it is not part of the release.

Framing the release around an outcome rather than a feature set also changes how you evaluate cuts later. When a feature is questioned, the test is not 'is this useful in general' but 'does removing this stop a user from reaching the outcome.' That distinction is what keeps scope negotiations from becoming subjective arguments about taste.

GOV.UK's guidance on the beta phase makes a related point: a beta is where a team tests whether a service actually works for people, not where every anticipated feature is built out. The same discipline applies to a first commercial release. The goal of MVP planning is not completeness, it is a decisive answer to whether the core outcome holds up in front of real users.

Separating the core outcome from its supporting scaffolding

Once the core outcome is named, most remaining scope falls into a small number of categories: things that produce the outcome, things that make the outcome trustworthy (error handling, basic accessibility, clear feedback), and things that make the outcome comfortable or convenient but not essential on day one. Confusing the second and third categories is the most common cause of scope creep, because comfort features often feel necessary to the team even when a first user could manage without them.

A useful discipline is to ask, for each candidate feature, what happens if it is missing when a real person tries to complete the task. If the honest answer is 'they get an error with no explanation' or 'they cannot complete the task at all,' the feature likely belongs in the trustworthiness category and should stay. If the honest answer is 'it takes them slightly longer' or 'it looks less polished,' it can usually wait.

This separation also protects accessible interfaces from being treated as a later add-on. Basic accessibility, such as usable keyboard navigation, readable contrast and clear error messages, is part of whether the outcome actually works for the people who need it, not a finishing touch applied once the 'real' scope is done.

Using small testable releases to replace guesswork

A small testable release is not simply a release with fewer features; it is a release built so that the team can learn something specific from it. Before building, it helps to write down what would count as evidence that the outcome is or is not being met. Without that step, a small release still runs the risk of shipping quietly and being judged only on opinion.

GOV.UK's prioritisation guidance frames this as deciding what to build next based on evidence of user need rather than internal assumptions about importance. Applied to MVP planning, this means each release should be scoped tightly enough that the team can observe, within a reasonable window, whether the intended outcome is actually happening for users, rather than assuming it because the feature exists.

Small releases also reduce the cost of being wrong. If a release is scoped around one outcome and the evidence shows it isn't landing, the team has lost little and knows precisely what to change. A release built around ten loosely connected features makes it far harder to tell which part failed.

A worked example: scoping a first release for a scheduling tool

The following is a hypothetical, illustrative only, and not a description of any IVRYN product or customer. Imagine a small team building a tool that lets independent contractors send clients a booking link so clients can pick a time without email back-and-forth. The team's instinct, before any cutting, is a list that includes multiple calendar integrations, payment collection, automated reminders, team scheduling for multiple staff, and a branded client portal.

Applying the outcome test: the core outcome is 'a client can pick an available time and both parties see it confirmed.' Payment collection, team scheduling and branding do not affect whether that outcome happens; they affect comfort and monetisation later. One calendar integration, rather than several, is enough to test whether the availability-and-confirmation mechanic works at all. Automated reminders sit in the trustworthiness category only if their absence would cause missed bookings that the core flow itself doesn't already prevent - in this case, a confirmation email at the time of booking likely covers that risk well enough for a first release.

The resulting first release: one calendar integration, a booking link, and a confirmation email. No payments, no team accounts, no custom branding. The team can now observe, within weeks, whether contractors and their clients complete bookings without confusion. That evidence, not a longer feature list, decides what gets built next.

• Name the one outcome the release must achieve before listing any features
• Sort remaining scope into: produces the outcome, protects trust in the outcome, or adds later comfort
• Write down what evidence would show the outcome is or isn't working before you build
• Treat basic accessibility as part of the outcome, not a later addition
• Prefer one integration or path over several, if it's enough to test the mechanic

Measuring what the release was meant to prove

A release scoped around a single outcome is only useful if the team actually checks whether that outcome occurred. This means defining, in advance, a measurable signal tied directly to the outcome rather than to general activity. For the scheduling example above, a meaningful signal is the proportion of booking links that result in a confirmed time, not the number of times the link was opened or the tool was mentioned favourably.

Measurable product outcomes also need a decision attached to them, not just a number. Before the release goes out, it's worth agreeing what result would prompt the team to expand scope, what result would prompt a change of approach, and what result is ambiguous enough to warrant more time before deciding. Without this agreement, teams tend to interpret ambiguous results as confirmation of whatever they already wanted to build next.

This is also where GOV.UK's prioritisation guidance is useful beyond the initial release: deciding what to build next is treated as an ongoing exercise in weighing evidence of need against effort, not a one-time scoping exercise that ends once the first version ships.

How IVRYN treats scope across its own portfolio

IVRYN is an independent product studio based in Paris that maintains a small portfolio of separate products, including Imryn, Datvero, Cascads, Reef, Flare, Sealed, Crucible CLUB and Victor Laybats, each with its own domain, audience and product page. The studio's editorial position is to document how focused products are researched, designed, shipped and improved without inflating claims, and this article reflects that stance rather than a report on any specific outcome achieved by those products.

No first-party study or customer result is claimed here; the reasoning in this article draws on general public delivery guidance and on the studio's stated preference for clear scope and measurable usefulness, not on internal data. Readers evaluating their own MVP planning should treat the worked example above as illustrative reasoning, not evidence of a tested method.

Because each IVRYN product occupies its own scope and audience, the studio's practical interest in this topic is straightforward: a release that tries to serve too many outcomes at once is harder to evaluate honestly, whether it is a scheduling tool, a content product, or something else entirely.