10 Mistakes in Developing a MVP.

MVP - Minimum Viable Product. A product that validates a hypothesis and is capable of entering the market. The latter is the most crucial aspect of an MVP. If the market doesn’t need your product, and you can't find your niche or break through the products of competitors, it doesn’t matter how good your idea is, the design of your product, or the technologies used.

First Mistake.

“We’ll do it well from the start so we don’t have to redo it later!”

Pay attention to the letter M in the MVP acronym. Minimum means the bare minimum. Imagine the worst-case scenario: your product is completely unnecessary for the market. Then, you’ve wasted money, but while you were developing the MVP and entering the market, you gained experience and knowledge. Now, using this new experience and knowledge, you can create a second MVP. So why did you expend so much effort on creating tests, validation, type checking, using best practices, and forming a full-fledged team? It turns out that you wasted money. After all, the same thing could have been done cheaper and therefore faster.

Second Mistake.

"Let's implement all the features in the MVP right away; this way, we can test everything, and when some features are missing, we can quickly refine them because it’s an MVP, which is light and thus new features can be implemented faster."

FDD (Feature-Driven Development) is not applicable to MVPs. This approach is used in product development that has a flexible architecture and is ready for rapid feature implementation. Using FDD in startups leads to a critical accumulation of technical debt and architectural bugs, which are impossible to fix without changes in architecture. At some point, development first slows down significantly and then comes to a halt. In such cases, the team, which loyally serves the startup and lives in constant turmoil, navigating through mountains of technical debt, is usually blamed. The business decides that for the startup, we hired "cheap people" and it's time to replace them with more "quality" personnel. The first problem will be transferring knowledge from the old team to the new one. In this process, more than half of the knowledge will be lost, and the hacks that kept the product afloat are likely to be lost as well, and the new team will face the same problems. Many companies change their team every year, and each new team steps on the same rakes as the previous one, without resolving the situation globally. If such an MVP is self-sustainable, you can stay in this cycle until a strong competitor emerges and knocks the company out of the market.

Third Mistake.

"Let's hire two mid-level developers instead of one senior, they cost the same, but we'll have twice the production capacity. Plus, the mid-levels will grow to senior level on our project, and we'll gradually increase their salaries, which will ultimately be cheaper."

In this situation, the mid-level developers will either only do what they know, and their knowledge is limited, or they will pull the latest technologies into the MVP to learn themselves and increase their market value. With this approach, the business will constantly hear the phrase: "We can’t implement this," and will start changing its business idea to fit the technical capabilities, which will eventually lead to the creation of a different MVP and a distorted business idea. And that’s if the MVP gets built at all. It’s quite possible with the help of mid-level developers to create an MVP that only works on their computers and is completely unprepared for a server. But thank God we have containerization, and today the likelihood of this situation is small.

Fourth Mistake.

"Let's expand our MVP; it has performed well in the market. Now we are ready to grow and expand."

In the case of successful market entry, the company starts spontaneously hiring new people, attracting funds, increasing advertising expenses, in short, begins to emulate big business - more expensive office, fancier team-building events. But we have an MVP, which was initially not built as an application ready for expansion; we saved on everything possible. In most cases, everything is calculated only for the positive scenario; in case of failure, the whole product stops, and the money stops coming in altogether. The business, as well as the team that hasn't worked with an MVP, doesn't understand that a large part of the product consists not of features, but of means to ensure functionality. Yes, cloud services partially solve the task of ensuring functionality, but they don't know how to configure your features; they don't know how to work with your users. In a working product, the admin panel is developed longer and has more functionality than the product itself. The response to a negative scenario is many times more complicated to develop than the development of a positive scenario. And I want to remind you that software development is only 20% of the product's lifecycle, and the remaining 80% is its support. And if an MVP can be built on average in a year, and that's just 20%, then the support of this MVP will last for four years.

Fifth Mistake.

"Why do we need such a big backend team? Let's keep one person and lay off the rest, since the product is already ready, and the mid-level developers can easily finish it off."

The interaction in IT is structured in such a way that the business mainly communicates with management and the frontend team. The backend is perceived by the business as some constantly dissatisfied people speaking a strange language. The frontend guys are always cheerful; everything is always good with them, the problems are mainly on the backend, not with them. They easily redesign buttons, change fonts, and repaint backgrounds. What these grim backend guys are doing is not clear at all. In a modern application, the correct approach is to move all the logic to the backend, because most applications have two versions, mobile and web. It's optimal for these two versions to have the same backend. Besides, a lot of logic can only be implemented on the backend. Therefore, dear business, you should fully take care of the backend team; it is in this dark and unclear environment that the company's money is generated. The frontend attracts and makes interaction with the application convenient, while the backend makes the application possible in principle.

Sixth Mistake.

"We need more documentation!"

There are two extremes regarding processes in IT companies: either we don't have any documentation at all or we have a pile of documentation that no one can read. Many diagrams, the idea defense stage, the R&D stage (research and development), prototyping, task formulation, task distribution. Why do you need all this when you have a twopizza team working on the project? When creating an MVP, it's worth focusing only on the necessary minimum in terms of documentation. After all, all this documentation, diagrams, and charts may turn out to be unnecessary if the MVP doesn't take off. On the other hand, just having a title for a task is not enough; at least a brief description of each task must be present. There's an issue with self-evident information; what's obvious to one person may not be obvious to another. A clear task description can save hours, even days, for a developer who will be solving the given task.

