The term MVP appeared almost a quarter of a century ago. In terms of technology, this is a huge period. Over this time, the understanding of this term has become somewhat blurred, and its scope of application has expanded significantly. In this article, I will try to define the boundaries of the application of MVP software products based on modern technologies.

Let me clarify right away that I am considering the use of MVP primarily from a management perspective and specifically for IT products.

A bit of theory and history

It seems logical and correct to rely on the meaning and ideas that the author originally placed in a term. (In the early 2000s, Frank Robinson proposed the concept, and later, in the early 2010s, Eric Ries popularized it within the Lean Startup methodology.) As my experience shows, while the concept behind the term MVP is widely known, it is not fully understood by many.

Eric Ries provides the following definition: “MVP is that version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.”

Another definition found online states: MVP can be considered an early stage in any product development cycle. An MVP (Minimum Viable Product) is a product that has enough features to attract customers and use their feedback to validate the product idea.

I propose a thought experiment: let’s imagine hearing the definition of MVP for the first time and analyze it. Based on this definition, several key features of its application emerge.

• MVP is a business tool. It is a specific business decision, but it also acts as a tool or methodology for creating products.
• The term MVP applies only to new products. Below, I will elaborate on what can be considered a new product.
• MVP is a version of the product that end users will see, and they may even pay for it. It is not for internal use, not a demo for investors, and not a version for testing with a loyal audience.
• MVP is a hypothesis embodied in a product. Its primary goal is to gather information from customers. MVP is a hypothesis that can be confirmed or refuted with specific metrics (KPIs, which should be defined in advance. We will discuss this in the next section). An important implication is that the hypothesis may not be confirmed, and a full product might never be created.
• Launching an MVP requires a mechanism for collecting and processing customer feedback. This means that before starting MVP development, we must clearly determine how we will collect and evaluate the data. Without clear and understandable tools for gathering and processing customer feedback, launching an MVP loses its purpose, as it does not address its primary goal.

There are two additional characteristics of MVP that do not directly follow from the definition but are equally important:

• MVP is just part of a hypothesis. A business model or business plan is also necessary. Without them, evaluating results is impossible. MVP can only test the existence of a market niche for the product, but even in this case, profitability thresholds must be predefined.
• MVP is an element of flexible development methodology. Agile projects can exist without an MVP, but an MVP without Agile loses its purpose. Therefore, the entire product development and growth must occur within this methodology.

When discussing MVP, we are not referring to a direct software solution but rather a set of components and processes. It is more accurate to call it an MVP cycle or stage.

Components of MVP

When we talk about MVP, we often mean a service or program. From the perspective of a team member working on the project, this is true. However, from a business standpoint, the concept of MVP is broader, as it encompasses a range of parameters that influence the project's success or failure.

• Functionality. These are the basic features provided to users.
• UI/UX. The first point of user interaction with the product, influencing whether users engage with the offered functionality and continue to use the product.
• Back office. Not all projects can be limited to an app on a marketplace. Basic customer support functionality is often necessary.
• Infrastructure. IT products rarely exist in complete isolation. They often depend on other services and providers, impacting overall stability and quality.
• Market segment. The chosen market segment also affects the product's success.
• Pricing and business model. Initial conditions can be decisive for product promotion and significantly influence the project's fate.

Misunderstandings About the Concept of MVP

I believe almost everyone interested in the topic of MVP has seen an image like this or something similar. Unfortunately, I suspect its author might not have fully understood what MVP really is, leading viewers to misinterpret the approach. Ah, the power of art! :-)

Let’s analyze it and try to identify if there’s a mistake.

We see two interpretations. The first suggests creating a wheel, then another, then adding a body, and finally, driving. Thus, at the first stage, we do not get a product unless we intend to sell wheels, and the car is developed gradually. The final product only emerges at the last stage.

The image doesn’t tell us what customer problem we are trying to solve. Wheels and cars can even be used as flower pots. Maybe we’ll understand it better with the second image.

In the second image, we see an evolution from a skateboard to a car, and in some images, even to a truck. A preschooler’s task might be to identify what these objects have in common. They are means of transportation!

At first glance, this scheme seems to describe MVP well — from the very first step, we are already able to move.

Let’s take a closer look at this picture. First, each of the shown vehicles serves a specific purpose, each has its own customer, and often, their audiences do not overlap.
They are not evolutionary stages of each other’s development.

It’s worth noting that examples from the physical world, often used in articles and presentations, can hinder the perception of information or ideas as they follow different rules and principles.

In this case, the product remains fundamentally the same and continues to fulfill its main function but evolves with technological advancements and customer expectations. Note that Karl Benz's carriage MVP was technically primitive but simple to operate (by the standards of that time) and visually appealing as a finished product.

Efforts to convey ideas often resort to oversimplified examples, such as an MVP being represented as a brief instruction, presentation, or similar. These examples are exceptions rather than the rule and should not be used as real-world references.

Another mistake lies in the belief that an MVP is the smallest functional volume a team can deliver, sufficient to study product viability from a business perspective. In this case, the team focuses on minimizing the functional aspect of MVP, neglecting its viability. The delivered product lacks sufficient quality to ensure accurate evaluation of whether customers will use the product.

Teams may also confuse MVP with the Minimal Marketable Feature (MMF) or Minimum Marketable Product (MMP). Here, the team shifts focus from solving user problems to purely generating profit, often lowering product quality and leading to failure. Testing these hypotheses (MVP and MMF) must occur sequentially.

