MVP is not a draft! Right?

What is MVP?

MVP (minimum viable product) is a product that is developed with maximum savings in money and resources, usually for the sole purpose of testing a hypothesis. The hypothesis, as a rule, is the need and / or usefulness of this product.

MVP in no case means “draft”, made in a hurry, which after completion will be thrown away and will be written from scratch.

If you are convinced otherwise, then you should definitely stop, review the development priorities and read this article. It is worth reducing the functionality of the product, but in no case try to do everything at once, in a crazy rush, missing important parts of the functionality and leaving behind a string of bugs. It is necessary to precisely determine which functionality is basic and which is not used in most cases.

In this article, I will talk about our personal experience in creating MVPs and at the end I will give a list of useful tips that you can use in your development.

Personal experience creating MVP

As a rule, if you create MVP, then you are limited in time and human resources. So, for example, we had about three months to create a “minimal” project, one frontend developer and one backend developer at the start. Later, two more backend developers joined. But in any case, these are small human resources. Therefore, the first and main step is to determine the basic functionality, without which this application does not make sense, that is the key action that should be carried out.

At the start of creating the product, we had a description of the product with absolutely all Wishlist. The product was developed for internal use in the company, so customers were part-time and future users. On the one hand, this simplified the task, because it was possible to conduct constant communication and collect feedback during the development process. But on the other hand, this interferes with the product simplification process, as there are many points "we would like this." Therefore, I had to balance at every stage ... According to statistics, of the entire existing functionality of applications, only 12% always use constantly. In our situation, it was very convenient to prioritize parts of Wishlist with the usual question “how much is the necessary functionality?” And select only the most anticipated ones in the MVP list.

As for the technical side of development, you need to immediately understand which elements should be discarded. The biggest and most common mistake of developers is that mpv is a “rough draft”. This is not true! In the future, if the hypothesis was successfully tested, it would be great just to continue developing the current product, rather than throwing away all the money spent on developing the current version of the product. Therefore, you should not be skeptical, for example, about covering with MVP tests.

What we did NOT refuse:

• Test coverage of the backend part;
• Checking front lines and using unit tests;
• Tester, if resources allow;
• Documentation;
• Code review;
• Technical retro and refactoring;
• Design.

Refactoring

Something that you definitely should not give up. When creating a minimum product, it is very important that it is flexible, scalable and ready to develop in any direction. Therefore, if it becomes obvious that some part of the application is not flexible or potentially incapable of scaling, then it is worth stopping and correcting the situation, because in the future it can turn out deplorably.

Code Style and Lints

It would seem that this can be missed, but no. An emphasis on code style is more relevant than ever where speed matters. Because at any stage of development, it may be possible to connect additional resources in the form of people. The maximum entry speed of a new developer into the context is our main goal. This also includes the availability of documentation. The emergence of a new person in the team should accelerate development, and not slow down. It can slow down due to a large number of questions arising from him regarding the code and the application as a whole. Therefore, both technical and architectural aspects should immediately be included in the documentation.

Design

Extremely controversial point in the development was the need for design. In fact, waiting for design development before starting product development would be extremely stupid - sometimes it may take more time to develop a design than is allocated to the entire development. But at the same time, it is worth remembering that it is very important to make a product that they want to use. It will be lucky if developers have an extremely rare ability to do “beautifully,” but in reality this is not always the case.

One of the important arguments, after which we nevertheless came to the conclusion that the design is needed, is to speed up the development. A design that appears, perhaps late in time, still significantly speeds up the development and removes some of the burden from the developers. Which, in turn, can devote more time directly to the development and architecture of the application. It’s great if the resources allocated to MVP allow you to add a designer to the team. In our case, we did not have our own designer, but there was a person who was involved in several projects, and devoted part of our time to ours. This, in a way, is also a saving. .

What we still refused

The processes

Processes are what we truly sacrificed. Building processes is always an expensive activity. Of course, we had elementary ones: setting goals, sprints oriented towards the implementation of the integral part of the functional, attempts to evaluate tasks. But in reality, everything went out of control, since it was always necessary to be as flexible as possible: somewhere, the task could be simplified, and somewhere suddenly it was necessary to modify the functionality that was missed or interpreted incorrectly. Nevertheless, we always set small guidelines for ourselves in the form of the nearest deadlines with an understanding of what should be ready for this moment.

What else can speed up MVP development?

