MVP means minimum viable product. The MVP product has the most important functionalities for the product, which are then tested on the market to see if it can be successful.

To perform initial tests, the product needs only the most necessary functions. The MVP product version is the most reasonable tool, in terms of both time and money, to help determine product potential. The MVP method can be used to develop any product, including mobile applications and websites.

Many talented people have influenced the concept of MVP. But the most famous author of the methodology "Lean Startup" Eric Ries. He defined MVP as: "MVP is a product version that allows the team to gather the maximum amount of confirmed customer knowledge with the least effort". In general, the purpose of this product is to check demand. The market response determines whether you get inspired to expand your business or just stop.

As you can see from the above statement, MVP offers a lot at a low cost, but it is not without risk. It is enough to choose the range of functionalities that are to appear in MVP incorrectly so that the interest of the recipients is too small and thus does not confirm our hypotheses, while placing too many functionalities can drive costs up, and in case of failure in confirming the idea of the product, we lose the invested contribution.

How does MVP work with IT projects?

It's great to test your idea before you spend a lot of money. Currently, programming offers many frameworks and libraries, which significantly speeds up programming time and reduces costs.

1. Preparation

The stage consists of gathering information about the project, its goals and ideas. During this stage, decisions should be made about what to do in MVP and what to leave for later, once the idea is validated. This step must be approached very restrictively because it depends on the amount of work we put into the project in later steps. Adding too much functionality will result in longer working time and shifting the "deadline" many times. On the other hand, too few functionalities may affect the negative reception by end users. The rule is to put in MVP only those functionalities that are the "core" of the whole idea and without which the project has no reason to exist. I will use the example of Facebook, as everyone knows how it works and what functionalities it has. If we were building the MVP mobile application for Facebook, at the beginning we would be limited only to the main functionality, i.e. displaying the feed and the possibility of commenting and interacting with posts. All add-ons in the form of groups, stories, shops or brand pages would be left for later, in the end we are only in the testing phase of the project.

2. Prototype

Once we've decided what will be in our MVP, it's time to create a project in the form of user stories or UI / UX mockups. This is not a mandatory step, but as in the first step, at this stage we decide what we should do. Thanks to this, we will avoid the temptation to add additional "features" during development.

3. Development

Often the longest and most costly stage of the entire MVP formation process. It was the two previous steps aimed at planning the work and thus minimizing the amount of work at this stage. Well-made stages of preparation and design should very accurately bring us closer to the time consuming development works, thus showing approximate costs.

When it comes to development itself, an experienced team leader or programmer with experience in MVP will also be useful here. As always in the work of a programmer there is a big temptation to implement solutions in the "art-for-art" style, this is a strange ailment of programmers consisting in writing code in such a way as to prepare for potential problems of scalability in the future or building solutions according to the latest technological trends. It is not uncommon when a project is delayed or its costs go beyond budget because programmers spend too much time on one of the modules, while the amount of this work has no chance of reimbursement in the future. Therefore, MVP also applies to programming, you should write simple, uncomplicated code and build the application architecture in such a way that it has as few "mobile" components as possible.

4. Validation and pivot

The last stage is project validation. It is then that our first users learn about the product and their behavior tells us what we should change. Either our idea turns out to be successful and we develop it further or we decide to suspend the project. In this case, you should learn as much as possible from such a failure, the mistakes we teach teach us a lot, sometimes it turns out that users start using our MVP in a completely different way than we originally anticipated. This is the moment for pivot, i.e. adjusting the product to the requirements of users that flow after the period of use, sometimes pivot may turn out to be a 180-degree product change.

Finally, a short DO & DONT'S list.

DO:

• Keep a minimum amount of high-quality functionality
• Be oriented on a large market
• Remember the business model that will allow monetization
• Monitor and adapt to user behavior
• Enter the market as soon as possible
• Research competition
• Invent a marketing plan and strategy that attracts a large number of users

DONT:

• Do not add unnecessary functionality
• Do not delay entering the market by adding new functionalities
• Don't be afraid to start again if the MVP results are not favorable