FAQ

By now, you may have some questions about clarifying or interpreting the concepts.

What can be considered a new product? For some, the answer may seem obvious. However, for companies offering similar solutions across different markets and platforms, answering this question might not be so simple. Naturally, there is no universally accepted definition of a new product. The necessary characteristics can be summarized into two:

• Novelty - from the perspective of technology or design.
• Uniqueness - the absence of direct market analogs, including in terms of positioning.

Can an improved version of an existing product, even presented under a different brand, be considered an MVP? Probably not, as there is no hypothesis to test. The audience is familiar, as are their expectations, and the product is no longer unique. A new generation of the product must at least be no worse in functionality than its predecessor, which means it cannot be classified as an MVP.

Is it always necessary to start with an MVP? No, it is not a mandatory element of Agile development but rather one of several possible approaches.

Should we be interested in all client feedback or a limited set of questions? Do we need to prepare a list of questions in advance? The Lean Startup concept clearly states that yes, the clearer we formulate questions, the more definitive the answers we will receive. It is also worth noting that, in addition to questions, we need a formulated hypothesis, which we test by releasing the MVP. Additional information is also important, but only as a supplement.

How to systematize and prioritize the collected information? Lean Startup offers several tools but does not limit your choices. Naturally, everything depends on the specifics and capabilities of your project.

The Agile Alliance explicitly recommends focusing on metric data first. Generally, early clients tend to be more loyal to developers, and what they do not say directly, you can observe in analytical data.

Manual data collection is acceptable but suitable only for a limited group and requires personal communication. Individual interviews can be helpful, but keep in mind that obtaining objective information requires structuring questions according to social survey principles. This demands a certain level of professional preparation for the interviewer and significant effort. Such costs may not align with the Lean Startup concept. Therefore, it is advisable to focus primarily on data collection and analysis systems, as well as online survey forms.

Prioritization of collected information is determined by its impact on the project's KPIs.

Should an MVP be developed using the same technologies that will be used to create the full-fledged product? The spirit of Lean Startup clearly states that no, it should not. However, keep in mind that an MVP may not consider constraints, including those related to scaling the main product. At the same time, what works as an MVP may be impractical as a full-fledged product or may require fundamentally different technologies. Therefore, I recommend using the same technological solutions for MVP development where possible, as this will help identify potential problem areas and tasks early in the implementation process.

Can the concept of MVP be used independently of other Lean Startup elements? As we can see, no. The MVP approach has a specific goal and assumes the use of other related components.

Economics of MVP

How much does an MVP cost?

There are no absolute values. Data from well-known startups suggest costs in the range of tens of thousands of dollars. What exactly this amount includes is often unclear. As we’ve learned, from the perspective of work volume and required specialists, it is a fully-fledged IT project. The project’s duration depends on how labor-intensive it will be to realize the idea and how much simplification can be achieved while preserving customer value.

It is important to forecast the total cost of the entire MVP cycle before starting. This forecast should include all expenses for creation, launch, and product support until the project is closed or a full version is created.

Where can you save, and where should you not?

Essentially, we need to create a decent product at a significantly reduced cost. Is this possible? Yes.

Where not to save:

• Security. Rarely does a project avoid handling user data. Even a minor data breach can cause irreparable harm to the project.
• Functionality. Focus on identifying the core functionality that reflects the product idea and concentrate only on that. For the rest, apply the Pareto principle. Take your backlog and evaluate each feature by two criteria: priority and labor intensity relative to the total backlog. For the MVP, select 20% of the highest-priority tasks and optionally add 20% of the most labor-intensive ones. This creates an optimal formal set, which can be further refined to form the final list, providing complete functionality.

Where to save:

• Scalability. This involves a set of technological solutions that always demand significant time and resources. Predict the maximum scale at which you can transition to a full version.
• Design (if it’s not a key project feature). While design is crucial, it can often accommodate different approaches to solving the same problem.

• Customization. Both in terms of UX and development, customization can be costly and may be omitted at this stage.
• Capital investments. Avoid any purchases or service payments exceeding the forecasted development period for the MVP. Opt for rentals and subscriptions with monthly payments instead.
• Data collection and analytics. Use third-party services like Google Analytics to provide the necessary minimum information with sufficient accuracy. If this isn’t possible, focus solely on collecting data critical for tracking your product's KPIs.

Is MVP Suitable for My Task?

First, you need to understand the ultimate goal you are pursuing and make a decision based on it.

If my goal is to validate an idea and minimize costs when investing in the development of a full-fledged product, and if I or my team understand that the result might be negative and the full product might never be developed, then MVP is the right choice for us.

Can I test the hypothesis with similar accuracy within the same or a shorter timeframe and with equal or lower costs? If not, then MVP is our solution.

Conversely, if the decision to develop the product is not up to you, or if you simply want to bring it to market faster and cannot prioritize the features to be implemented, then MVP is not the right approach for your case.

Lastly, ensure that your team is capable and ready to handle the entire MVP lifecycle. This is not as straightforward as it might seem at first glance.

Conclusion

In summary, MVP is primarily a business tool that requires expertise in using accompanying tools. It is not mandatory and is not suitable for all projects.

Its main purpose is to quickly bring a product to market to assess its potential. Its creation involves reducing costs as much as possible without compromising the overall quality of the final product. In projects where development costs are the largest expense, most savings are achieved by reducing functionality.

You will learn how the MVP creation cycle works in practice in the next section.