A minimum viable product, or MVP, is the first instance of a product: the smallest set of features expected to deliver enough value to early customers that they engage with it, while the company learns, validates its assumptions and steers what to build next.
The MVP is minimal in scope, not in quality. It is not a prototype or a proof of concept: real customers use it, in real conditions. And its V is a hypothesis, the team’s best-evidenced estimate of what will prove viable, released early enough for the market to answer. This guide gives the definition, the reasoning behind it, and the method for defining a great one, whether you are meeting the term for the first time or scoping your next release.
Passages marked From the book are quoted from Innovation Mode (Author’s Edition, 2026); the method is Chapter 8’s.
What does minimum viable product mean?
When a team defines a new product, there is usually a surplus of feature ideas, and deep uncertainty about which of them matter: market demand must be estimated, user behaviour assumed, and novel features have, by definition, never been validated in real-world conditions. The team faces three questions. How might we minimise the risk of releasing a non-viable product? How can we ensure that only the most valuable features are in the first release? How can we tell if the defined product is too big, too expensive, too risky?
The minimum viable product is the answer. The term was coined by Frank Robinson and popularised by Steve Blank and Eric Ries, who defined the MVP as the version of the product that can bring “the maximum amount of validated learning with the least effort”. In Innovation Mode, we interpret that definition for the corporate product team:
Interpreting the above definition, a minimum viable product describes the first instance of a product consisting of select features that are expected to provide sufficient value to early customers so they engage with the product while the company obtains essential feedback and insights to learn, validate assumptions, and steer the product improvement process.
Every word of that carries weight. First instance: the MVP is a product, released to the market, not a trial run. Select features: the smallest subset that solves the problem, significantly cheaper and faster to build than the full product. Early customers engage: viability means real engagement, not a complete feature list. And the company learns: the release opens the feedback loops that make everything after it insights-driven rather than assumption-driven.
One more thing the definition quietly admits: nobody knows in advance whether the chosen set is right.
Obviously, for a given product concept, the definition of its MVP is only an estimation; it is what the team believes will be proven viable: the “V” in “MVP” is an additional hypothesis to be tested.
That is the honest reading of the term, and the one that makes the method below necessary. For the long-form discussion of the definition and its misconceptions, see The True Meaning of the Minimum Viable Product.
The real risk is not building small. It is learning too late
When building a new product, the real risk is releasing a non-viable first instance too late.
Picture the alternative. A team makes a significant investment and spends a long development cycle building an ambitious product, only to find at launch that it fails to engage users. The product may not be solving the core problem, and the team is the last to know; they learn it at the most expensive possible moment. With the investment already made, the product may not be fixable, the option to pivot may be too costly, the interest of early adopters may have passed, and the product’s reputation, and the team’s belief in it, may already be damaged.
The MVP approach inverts that sequence. A good, inexpensive first release limits the financial damage of a failed launch and, more importantly, preserves the resources and the options to react: with feedback arriving from real users in real conditions, an initially unsuccessful launch can be turned into a successful product through fast iterations. As the book puts it, “building a good, inexpensive first release preserves degrees of freedom for the product”.
High-performance product teams excel at exactly this: identifying the smallest set of features that, on the available knowledge, will satisfy a critical mass of customers, then learning quickly through frequent improvements. Minimal scope is not the goal. Early, inexpensive learning is.
Not a prototype, not a proof of concept
Contrary to a popular misconception, an MVP differs from both a prototype and a proof of concept. The difference is the audience: prototypes and proofs of concept are reviewed by experts and stakeholders, while an MVP is exposed to real customers, so it must be close to production-ready, with the security, reliability and polish that implies.
| Artefact | What it answers | Who uses it | Production readiness |
|---|---|---|---|
| Proof of concept | What it answers: Is this idea or technology feasible at all? | Who uses it: Domain experts and decision-makers | Production readiness: None; often throw-away code |
| Prototype | What it answers: How should the product look, feel and behave? | Who uses it: Stakeholders, and users in tests | Production readiness: Selected aspects only |
| MVP | What it answers: Will real customers engage with this product? | Who uses it: Real customers, in real conditions | Production readiness: Close to production-ready |
Getting these terms right matters because each one sets different expectations with sponsors, customers and partners. What is a prototype? maps every artefact on the book's two dimensions, production readiness and functional completeness; Prototype, MVP or proof of concept? walks through the differences one by one, and the software prototyping guide covers how to build prototypes in days.
How to define a great MVP: the seven steps
Defining an MVP is not a straightforward process. It requires a holistic view of the envisioned product, sound judgment, a deep understanding of the users and their needs, and market and technology savviness. Innovation Mode describes it as a structured process, led by experienced product managers and triggered by a sponsor who asks for a validated opportunity to be realised. Its output is a product definition document, with a prioritised backlog and the cutline that defines the MVP.
- Set the context. Start from the validated opportunity: the product concept, the insights and any functional prototypes produced by the validation work. Organise the project, scan the organisation for related ideas, projects and knowledge, and identify the domain experts and stakeholders the process will need.
- Understand the users. Review and enrich the existing user framing: personas, habits, pain points and needs, and what success looks like for each. Decide which personas matter most for this product, and trigger additional research, interviews, surveys or focus groups, where the gaps are.
- Understand the market. Study the demand, the structure and dynamics, and the competitive landscape: who has attempted to solve this problem, how well, and what customers do today instead. Distil market size estimates, trends and open-source intelligence into a single view the team can act on.
- Refine the product concept. Review, combine and enrich the candidate solutions into the product concept to be built, then decompose it into features. Where the concept is still open, AI-powered ideation, an open call to the organisation’s innovators or a design sprint widens the field before the team converges.
- Frame the complete product. Although the aim is a minimum product, it is a good strategy to think big, capture everything, prioritise wisely and review often. Capture every feature as epic user stories in the product backlog, then enrich each with rough size, complexity and urgency: how early the feature must exist for the product to solve the problem.
- Synthesize the MVP. From the complete backlog, select the best subset: the one least expensive to build and valuable enough for customers to engage with. The six-step method below makes this decision rigorous rather than instinctive.
- Define success. Choose the KPIs that reflect the product’s performance for the company, its users and its stakeholders, and assign goals to them, so success is described in numbers before the first line of code.
The cycle closes where Figure 1 shows an eighth node: the team reviews the MVP definition with key stakeholders and moves to implementation road-mapping, team formation and go-to-market planning. Building an MVP walks through the method step by step, from framing the problem to the measurement framework.
Choosing the features: the cutline, not a filter
The backlog now reflects what the team understands as the complete product. The synthesis step draws a line through it: everything above the line is the MVP, and everything below it is a candidate for the releases that follow. Features above the line are those ranked highest on user value, business impact, reach, feasibility and urgency; expensive and uncertain ones are flagged and questioned on the way.
To address frequent misconceptions, selecting a subset of features does not restrict the product by any means. In an agile world, the first release of a product initiates an ongoing process of frequent incremental improvements. Hence, the selection of features does not filter out items; it defines what to build first and what may follow through subsequent releases.
The book proposes a six-step method for drawing the line well:
- Obtain the high-potential feature set. Select the features scored high on value and impact; exclude those with limited feasibility and low urgency.
- Analyse it. Question the marginal entries, review the distribution of effort, and for the most expensive features look hard for cheaper alternatives: smaller features and low-tech workarounds that serve the same purpose.
- Cross-validate the selected features. For each one, ask: “Would the product be valuable (and viable) without this feature?” If the answer is not a definite no, reconsider the entry.
- Cross-validate the non-selected features. For each one, ask the mirror question: “Is this feature necessary for the first instance of the product?” If the answer is not a definite no, discuss, reconsider and justify any change.
- Invite independent review. Ask evaluators and product experts outside the team to assess both sets, thinking as users and as entrepreneurs.
- Summarise and validate the scope. Write a one-page executive summary of the product built only on the selected features, and use it to challenge the scope with users in the organisation.
Selection is not the only lever, and the second one is missed most often: each feature also has a depth, how far its first implementation goes. A feature can enter the MVP as a low-tech workaround, as a standard build, or at full depth, and the method sets the dial on the way in: analyse the most expensive features and “try to find cheaper alternatives, such as smaller features and low-tech workarounds, which can still serve the purpose in an inexpensive way”. The features at the core of the product earn full depth first; most others earn theirs release by release.
One rule survives contact with every budget conversation. When the chosen MVP looks too expensive, the easy decision is to cut its scope, and it is usually the wrong one:
If the MVP is too expensive for the company to develop, the team should focus on finding less expensive implementation options, technical alternatives, or workarounds for the included features. For example, there may be less fancy or less technologically advanced solutions that serve the same purpose.
Change how the features are built, not whether the problem gets solved. A cheaper implementation of the right scope beats a polished implementation of the wrong one.
Defining success before you build
The product definition is not complete until the team has said what a successful product looks like and how its performance will be measured. That means KPIs covering both sides of the product’s purpose, the value generated for the user and the benefit created for the company, with explicit goals assigned to each: engagement, growth, satisfaction, market share, revenue and profitability prospects, as the product warrants. Value is not always revenue, and a snapshot rarely settles the question; a product’s growth dynamics can say more than any single month’s numbers.
Everything the process has produced is then packaged into one solid artefact: the Product Definition Document, holding the problem, the final scope, references to the backlog, and a roadmap that puts what to build first and what follows in perspective. That document is where the MVP method hands over to product requirements: How to write a PRD covers the structure, and the Product Toolkit provides the templates and a complete worked example. For the stages before the MVP, the Product Concept Template and the Business Experiment Template carry an idea from framing to validated opportunity.
What changes in the age of AI
The reasoning behind the MVP has not aged; the mechanics have. Initialising a complete product backlog was a long process of workshops and post-processing. With AI in the loop, the book describes the team obtaining a detailed backlog of prioritised, grouped epic user stories in a single step, each enriched with the justification for its importance and its priority. The team’s work shifts from typing in user stories to understanding, refining and debating them, and the AI generates variations of the MVP on demand: scoped to a specific persona, or constrained by time or funding.
What AI does not change is the V. Only real customers, engaging with a real product in real conditions, can validate what the team believes. If anything, the economics sharpen the method’s point: when building is cheap, the discipline moves from building too slowly to building too much. The MVP FAQs answer the recurring questions, including whether MVPs are still relevant, and Ainna, the agentic innovation platform, runs this method end to end, from problem framing to an MVP definition with its backlog.
Further reading
- The True Meaning of the Minimum Viable Product: the definition unpacked, the misconceptions, and the characteristics of a good MVP.
- Building an MVP: the method step by step, from problem framing to the measurement framework.
- What is a prototype?: the artefact map by readiness and completeness, and how AI collapses prototyping time.
- Prototype, MVP or proof of concept?: every artefact from wireframe to pilot, and when each is the right one.
- MVP FAQs for startups: feature selection, costs, and the advice that holds for small teams.
- Software prototyping: what a prototype is for, and how to build one in days.
- How to write a PRD: the document the MVP definition becomes, section by section.
- The Product Toolkit: PRD deck and document templates with an annotated worked example.
- The Innovation Toolkit: the eight templates for every stage before the MVP.
Cite this guide
Krasadakis, G. (2026, November 2). What is a minimum viable product (MVP)?. Innovation Mode. https://theinnovationmode.com/minimum-viable-product
@online{krasadakis2026mvp,
author = {George Krasadakis},
title = {What is a minimum viable product (MVP)?},
year = {2026},
date = {2026-11-02},
organization = {Innovation Mode},
url = {https://theinnovationmode.com/minimum-viable-product}
}
