Before we begin, let us define the concept of MVP (Minimum Viable Product) briefly and precisely.
An MVP is the execution of an experiment designed to validate or refute a relevant hypothesis, with the objective of reducing uncertainty and obtaining actionable learning about the product, users, the market, or the problem to be solved. This experiment does not necessarily have to be a product
This definition may come as a surprise. A quick search on the Internet reveals many interpretations that present the MVP as something integrated into Scrum, even as a possible substitute for the Sprint Goal, the Definition of Done, or the Increment. Although very common, this interpretation is a bad practice that distorts both the Scrum framework and the MVP concept itself, as well as its real usefulness within a project or organization.
When we read “Minimum Viable Product”, we tend to think automatically about product, small features, and value. But the MVP is not primarily about that. It is about testing a hypothesis that does not need to materialize as a viable or even usable product.
It is important to be clear about what an MVP is NOT. MVP and Scrum are completely different concepts, although they can complement each other to facilitate the iterative delivery of quality value.
MVP is not part of the Scrum standard. Therefore, doing Scrum does not mean that you are applying MVP. To begin with, MVP comes from Lean. Scrum has moved closer to Lean in recent versions, especially in its strong emphasis on eliminating waste throughout the iterative process of building a product.
In 2011, Eric Ries introduced the MVP concept within Lean and defined it around three basic pillars: learning, hypothesis validation, and decision-making. What must be clearly understood here is that MVP does not explicitly focus on the “product”; it focuses on learning.
Scrum is strongly focused on product and value increments. When MVP is introduced, the first instinct is often to think in terms of features and tangible value. But MVP is not that. MVP is a tool that helps teams improve how they work in order to achieve better outcomes. To do so, it is necessary to create an environment in which continuous learning, hypothesis testing, and the possibility of failure—so that another direction can be tried—are possible, accepted, and even encouraged.
Some more concrete implications of this perspective, which help clarify what an MVP is NOT, include the following:
The use of the MVP concept is not merely about building faster or cheaper, but about making better decisions in uncertain environments. In product development, the main risk is not speed or the number of deployed features, but building something that does not provide real value to the organization.
In this context, MVP should be considered a product governance tool. It allows uncertainty to be reduced and product evolution to be guided by evidence obtained from the real world—users actually using the product. The objectives of MVP can be summarized in one central idea:
Ensuring that we are moving in the right direction when building our product.
A more detailed list of objectives includes:
This learning must be based on observable evidence of usage and behavior, not only on internal opinions or intuition. The result is a tangible outcome that enables informed decisions about product evolution.
Using MVP to govern product creation brings several key benefits:
However, ignoring the three pillars of hypothesis, experiment, and learning leads to the scrumification of MVP: turning it into just another artifact or ritual within the Scrum cycle. This confusion creates friction with established practices such as the Sprint Goal or the Definition of Done and undermines both MVP and Scrum.
MVP does not replace Scrum nor overlap with it; it complements it. Scrum provides the framework to build quality increments, while MVP provides the criteria to decide which increments are worth building and with what learning objective.
Many Scrum teams see MVP as something that can be added as yet another artifact to their regular practices. At this point, there is a risk of treating MVP as a list of items that deliver value each Sprint. Unfortunately, this simplifies the real purpose of MVP—which is to enable learning, not to deliver cyclical value.
MVP does not change the Scrum framework. Core concepts such as Increment, Sprint Goal, or Definition of Done remain fundamental. The challenge is understanding how hypotheses, experiments, and learning can coexist without introducing bias into team operations or stakeholder communication.
Scrum has a clear and easily understood focus for teams: delivering value iteratively—though not necessarily in every Sprint, as the concept of release reminds us—even if the increments are small. This results in artifacts and activities centered on selecting viable product increments that move the product forward toward being scalable, secure, and useful.
MVP focuses on learning and on how that learning can positively influence the reduction of uncertainty, guiding the Product Owner toward better decisions about product evolution.
If we understand MVP as a tool for reducing uncertainty, we can adopt the mindset that reducing uncertainty does not always mean advancing in business value increments. Some decisions cannot be made simply by adding more value, but by stopping and questioning whether what we have built is generating the right value to continue evolving the product. Resolving uncertainty has a positive impact on identifying the correct path for product evolution and its features.
MVP relates to discovery in the same way Scrum relates to the Sprint. In other words, MVP aims to resolve uncertainty by testing hypotheses in order to discover whether they are valid or merely market illusions. That said, MVP is not a discovery framework—discovery can be fully integrated into Scrum. MVP is a tool focused on discovery, not on producing unvalidated value.
When Instagram decided to test whether publicly displaying likes caused stress among users, the goal was not to deliver new product value, but to resolve a doubt that could shape the product’s future. It is therefore reasonable to assume that, alongside Sprint Goal–aligned functionality, they deployed a small and simple experiment to validate or refute their hypothesis.
This way of thinking—at both team and organizational levels—creates an environment in which increments can be deployed where value is complementary to other needs, and where teams have space to learn about the product and the market in order to evolve in the best possible direction.
To conclude this section, the ultimate goal of learning is not learning for its own sake, but reducing uncertainty enough to make better product decisions. MVP does not replace or weaken Scrum commitments; it coexists with value-oriented increments within the same working cycle.
As mentioned earlier, MVP is based on three core pillars: hypothesis, experiment, and learning. In this section, we will look more closely at each of them.
A hypothesis is an assumption initially believed to be true but requiring validation—either confirmation or refutation. Throughout a project, doubts may arise about whether a feature or a particular product direction is actually the right one.
With MVP, we formulate hypotheses designed to resolve these uncertainties. The collection of hypotheses that emerge over time must be prioritized, as some are more critical to the product’s future than others. Based on this prioritization, we decide which hypotheses to execute within the current workflow.
The Product Owner governs the hypotheses. Their responsibility is twofold:
An experiment is the execution of a hypothesis in order to validate it. Scrum can serve as an execution vehicle for experiments. An experiment may fit within a Sprint so that the team can build it and users can test the hypothesis being addressed.
An experiment does not have to be confined to a single Sprint; it may span multiple Sprints. It is also important to recognize that an experiment may or may not produce direct product value. However, the learning derived from it always has value for both the team and the business.
The primary goal of an experiment is to validate or refute a hypothesis. In practice, this is not always achieved. Hypotheses may be incomplete, experiments may surface new uncertainties, or results may only partially validate the original assumption—leading to reformulation or the creation of new hypotheses.
Learning is what emerges from executing the experiment: the insights or information that confirm or refute the hypothesis. This learning may influence what is shown at the Sprint Review, modify the Product Backlog, or even impact future Sprint Goals.
Learning is a shared responsibility. The team learns by building experiments that may shape the product’s evolution. Stakeholders learn by seeing assumptions about users, business, or market validated or refuted. The Product Owner learns by gaining a clearer understanding of what the product truly is at each step.
Working with prioritized hypothesis lists implies that different people hold different responsibilities at different stages of the process.
This involves prioritization, experiment construction, real-world testing, and information gathering—ensuring alignment with Scrum. It is a collective effort involving all project participants, including the business.
The Product Owner is primarily responsible for collecting and prioritizing hypotheses. However, this does not mean acting alone. Stakeholders provide critical context, constraints, and business objectives that inform hypothesis creation.
The Product Owner actively incorporates—rather than delegates—stakeholder input. Final responsibility for prioritization remains with the Product Owner, based on product risk and uncertainty, not technical effort.
Once a hypothesis is selected for validation, the Scrum Team is responsible for designing and building the experiment in the most appropriate technical way. The team does not decide which hypothesis is prioritized nor how results are interpreted.
After deployment, focus shifts to users or the market. Stakeholders engage with the experiment, while the team supports technically as needed. The outcome is measurable information—KPIs, metrics, and evidence—that enables hypothesis validation.
Finally, based on validated or refuted hypotheses, the Product Owner interprets the learning and makes decisions about product direction—whether to continue, pivot, or further investigate. These decisions often impact Scrum artifacts such as Sprint Goals, the Product Backlog, and Increments.
To conclude, one key idea must be emphasized: MVP is not a technique that belongs to the Scrum framework, nor an activity or artifact that can simply be added to it. Understanding MVP in this way is a bad practice that distorts both its purpose and Scrum itself.
MVP is a strategy aimed at reducing critical uncertainties that can severely affect product evolution. Its focus is not on increasing functionality, but on providing a value perspective based on risk reduction through real evidence.
Through explicit hypotheses, well-designed experiments, and the learning derived from them, MVP forces teams and organizations to confront an often uncomfortable reality: making decisions. When used rigorously, MVP does not replace Scrum or weaken its commitments—it complements product governance. But it only works when there is a genuine willingness to learn and to act accordingly.
![calaix[À]gil.com](/img/logo.png){kind=logo}