The same applies to IT formalism. Is Jira mandatory, or will Google Sheets suffice? Does it have to be Scrum, or will Kanban do? While you're building an MVP, reduce all formalism to a minimum. Providing information for calculating KPIs and easy report generation for management in a startup is more about the appearance of work than actual work. You have a small team; the product owner can ask each team member any questions they have. When you have several departments in the company, when you have large teams, and a lot of work is done in parallel, then this formalism helps. But you should start establishing company processes only after a successful MVP launch. For many businessmen, IT might no longer be interesting as a money-making sphere after their first experience with an MVP, so why spend time and money on processes now. Small internal agreements at the first stage are quite enough.

Seventh mistake.

Premature scaling.

So, your MVP is on the market, and investors are lining up to give you money. The business makes promises and agrees to everything that is offered for implementation, and yesterday's mid-level developer, now grown to a senior, proudly bears the CTO abbreviation and answers numerous technical questions just as optimistically as the CEO. The imagination paints a picture of a successful unicorn startup, here it is - success! The survival rate of startups according to statistics was drawn within 10%, then it was reduced to 5%, later it was 3%, and now they talk about a pessimistic 1%. From 10%, the survival rate fell to 1% due to premature scaling. Ten to fifteen years ago, this stage was simply not known, or such a fact was not given such a big importance. Therefore, the successful 10% of MVPs over several years generated another 10% of survival, which ultimately led to a total figure of 1%.

When you were building your MVP and did it right, you saved on everything you could. And of course, your MVP is not ready for development, because nobody invests the ability to develop into an MVP. A large number of startups are scaled in the form they existed in at the time of MVP production. And since the MVP is made without processes, and often relies on personal responsibility and the personal knowledge of team members, an attempt to scale leads to the fact that the holders of knowledge about the MVP become a bottleneck in the onboarding process of new employees. Since the MVP existed in creative chaos, the company begins to scale this very chaos. This is a very painful process for the company, many companies, even those not from the IT sector, may not always survive scaling. Therefore, always start with processes, and you will bring everything else in order afterwards.

Eighth mistake.

MVP Development.

Probably in every mistake described above, I mentioned that an MVP is about saving as much as possible. It is perfectly logical to leave the MVP on the market to attract users, receive feedback, and be an attractive piece for investors, while at the same time building a real product based on the confirmed hypotheses from it. There is no need to refactor the MVP and divide the monolith into microservices; it is necessary to build a product from scratch, embedding in it sufficient flexibility and scalability. Refactoring a monolith into microservices does not solve architectural problems; you will get the same MVP, but only on microservices. If you manage to do this, of course, you will get a more viable version of the MVP. But you won't solve the problem as a whole. And quite often, an MVP that has been transferred to microservices works worse, or the refactor itself has to be done several times. Therefore, in fact, the attempt to save on product production most often makes the process even more expensive. Your MVP will always be in version 0.9.x and will never become version 1.x.x. The sooner you understand this, the sooner you realize this reality, the more money you will earn.

Ninth mistake.

"This is my second startup; now I know everything. After all, the first startup was successful, so the second will definitely be too."

At the time of writing this article, I have knowledge of 18 startups. Some I started from scratch, others I joined at some stage. Most startups did not survive, but some are still alive today. My first startup failed, the investor ran out of money, and I didn’t find another one in time, although I did receive potential interest from an investor, but since his portfolio was full, I was postponed to the next year. When I was doing my first startup, I had no idea what I was doing and how, I had burning eyes and an idea that I really wanted to implement. After the failure, I thought that I lacked trivial knowledge and that there must be a formula for success that I had to find. 16 years and 17 startups have passed. There is no formula for success; success is a fortunate intersection of many factors. Failure is the same but in a negative aspect. Over these 16 years, many companies have ceased to exist, although they started as a successful startup. On average, a company existed for 5 years, and during this time, it tried to repeat its success in dozens of new startups and lost every time. And I completely don’t understand why, but in all these attempts, there was one common trend. All subsequent startups of the company were done in the same way as its first startup, but times change, markets change, approaches to products in the market change, none of the companies that ceased to exist had a high level of market adaptation. And they called a startup what was not a startup. A startup is an innovative idea, something fundamentally new, but at the same time understandable to the market. A new product based on the idea of competitors is an attempt to defeat competitors - this is not a startup.

Tenth mistake.

Reading literature on startups and wanting to prepare for everything.

Of course, I'm flattered that you've read all the way to these lines, but please stop. Stop reading these abstruse articles about startups, MVPs, agile, and other IT parts. No one but you knows how to do it better, no one but you can create your best startup. Articles, books, descriptions of someone else's experience do not suit you personally. I have encountered startups that were made impeccably, but they did not take off, and also participated in startups that I can confidently call hell for everyone who worked there, from the CEO to the tester, which brought in money. No one knows how to do it right for you personally, experience gives you the opportunity to avoid a certain number of similar mistakes. But the world is changing, and mistakes change with it, so in addition to common mistakes, you will inevitably face new ones. You should be ready to solve problems, and there will be many of them. If you have the opportunity to gather an experienced dream team - go for it, if you don't have this opportunity, start with what you have now.