What is an MVP in product development

What is an MVP in product development, exactly

An MVP, or minimum viable product, is the smallest version of a product that lets a team test a specific assumption about real usage with real users, and gather evidence before committing to a larger build. The word 'minimum' refers to scope, not quality: an MVP still has to work, still has to be usable, and still has to solve the problem it targets. The word 'viable' is the harder part, because it means the release has to be complete enough that someone can actually rely on it for the task at hand, not just look at it.

The confusion around this term usually comes from treating MVP as a synonym for 'rough draft' or 'demo'. A demo can be faked; an MVP cannot, because its entire purpose is to produce trustworthy signal about whether people use it and whether it changes their behaviour. If the release is too thin to generate that signal, it has not actually functioned as an MVP, whatever it was called internally.

It also helps to be precise about what an MVP is not. It is not a prototype, which exists mainly to test a design idea internally or with a small group before any real commitment to build. It is not a proof of concept, which exists to answer a narrow technical question such as whether an integration or approach is even feasible. An MVP sits downstream of both: it assumes the idea is worth trying and the technical approach is plausible, and it tests whether the product earns real use.

The decisions an MVP is meant to de-risk

The reader question worth sitting with is not 'what is an MVP' in the abstract, but which decisions one actually protects a team from getting wrong. Three decisions come up repeatedly. The first is scope: whether the problem the team believes it is solving is the problem people actually have, at the priority level assumed. The second is workflow fit: whether the proposed solution slots into how people already work, or requires behaviour change that will not happen. The third is investment sequencing: whether it makes sense to build the next layer of features, or whether the current layer already reveals a dead end.

None of these are questions a spec document, a roadmap discussion, or a well-designed mockup can answer on its own. They require observing what happens when the product is actually used for its intended task, even in a limited way. That is the specific risk an MVP reduces: the risk of investing months of engineering and design effort into an assumption that was wrong from the start, discovered only after the cost has already been paid.

An MVP does not de-risk everything. It says little about long-term retention, pricing tolerance, or how a product will hold up at meaningfully larger scale or under adversarial use. Those require different kinds of evidence gathered later, usually from a product that has already cleared the more basic bar of being useful to a first group of real users.

A worked hypothetical: deciding what belongs in the first release

Consider a hypothetical example. A small team believes freelance operations managers waste time reconciling client invoices across spreadsheets and email threads, and wants to build a tool for it. Before writing a single line of code for a full platform, the team needs to decide what the smallest viable version of this idea looks like, and what it must accomplish to count as a real test rather than a wasted release.

In this hypothetical, the team might choose to ship a single-purpose tool that only imports invoices from one common export format and flags mismatches against a client-provided total, with no dashboards, no user accounts beyond a single login, and no support for multiple currencies at launch. The test is not whether the tool looks polished. The test is whether operations managers actually upload real invoices, return to do it again the following week, and stop maintaining the manual spreadsheet they used before.

This example is illustrative only, not a claim about any product IVRYN has built or observed. It is meant to show how an MVP definition translates into a concrete scoping decision: what to cut, what to keep, and what evidence would count as a genuine answer rather than a comfortable one.

A simple decision aid for this kind of scoping conversation is to ask three questions about any proposed feature for the first release: does removing it make the core task impossible to complete, does keeping it delay shipping past the point where feedback is still cheap to act on, and would its absence make the test dishonest by hiding the real problem. A feature that fails the first question and passes the other two is usually safe to cut from the MVP.

• Does removing this feature make the core task impossible to complete?
• Does keeping it delay the release past the point where feedback is still cheap to act on?
• Would its absence make the test dishonest by hiding the real problem being tested?

Principles that keep an MVP honest

Problem clarity comes first. An MVP built against a vague or shifting problem statement will produce ambiguous results no matter how well it is executed, because the team will not know what a positive or negative signal actually means. Writing the problem statement down in one sentence, and checking that every feature in the release maps back to it, is a low-cost way to catch scope creep before it starts.

Small, testable releases matter more than technical minimalism for its own sake. The goal is not to build as little as possible; it is to build the smallest thing that produces a trustworthy answer to a specific question. Sometimes that requires more functionality than a team expects, particularly when the task being tested has a natural minimum complexity, such as handling payments or scheduling.

Accessible interfaces are easy to deprioritise under time pressure, but an MVP that is hard to use will generate noisy or misleading feedback, since people will struggle with the interface rather than reacting to the underlying idea. Keeping the interface straightforward, even if visually plain, protects the integrity of the test itself.

Measurable product outcomes close the loop. Before release, it is worth deciding in advance what evidence would count as a signal to continue, adjust, or stop, rather than deciding after the fact based on whichever numbers look most favourable. This is less about picking a single metric and more about being honest with the team about what would actually change the plan.

How IVRYN's public product context bounds this advice

IVRYN is an independent product studio based in Paris that maintains a 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. This article reflects the studio's general editorial position of documenting how focused products are researched, designed, shipped and improved without inflating claims, rather than describing the results of any specific product's launch.

The advice here is bounded accordingly. No first-party study, user test, or outcome measurement from an IVRYN product is being cited, and none should be inferred from this article. The worked hypothetical above is a teaching example, not a case study, and the principles are offered as a general framework consistent with the studio's stated preference for clear scope, measurable usefulness and responsible automation, not as evidence drawn from a particular launch.

For readers who want a more structured comparison of the terms used loosely around 'MVP', including how it differs from a prototype or a proof of concept in scope and purpose, that distinction is covered separately and referenced in this article's evidence sources rather than repeated in full here.

A short checklist before calling something an MVP

Teams often disagree about whether a given release qualifies as a real MVP or is really an unfinished internal demo mislabelled for optimism. A short checklist can settle most of these disagreements without a long debate.

If a release satisfies most of the items below, it can reasonably be called an MVP. If it fails several, it is probably closer to a prototype or an internal proof of concept, and should be treated that way, with different expectations for what its results actually mean.

• It solves one clearly stated problem for a specific type of user, not a general vision.
• A real person outside the team can complete the core task without being walked through it.
• The team has decided in advance what result would count as a signal to continue or to stop.
• It excludes features that are nice to have but not required to test the core assumption.
• The team is prepared to act on negative results, not just positive ones.