Why detailed competitor analysis can ruin your company

No, of course you should analyze, of course it is very important. But this article is specifically about obsessive analysis. We will give a real-life example about competitor analysis, but this also applies to overly diligent analysis of customers or technologies, for example. The point is that a client came to us who was very interested in competitors, wanted to know everything about them, wanted to study them inside and out, and sincerely believed that this was an important issue that would lead the company to success. "Let's analyze 10 more competitors?", "Why does everyone have different technologies?" Why do they have Java?", "Maybe we should develop it on Node?", "Why is prom.ua on Python?", "Maybe we should do it on a CMS? Or a website builder?". And a hundred other questions. And this is normal; any director or owner has the right to worry about not being worse than competitors. However, at this point we have already collected a lot of information about competitors, but have made no progress at all in another critically important analysis...

I will quote from our dialogue after another concern from the client that we had not conducted a sufficiently detailed competitor analysis.

"Okay, tomorrow from 11 we can look at everything in detail, but I would suggest spending this time on more valuable analysis, because we will be able to find some details about competitors, but this will not tell you anything. Just like looking at a city and analyzing: 'why are the roads like this here, why at this angle, why is this building standing there and not 100 meters farther away, why is the bridge in such a strange place, since it is not logical.' 500 years ago the city was a small village on a trade route. Where caravans passed more often, beaten paths formed; then stone paving was laid, and then asphalt was poured. Bridges were placed where, at that time, it was appropriate to build them according to the technologies of wooden bridges. And then all of this became connected with the road as a whole, people built houses near the road, and later no one could demolish the houses to change the architecture of the roads and bridges, because different bosses were responsible for each district.

You do NOT need to look at how these large companies were formed. This is their personal experience and their own rakes; they dream of rewriting everything from 0 and on other technologies, they want to simplify everything and avoid heterogeneity, but that is how it has already historically developed. They are not able to do this because they have grown, acquired their bureaucracy, and created a lot of undocumented code that no one will rewrite anymore, but somehow it works there under the hood. This is called Legacy.

Therefore, in my opinion, we need to talk about what exactly your company is and what to do with it within existing technologies, how to automate its processes, and not look at mammoths, and especially not look at those who mindlessly try to copy them without logical reasons and arguments. This is the most optimal way to bypass competitors: make your own solutions, solve real problems that exist today, and build a flexible architecture without enterprise elements, without a pile of different technologies.

In all this time, we have never properly discussed what processes you have. What can be strengthened to increase the company's profitability. How to raise your customers' loyalty programmatically. How to do upsells. What takes the most time in the company's working mechanics. Which people are involved in the business... And many more questions of this kind.

The decision is yours, but I would suggest spending tomorrow's time specifically on analysis that will lead to an increase in the company's profitability and, in the future, would create innovations for the company instead of stepping on competitors' rakes, whose full history we do not know and no one will tell us."

That was an excerpt from the conversation. Someone will say that it is harsh, that it is wrong, that the client's word and wish are law. But not for me. My task is not to indulge the client, but to solve their problems. Because no matter how much an architect or manager follows the client's wishes, the client's main wish is still a good company. And a good company makes money. That is its point. Of course, this is not the only metric; of course, it must compete with competitors and create innovations. Everyone has their own values, and that is good. But the common denominator of all companies is the money that it can focus on embodying its model of values.

When conducting any detailed analysis, please do not forget that everything is understood in comparison, and everything has different points of view. And when you create a software product for a company (which, generally speaking, is your company in our century), you cannot afford to analyze only one aspect. Your "triangle of success" is customers, competitors, and technologies. This is precisely the main subject of product analysis. And to create a product, you need a project whose key metrics are scope of work, budget, and time. But read more about this in our "Management and Administration" section.

Categories have no boundaries, and it is difficult for us to stop comparing. For example, if you sell clothes, then your distant competitors are travel agencies. Because any person can, for example, refuse to buy a fashionable seasonal set of clothes in favor of a pleasant weekend trip. But these are very distant competitors. And while you are analyzing them, someone is selling to your direct customers. To some people this seems obvious, but such scattered focus and poorly set priorities among competitors (customers, technologies) are a very common antipattern.

Do not compare yourself with those who have been writing their own software solutions for 20 years. This is a completely different world. A product that is one year old and a product that is 20 years old are like a village and a city. Of course, everyone wants to become big immediately. But this is impossible; the laws of physics do not allow such quantum leaps. And in general, think about whether you want to become a large, bureaucratic, constrained, slow, and conservative company. Or whether you like being small, flexible, trying new technologies, and quickly adapting to the surrounding world. Large companies have their own headaches; do not rush to take them on. We at the company https://ingello.com always strive for balance, and in terms of size it is great to be both large and small. That is why our teams of programmers are decentralized; we do not have a single command center, but we do have unified technological bases that store experience, are capable of improving it and sharing developments, but without a single heterogeneous enterprise shell.

And to conclude this little article, I want to say a simple truth: your time is limited, we are mortal, and our projects and companies are too. Therefore, it is logical that within such limitations we can create a limited number of projects and products. Therefore, as a system architect, I simply cannot allow one analysis to be done at the expense of another. My task is to make the most critical and complex decisions for the company and the system. There are already many complex subsystems where mistakes will inevitably occur and reserve time will be needed to fix them. So let us at least not ignore the standard best practices, where everything is transparent.

Successful projects to you, colleagues!