On the Internet, the environment changes at the speed of light: technological advances constantly appear that offer new opportunities; users not only adapt faster to changes than in other areas, but also demand them and, additionally, competition is much broader. It is not enough to keep an eye on the rivals within the sector, since at any moment a new actor can appear that turns the market around.

Given this complicated environment, when we work with digital products, we can not use the same methods as if we were constructing a building or a bridge: it is impossible to collect all the requirements at the beginning.

In addition to this, any requirement will change over time and, of course, we will always want to have the maximum return with the least investment. Traditional methods do not respond to this need for constant change.

The agile manifesto already gives us a vision on how to prepare for constant change: focus on what is important and value functional software as a measure of progress, interactions, individuals and collaboration in the face of negotiation, etc. But this is not enough, we need more detail of how to focus on the importance of our product if we want to achieve success.

Value as the axis of agility

In Scrum we define a Product Backlog with all the functionalities to include in our product. This Product Backlog must be prioritized by the Product Owner and the highest priority functionalities must be defined in detail for the team to focus on them.

But what is the correct method to prioritize the Product Backlog? How to know what is most important for a team to be 100% focused on it? That is where the concept of value comes up.

The value is defined as the benefit that a given product or individual functionality brings to an organization, represented in monetary terms. And that is the vision that the Product Owner must have to prioritize the backlog.

If the value is the monetary benefit that an organization obtains from the use of the product, no functionality will obtain money if it is not developed and goes into production.

Working with a traditional methodology in cascade, with its phases of definition, analysis, development, testing ... until we release the complete product at the end of all these phases we will not be able to obtain anything. No value, no feedback from users. That is to say, in the best of cases, we will be months without getting value. And months, in the digital world, is a period of time that you cannot afford.

However, if we use agile methods we begin to obtain this value much earlier. With Scrum, from the first iterations, we should already have something that adds value.

The MVP concept

This is where the concept of MVP (Minimum Viable Product) comes in. One of the issues that must be solved from the beginning is what is the minimum version that will allow me to launch the product and start to obtain real value from it.

In Scrum, for example, this translates to "from which Sprint are we going to launch the first release into production?" And therefore, in what Sprint we start to obtain value, reducing the term from months to weeks, a more acceptable time range when we talk about the Internet.

There is a false myth that once the MVP is launched that will be the final product and will not evolve. But nothing is further from the truth, working with the MVP concept and increasing its functionality in later releases is important for two things, mainly:

• The sooner you release a version, the sooner you can begin to obtain benefits that report income to the company and allow you to continue financing the evolution of the product.
• No matter how hard you work with the strategy and definition of the product, until the user interacts with it, you will not know exactly what is useful for him and how he uses the product. In the Customer Centric era, the user has the baton, and this does not begin to run until the user and the product know each other.

Measure and you will conquer

To further enhance the value obtained and be able to assess it, you have to introduce measurements. Each functionality launched will have a previous value based on hypothesis, but, once this functionality is available to users, we will have to check whether it is actually contributing the value we believed so that this information allows us to refocus the product or prioritize subsequent functionalities.

For this, each functionality launched will need to have defined indicators to measure and, as well as include tasks of layout, automatic test development, etc., will also include the development of the necessary analysis that allows us to obtain objective data as soon as that functionality is launched.

In Paradigma we have defined a method to do it and incorporate it in the Scrum work cycle, if you want to know more about how we do it, you can read it here in more detail.

In summary, working with the concept of MVP and agile methods that allow expanding the product in subsequent iterations reduces risks, costs and provides valuable information for future releases.

It allows you to work with deadlines that are more appropriate to what the digital world needs. And, above all, it means a change of mentality so that the teams focus on delivering products that provide business value, and not only to execute projects in time and cost.