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 in 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. 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.
According to statistics, of all the existing functionality of applications, only 12% always use constantly. You should 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 you DO NOT need to refuse:
- Test coverage of the backend part;
- Using unit tests;
- 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
It would seem that this can be missed, but no. 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
The 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 and you might need to hire a graphic designer who has at least basic, but good, graphic design skills .
One of the important arguments, after which you still come to the conclusion that the design is needed, is the acceleration of development. A design that appears, perhaps, out of time, still significantly speeds up development and removes part of the load from 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.
What you can still refuse
The processes
Processes are what you can truly sacrifice. Building processes is always an expensive activity. Of course, you should have the basic processes: setting goals, sprints, oriented towards the implementation of an integral part of the functional, attempts to evaluate tasks. But in reality, everything can get 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 refine the functionality that was missed or interpreted incorrectly. Nevertheless, you should always set yourself small guidelines in the form of the nearest deadlines with an understanding of what should be ready for this moment.
By using a time tracking tool along with your project management app can give you a clear insight about where your team is spending how much time.
This will help you to calculate the cost and improve team productivity.
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.
Direct communication between developers 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. Having ascertained the real goal, knowing about the goals of the product, the capabilities of the current application and the functionality already implemented, 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.
The 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
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. 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. Both front and back, and design, and even the analyst are guided at such documentation at the same time. So you will always have a common understanding of the application, and you will not waste time trying to adapt to each other. 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 will also help you 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 function 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”!
MVP is when at each stage we have a workable 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.
Add Comment