Ready-made developments. At the stage of creating MVP, you definitely should not engage in the development of your libraries and plugins. The maximum part of those should be taken from the outside and turn to Open Source. Perhaps some parts of the functionality have already been developed in other products of your company or by you earlier for your pleasure. This also applies to components. It’s great if your company already has a single UI Kit that you can use. As a result: accelerated development and a uniform style of the company's products out of the box. I talked about the experience of using a single UI Kit in a company in this article .

Direct communication between development and customers

Many developers do not like to communicate and communicate in life, not to communicate with customers. But communication really has great potential in accelerating development. In our experience, there have been many situations where customers implicitly imposed some kind of technical solution, to which they were already accustomed or invented themselves. But after finding out the real goal, knowing about the goals of the product, the capabilities of the current application and the already implemented functionality, the developer can offer a solution that at the same time will help solve the customer’s problem and save the lion's share of the time.

Be a team, not a recruitment

The increased level of communication in the team will help you quickly come to the optimal solution. For example, Frontend and Backend constantly communicated directly with us, sitting down at the negotiating table and deciding on which side this or that logic would be implemented, who would determine the format of the contracts and what data would really be needed in the API. It is very important that each part of the development can quickly respond to the requests of the other part, so as not to block the development as a whole.

Motivation of the team and developers personally

Creating MVP can sometimes be stressful and cause a lot of controversial points in which hot and sometimes difficult debate can arise. It is very important that in such situations someone acts as a catalyst and does not allow the team to lose motivation and team spirit. As a rule, this is the responsibility of the head of the current development, but it often happens that he simply does not have time or, even worse, he simply does not care. Do not underestimate how much this affects the speed of development. A united and motivated team communicates better and willingly lingers in the evening before the deadline of its own free will and desire.

Clear distribution of responsibilities: both roles and development

Regarding the development, we had an agreement that definitely accelerated the process. Namely - I expected all the necessary APIs and requirements from the front from the front, and the requirements for the front came from joint communications with customers and a resume of the technologist. So if something was missing on the backend in the API, the responsibility for it lay on the frontend part, no matter how strange it seemed. But that was our internal agreement. Regarding contracts, there was an agreement that the final decision was always behind the back, and with the front there was always an offer and the necessary data. Such internal agreements about who is responsible for specific parts of the application and development significantly speeds up the development process itself and helps to avoid contentious issues.

When communication goes directly between the development and the customers, it’s worthwhile to determine at the very beginning who leads the meeting and which plan everyone follows, who exactly assumes the role of the analyst (if there is none), and who offers the final solution. In our team, the roles were “smeared” throughout the team and there is nothing wrong with that, but a clearly undefined final responsibility is really a problem. This could turn into a “twice-salted soup, due to two cooks in the kitchen” and “a forgotten child in kindergarten”. The distribution of responsibility in the team should again be handled by the head of the current development.

Product Understanding Synchronization

At the beginning of product development, it is very important to build a plan for building the application architecture and discuss it collectively with the team - this is what we did before each complex part of the application. Description of the development architecture, a series of discussions, and we get a ready-made plan. Front and back, and design, and even analysts were guided at such documentation at the same time. So we always had a common understanding of the application, and we did not waste time trying to adapt to each other. The simplest example: we had a difficult work with data and a table view. Each key of this table could have its own view. Before doing the design, or the frontend part, or the logic on the back, or organizing the data in the database, it was very important to synchronize the understanding of all these parts into a single picture and come to an agreement on the names and terms. The general glossary also helped us with this. It would seem a trifle, but it really simplifies communication. As a result - accelerated development. It’s great when the analyst and designer understand what a component is; front and back name the same data with the same name; customers and development call the same part of the functional the same name.

We summarize:

• You should not give up control of code style, test coverage, design and refactoring.
• Design your product so that it grows and scales. Always keep that in mind.
• It is possible and necessary to use ready-made developments, if any.
• Direct communication between development and the customer can significantly speed up development.
• Do not underestimate the importance of team spirit and team motivation.
• Clearly allocate responsibilities in roles and in development at the very start.
• Very important in “fast” development is the same understanding of the product and synchronization of understanding.

MVP is not equal to “draft”!

I really liked the illustration that I attached at the beginning of the article. It well reflects the essence of development, where at each stage we have an already efficient and useful product. Further, it is only improved and supplemented with new functionality, and not developed functionality, which in itself does not make any sense and is not holistic.

In this short article, I shared our experience in creating MVP and some tips that I emphasized for myself from the work done. At the moment, MVP has successfully passed the hypothesis confirmation stage, and its further development is expected without discarding the already developed part.

Thank you for reading my article to the end. Leave useful tips on developing MVP from your personal experience in the comments and ask questions if any remain.