The story of stepping on the same rake… multiple times

This is the story about our clients who step on the same rake over and over again, while some of them are even forced to shut their projects due to rather serious documentation mistakes, both business and technical.

I guess, everyone is familiar with the proverb “to step on the same rake” There is a wide variety of interpretations and hidden meanings of this idiom, but the very point of it is almost always the same: stepping on the rake you are guaranteed to get slammed in the face… That’s the way it works… Damn rake! 🙂

Let’s consider “a rake” to represent our clients’ mistakes that need to be solved. These mistakes are often made by the clients themselves, or by their teams. There are many various types of such mistakes as well as corresponding consequences caused by them.

To put it simply: such “rake” can be a pain in the neck sometimes. It can even hurt you really bad in exceptional circumstances. But, if you try hard enough, you are able to come up with a super-unique “rake”, which, in fact, can put your business to an end.

As ridiculous as it may seem, this is a so-called “killer-rake” that we wish to discuss today and even take a look at some obvious incidents involving our customers. Fortunately, we have noticed just in time that our clients tend to become increasingly sophisticated in “upgrading” their “rake”, and, therefore, we have prevented all (or almost all) our customers from getting “kicked out” of the business world…

Anyway, what was I talking about…? Oh yeah! “A rake”… The most painful and non-obvious aspect of it for our clients turns out to be… Guess what? I bet you have no idea whatsoever! 🙂 The answer is “documentation”: both project and pre-project ones.

I will provide you with some particularly vivid examples of such cases. Let the real names of people and companies remain anonymous. The point of the story will remain the same.

Let’s say, a man named John Smith asks us for a consultation. John works in the “EdTech” sector. He runs a successful business that generates enough profit, enabling him to cover all his expenses and even have an extra income for further improvement.

With great effort, John has been trying to advance to a new level of business for quite some time. He constantly tries to set up new blocks and landing pages, aiming to implement them on his web-site and thus to improve it by every possible (or rather impossible) way.

Unfortunately, every new update makes John notice that, while he dedicates time and money for the project, the income is not worth his investments or even goes negative.

We usually ask several standard questions at the very beginning of work with clients. The answers are commonly the same. The following questions are:

1. Do you own any business documents (the overview of business processes)?

2. Do you own the overview of your target audience and unique selling proposition?

3. Do you own any technical documents?

How often do you think we hear that a client owns all of the afford-mentioned things? Bingo! Once in a blue moon! 🙂 Truth be told, only two to four percent of our clients own all the necessary documents more or less in their entirety, while another ten percent of the clients own hardly a part of them.

And so, John tells us the same old story as all the other clients do: “Of course not! There is no documentation, and the project is outdated. It was started ten years ago. It has been gradually developed as required since then. We were not up to the documents. We consider them to be useless even now. I know all the aspects of my business inside and out. I keep all the processes in my head. All the technical documents”, it can’t get any worse, “are the responsibility of my team leader Simon, who is a talented developer and a good friend of mine. And as for the ICP and UPT… C’mon, gimme a break! That’s ridiculous… Of course we know our clients very well! We sell our product to them rather effectively…”

Let’s pause and think it over for a moment! What alerts you in this situation?

In fact, we have a “combo” here! The situation can be easily illustrated by our beloved “rake” just like this:

I actually reckon it might be even more entertaining and thought-provoking if we draw a parallel with a situation, when you go for a walk and you take your favorite rake with you. You throw your rake in front of yourself and get slammed in the face by it every five meters. But you are a real die-hard, aren’t you? 🙂 So, you keep walking and throwing the rake in front of yourself and getting slammed in the face mercilessly again and again… It just goes on and on until the end of time. I think you see my point. We can name this type of fun “a rake-tron”.

Anyway, why is the above-mentioned situation so fatal? Let’s discuss it step by step:

1. We have a project with a great legacy. Ten years is a rather solid term for a project. Why is it so? In a nutshell, ten years is enough time for some technologies to be developed, reach the peak of popularity, then gradually lose their potential and finally vanish and be forgotten as a bad joke within a certain community. In addition, the majority of third-party solutions that you have been using, such as API, side-services and others, may no longer be supported, shut down as businesses or be completely modified. It is a debatable point, whether a solution that you bought ten years ago can be supported without any updates.

