Minimum Viable Product (MVP)
A Minimum Viable Product (MVP) is a released version of a product, cut back to the smallest set of features able to test a hypothesis with real customers. That version goes into service with early adopters and its use is measured; the measurement then settles what happens next, between extending the product, revising the hypothesis and giving up. The term comes from Frank Robinson in 2001 and owes its currency to Eric Ries's Lean Startup. The Agile Extension to the BABOK Guide files the technique under product management and refinement, among those practised with the delivery team and with stakeholders outside it.
Goal
The technique keeps the smallest set of features that delivers value to early adopters, puts it into service as quickly as possible, then reads the answer in their behaviour. An MVP answers a question of direction: does the product under consideration interest enough customers to be worth building in full? The Agile Extension gives it the intent of avoiding the cost and risk of developing the wrong product. The guide places it on the strategy horizon, where it serves to prioritise the allocation of resources and to speed up organisational learning.
The problem it addresses is the one-shot bet: an organisation picks a product, funds all of it, delivers it eighteen months later and discovers that the use is not the one it assumed. A market analysis moves part of that risk without lifting it, because it records what people say they would do. The MVP puts observed behaviour in place of the statement: adoption, payment, repeat use.
The technique produces two deliverables. The first is the version put into service. The second is the validated learning: the measurement obtained, set against the threshold, then the decision that follows from it. A reduced version released without a measurement has paid for a cut in scope and taken nothing back.
Usage
When to use it
- A new product whose demand is still an assumption: release the core to early adopters and read their actual use.
- A service whose price has never been put to a customer: test the willingness to pay before building the full offering.
- A feature the team and the sponsor rate differently: settle it by a usage measurement rather than by an opinion.
- Entry into an occupied market: test the differentiation on a narrow segment before general availability.
- A tight budget and a tight deadline: obtain customer feedback before committing the rest of the money.
When not to use it
- A simple solution, with no uncertainty about its use: the complete product is already the smallest viable product, so write the user stories of the solution straight away.
- No access to real customers: without observed use the technique loses its object, so test the demand through a survey or questionnaire or a market analysis.
- A partial version impossible to expose for security or compliance reasons: test the intent through throw-away prototyping or a simulation.
Description
Where the technique comes from
Frank Robinson coined the term in 2001, within his synchronous development method: the product to build is the one whose ratio of expected return to risk is highest, large enough to bring about adoption, satisfaction and sales, small enough to keep it from becoming bloated and risky. Eric Ries gave it its current formulation and its reach in 2011: the version of a product that allows the maximum amount of validated learning about customers to be collected for the least effort. It is this second definition that the Agile Extension takes up, without naming it.
The guide titles its entry "Minimal Viable Product". The original literature, the Agile Alliance glossary and practitioner usage say "Minimum", the form used here; a reader going back to §7.6 will find the other spelling for the same technique.
The four elements
| Element | What goes on it | What gives away an error |
|---|---|---|
| Target audience | The market segment and, inside it, the early adopters the version will be offered to, with the expected headcount and the problem they face today. | "Our customers": an audience of unknown size supports no rate at all. |
| Goal to achieve or hypothesis to test | A statement about the behaviour of that audience, carrying a threshold and an observation horizon. | An intention of the team, of the "improve the experience" kind, that no measurement can disprove. |
| Mechanism to measure learning | The objective measurement chosen, the system that produces it, the observation period and the threshold attached to each possible decision. | A measurement chosen after the release, from among those that show well. |
| Defined requirements | The smallest set of requirements that makes the release and the measurement possible, derived from the three rows above. | A list drawn from the existing backlog, to which a hypothesis is attached afterwards. |
The guide states that the amount of requirements is subjective and dependent on context, with two bounds: enough has to be produced to validate the hypothesis, and it has to be the minimal amount that releases the solution quickly. A team that starts by cutting into its backlog therefore never arrives at an MVP. Where the instrumentation is missing, the metrics and key performance indicators come before the mechanism to measure learning.
The three steps
- Determine the problem to be solved and state the hypothesis
The problem is established from what the early adopters live with. The hypothesis says what one believes to be true of their behaviour if the solution existed. - Identify the smallest set of features that puts that hypothesis to the test
The guide asks for creative, low-cost options to test with the target market. A page describing the offering with its price and a sign-up form measures a willingness to pay without a line of the product's code being written. - Analyse the validated learning to decide what comes next
The measurement is set against the threshold. The feedback also covers the feasibility of the solution and the further features needed to widen adoption.
The numbering reads like a straight line; the guide describes successive cycles, the feedback being collected and analysed before further features are delivered. Step 3 therefore leads back to step 1 when the measurement invalidates the hypothesis, to step 2 when it confirms it and a wider scope is warranted.
Writing a hypothesis that can fail
A usable hypothesis holds four things: the audience concerned, an observable behaviour, a quantified threshold and a horizon. "Fiduciary firms will appreciate having the VAT return prepared automatically" holds none of them. "At least 30% of the pilot fiduciary firms take out the paid option at the end of the six-month trial" holds all four and can be disproved by a figure.
The threshold is set before the release, with the sponsor, because it answers a funding question: from what rate onwards is the next stage paid for? Three decisions hang on the same figure: carrying on, reworking the hypothesis and stopping, each with its own band of values. An adoption rate of 12% can be argued in front of a steering committee as encouragement as readily as failure.
How to choose the smallest set of features?
The guide is explicit: there is no formula, and the desired features are a best guess. Two questions are enough to sort the candidate features. Without this feature, can the hypothesis still be put to the test? Without it, would the measurement be distorted? A security requirement, a legal obligation, the accuracy of a calculation or an acceptable response time come in through this second door. Kano analysis sorts the same candidate features by the satisfaction they produce and separates those the two questions leave tied.
The quality level is therefore set by what an honest test requires. A botched version confuses two causes of abandonment, the defect and the lack of interest, and makes the measurement unusable for the sake of saving a few days. What stays outside the scope is written down, with the features named one by one: without that list, the discussion about scope starts again at every backlog refinement.
The guide notes as a limitation that the technique requires advanced market analysis to identify the feature set the early adopters need. This is the hidden cost of an MVP: the segmentation work, often supported by personas and interviews, happens before the first line of code.
MVP, prototype and minimum marketable product
Three neighbouring objects are told apart by their audience and by the criterion that judges them. A prototype shows a feasibility or an intent; it circulates inside the organisation or in front of a panel assembled for the occasion, and it is judged on opinions. An MVP is a version in service, offered to real customers under their usual conditions, and it is judged on measured behaviour. The minimum marketable product is the smallest set that sells; the Agile Alliance glossary fixes the difference by purpose, learning for one and revenue for the other.
An MVP whose hypothesis is disproved has done its job, since it spared a full build; a minimum marketable product that does not sell has failed.
What makes the technique fail
The reduced version with no hypothesis
The guide says so among its limitations: the technique is about testing an initial hypothesis. A team under deadline pressure cuts features, delivers the rest and calls it an MVP. No threshold was written and no measurement was set up.
Step 3 skipped
The version goes into production, the team moves on to the next iteration and nobody works through the measurement. The cost of an MVP is paid up front, in scope given up and in instrumentation; it pays back at step 3. The remedy is an appointment fixed at the moment of release, on the closing date of the observation period, with the sponsor.
The audience too wide
Opening the version to every user drowns the signal from the early adopters and exposes a deliberately reduced version to customers who expected something else. A named cohort, a feature flag and a communication that presents the version for what it is: these three things hold the exposure under control.
The MVP promoted to finished product
The measurement is good, the version stays as it is and the shortcuts become the foundations of the product. Working through step 3 settles two things: what gets built next and what gets rebuilt because it was only ever built to last eight weeks.
AI considerations
A language model is useful at both ends of the technique. At framing, it produces candidate hypotheses from a problem statement and a description of the target audience; what interests the analyst are the ones the room had not formulated. It suggests low-cost test options, what the guide calls for at step 2, and it lists the events to instrument so that the measurement exists on the day of release. Asked feature by feature, "which hypothesis does this feature put to the test?", it brings out the ones that test none. At the analysis, it groups the free-text comments from early adopters by pattern and flags those that contradict the quantitative measurement.
The threshold is not asked of a model. Pressed to produce one, it will return a plausible percentage that comes out of no decision the company made, when that figure commits a budget. The same pitfall applies to the verdict: a model asked whether the MVP succeeded will build a favourable account from the same data, which the threshold written in advance renders harmless. The usage data collected during the observation identifies customers and sometimes amounts, so personal data within the meaning of the Federal Act on Data Protection (FADP); it is anonymised before any transfer to an AI service hosted by a third party, and the hosting is checked when the processing leaves Switzerland.
Code generation changes the economics of the technique. Building a reduced version costs less than it did, which weakens the guide's cost argument and leaves the value on the measurement side: the hypothesis, the threshold and the analysis remain the business analyst's work.
Examples
A French-speaking Swiss accounting-software vendor wants to know whether fiduciary firms will pay for the VAT return of their mandates to be prepared automatically. The definition sheet below is the deliverable the technique starts from.
| Element | Content settled |
|---|---|
| Target audience | Fiduciary firms in French-speaking Switzerland with 2 to 10 staff, already customers, whose mandates fall under the net tax rate method. 40 firms approached, 20 taken into the pilot. |
| Hypothesis | At least 30% of the pilot firms take out the option for at least one mandate, at CHF 15 per month per mandate, at the end of the six-month trial. |
| Mechanism to measure learning | Share of firms having taken out the option for at least one mandate at the end of the trial, read off the billing system. Observation period of six months, set to cover one half-yearly return deadline per mandate. Secondary measurement: proportion of returns generated and then filed without manual correction. |
| Defined requirements | Import of the general ledger from the accounting module; calculation of the half-yearly return under the net tax rate method, at a single rate; consistency check against the turnover booked; export of the form for entry in the portal of the Federal Tax Administration (FTA). |
| Out of scope | Effective reporting method; mandates with several rates; direct filing with the FTA; retroactive corrections; annual turnover reconciliation. |
| Decision by measurement | 30% and above, meaning 6 firms out of 20: opening to the whole installed base. From 15% to under 30%: a further period at CHF 8, with price as the assumed cause. Under 15%: the option is dropped. |
- Calculating the half-yearly return under the net tax rate method
- Importing the general ledger
- Exporting the FTA form
- Consistency check against the turnover booked
Out of scope
Neither criterion admits them.
- Effective reporting method
- Mandates with several rates
- Direct filing with the FTA
- Retroactive corrections
- Annual turnover reconciliation
Visualisations
The first drawing is the loop: problem and hypothesis, smallest set of features, release to early adopters, measurement of learning, then decision. The line that has to show is the one running back from the decision to the hypothesis rather than to the feature list.
A second drawing serves the sorting of scope. The candidate features are laid out in three zones: those that put the hypothesis to the test, those that keep the measurement honest (security, compliance, accuracy of a calculation) and those waiting outside the scope. What has to show is the second admission criterion, the one through which a requirement unrelated to the hypothesis still enters the released version.
Cost
| Phase | Level | Rationale |
|---|---|---|
| Preparation | Medium | Segmentation and identification of the early adopters, which the guide gives as a demanding prerequisite, then writing the hypothesis and obtaining the sponsor's agreement on the decision bands. A few days of analysis, more if the segment is not already documented. |
| Execution | High | A real production release, with the level of quality, security and support of a version exposed to customers, plus the instrumentation of the measurement and an observation period set on at least one full cycle of the measurement chosen. |
| Documentation | Low | A one-page definition sheet and a measurement reading at the end of the observation. The decision taken is recorded in a few lines. |
Tooling
The feature flag (LaunchDarkly, Unleash or the mechanism built into the development platform) is the tool specific to the technique: it opens the version to a named cohort, closes it again in one operation if a defect appears and separates deployment from exposure. Without it, exposure is regulated by successive deployments, which costs a great deal and takes away control over the audience observed.
Usage measurement tools (Matomo, Piwik PRO, Amplitude and their equivalents) produce the rate that will be set against the threshold, provided the events are instrumented before the release.
A/B testing tools (Optimizely, VWO, GrowthBook) serve the variant where two propositions are exposed in parallel, covered under A/B testing. They bring the random split of the population and the significance tracking that usage measurement tools do not offer on their own.
Page and form tools (Webflow, Typeform, Jotform) carry the low-cost test options of step 2: an offer page, a displayed price and a form.
Backlog management tools (Jira, Azure DevOps, GitLab and their equivalents) house the definition sheet and the out-of-scope list, provided a field carries the hypothesis each selected item targets. That link makes it possible, at step 3, to say which features the measurement served to decide. A spreadsheet is enough for the sheet itself, which is read out in the decision meeting.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.6 Minimal Viable Product: the purpose of the technique, the definition of the smallest set of features, the four fields of application, the three steps, the four elements, the strengths stated and the limitations, among them the absence of a formula, the prior market analysis and the case of the simple solution.
- Eric Ries, The Lean Startup, Crown Business, 2011, chapter 6: the definition in use, the version of a product that allows the maximum amount of validated learning to be collected for the least effort, and the build, measure, learn loop.
- SKMurphy, Frank Robinson's Minimum Viable Product Definition: a documented account of the definition by Frank Robinson, who has been credited with the term since 2001, and of its sizing by the ratio of expected return to risk.
- Agile Alliance, glossary, Minimum Viable Product (MVP): the form of the term the profession has settled on and the distinction between the MVP, aimed at learning, and the minimum marketable product, aimed at revenue.