Moreover, there is a possibility that you can have a solid number of developers, product & project managers and other specialists going through your business within a ten-year period. I’m not saying that all these developers are capable of making mistakes. Noway! They may be highly qualified and perform even better than their predecessors. Nevertheless, it’s worth mentioning, that, in the absence of a single unified business outline and description, all new specialists tend to solve the local problems the way they consider to be the most appropriate for the moment, not bothering to take into account previous or possible further solutions.

What exactly can this situation cause? It can cause chaotic development at the process level and at the code level as well. Every team manages its current tasks, while each subsequent team unintentionally “creates” new obstacles. This leads to the fact that new solutions are inevitably based on the outdated framework.

As a matter of fact, this is the beginning of a process called “dead-coding”, which implies writing of a code bound to die and thus turn the whole subsequent project into a “zombie”.

2. Another critical point of John’s business is his friend Simon. As strange as it may seem, but managing a business with your friends, as far as I’m concerned, is more likely to have negative rather than positive consequences. It is possible to build friendship in the course of work given the preliminary functions distribution and subordination, but launching a project with friends is the right way to lose both business and friends.

I wrote more about business and friendship in my previous article. In brief, a business friend is either an absolutely ultimatum-like character, or a time bomb that might (or rather surely will) go off at the most inappropriate moment.

In this particular case, John has, actually, shot himself in the foot: his friend is not only his partner, but also a technical co-founder. His quitting may be somewhat risky. Not only does he own analytical data of the business, but is also aware of its commercial secrets. What is more important is that if you have no business documentation or lack another trusted specialist, then you are likely to be left with the project that only Simon specializes in.

John’s case is already a failure from a business point of view. It doesn’t matter whether Simon left the business the easy way or the hard way. From now on, John will constantly depend on his former partner, begging him for help. It obviously looks like the beginning of the game called “Simon says”. You know… Simon tells John to go straight to hell with his plea to pass the project to a new team, and so on and so forth…

In fact, it doesn’t mean a “bad break-up”, and Simon won’t tell John to go to hell, but as soon as Simon finds a new job, or, let’s say, I have some family circumstances, there is no doubt that the game of “Simon says” is going to become John’s biggest headache for a while.

3. According to our experience, the absence of ICP and UTP can be a peculiar and rather obvious matter. In reality, its written form completely differs from the one that a business owner tends to visualize.

After we persuaded John to do research and prepare ICP (user persona) according to his clients, as well as to analyze their purchasing power and segments, he was quite surprised to find out that the majority of his clients have certain characteristics, values, interests and lifestyles. And when we compiled an updated UTP according to this database, it turned out that his business could afford way more services to his target audience, and more importantly, his clients were looking for solutions to their problems.

I know you may find it difficult to grasp without specific examples, but I would prefer our client’s real name to remain anonymous, in order to avoid unnecessary compromising information.

To be more specific, let me provide you with a vivid example of another case.

We once used to carry out a market and niche analyses for a car service station. We analyzed its current audience and observed it from different perspectives.

It turned out that the owners of the car service station didn’t single out a specific segment or manufacturer, but provided services for everyone. Some interesting details were discovered, after we got to analyzing clients from the money perspective.

There were only nine percent of BMW clients. It was them with the most complaints and the smallest margin. It may sound weird, given that BMW is the most frequent brand for maintenance, but in this particular case, the reason was that none of the mechanics at the station specialized in BMW. Hence the inappropriate quality of work and a low profit.

There were twenty-three percent of AUDI and Mercedes clients put together, that showed a decent income. To our surprise, it turned out that almost all the other cars were French (Peugeot, Citroen, Renault), and, in truth, it was them demonstrating the highest margin rate.

Moreover, after analyzing the clients of these cars, we could create a curious profile of a customer. These were between twenty-seven to forty-five years old middle-level managers with an average sustainable income, who regularly spent about hundred dollars a month on a car service.

The point of the story is that, after a more profound analysis of your business and the processes related to it, you may be surprised to learn that only twenty percent of your services bring about eighty percent of the income, while everything else works poorly, or doesn’t work at all. And in case you haven’t yet launched your product or service, it can turn out that customers may not require what you offer them, or, on the contrary, you may underestimate the necessity of your product or service.

Thus, to sum up, you should always keep in mind that your project’s documentation is the key to a more appropriate and cheaper development process. It will prove that you are able to understand the way your business works and how it can be possibly optimized even after a while. It may eventually help you to hold your nerve and stay as cool as a cucumber. 🙂

P.S.: Ask yourself a question: “Do I really keep my business’ processes under control, or do they actually control me?” 😉