The Failed Construction Tech Startup's Story
Two years ago I shut down Brigadier - a construction tech startup about field management on a construction site. I've been trying for a long time to make all new attempts to move our startup forward. Along the way, we studied the market, tried different segments, and different value propositions, and experimented with marketing, sales approaches, pilots, accelerators, and much more. All of this gave us some kind of momentum, but it did not transfer into predictable growth.
Yes, we had pilot launches, we had thousands of registrations, we had in-app sales, and during quarantine, there was even a hint of positive momentum in B2B sales. But each time it didn't take off. For different reasons, which is probably a good thing, because each time the mistakes were new.
I wrote about the reasons in this post. I want to reflect on the 3 years of Brigadier's life and share some thoughts that seem obvious now but are still very important in building a business.
The most important thing is the team.
We had a great team that was resilient and flexible. Still, it wasn't as joyful as most success stories make it out to be. We ran into a lot of problems. Some of them could seem obvious, but at that time not so trivial to us.
About sharing responsibilities
Ideally, all co-founders should be responsible for their part of the project. However, in the early stages of a startup, it does not make much sense to share responsibilities. At this stage, there is the most uncertainty and everyone should be doing everything - communicating with users, building prototypes, experimenting with marketing, etc.
If you try to differentiate functional responsibilities from the very beginning, it may become an unnecessary formality. When there are problems with a task, one person will have to deal with it, and the others will step back, claiming that it is not their area and that they do not know how to deal with it and do not want to.
It may seem that the one who does not do his part is an incompetent weakling. But here lies the key meaning of the word "co-founder" - a person who realizes himself as an important part of the project and owner of a potential business, who is ready to do everything necessary for the life and development of the project, regardless of his skills and formalities. Everyone has to learn.
Personal Priorities
It is impossible to predict, but over a long distance, the personal priorities of the participants will change. The fact is that, except in cases of force majeure, the probability of this happening increases after 3-5 months from the start of the project. Often this nuance is revealed too late when it begins to manifest itself clearly in the work.
You have to agree in advance on such things and update agreements every few months to assess the risks associated with the team. If it is not possible to start growing according to your own metrics in the first six months, you should be ready to stop the project on any of the following days. On day 184, people start to burn.
Divorce
People often write vaguely about what to do when everything falls apart. Sometimes issues such as how to divide the money, stocks, intellectual property, and other acquired assets are mentioned. However, it is easier to divide money than it is to divide the remaining inherited obligations.
This is exactly what needs to be agreed upon when it comes to the question of "how we will divorce". Obligations under current contracts, accounts, debts, customers, investors, closing or reorganizing the company - all of this will need to be sorted out and resolved, possibly for more than a month. A lot of nerves and things that nobody wants to do anymore. And you can be alone with it.
What about the product?
I picked an interesting, large market. There are many niches and segments, and there is really a place to develop. However, its specificity and conservatism require decent initial resources to build a quality product.
For the product to be in demand, it must be integrated into existing business processes, not just solve individual tasks. Many processes are so intertwined that the product may not be the best solution, but just another tool to figure out and complicate life. In our chosen niche, the product had to cover many aspects of the business, and the MVP couldn't be assembled from bits and pieces in a few weeks.
Then it gets complicated - there is no default customer trust. On the opposite, there is only mistrust in construction. Therefore, the product must be extremely reliable. Anyone who is disappointed in the first stages of getting to know the product is unlikely to come back.
Even if the problem of trust is solved, there is still the question of scaling up sales. For this, you need very demonstrative, attractive use cases that show the usefulness of the product in numbers. Building these cases can take many months of work with metrics, product support, and customer support. And with a team of 5, the resources to do this work quickly become scarce. Just not enough hands and time. Of course, there is a way out - a high price that covers everything and allows you to make money. But this is the way to custom development or other segments and formats. Another story.
So, in addition to the complexity and reliability of the product, a key requirement is to lower the entry threshold for users. What a task! In our case, many did not even have a clearly articulated need. It took 2 years (from the start of Brigadier) for the market to simply recognize the need for innovation.
To a greater or lesser extent, these problems are inherent to any B2B product. Nevertheless, I was fortunate enough to go through this experience, which greatly influenced my attitude toward building business products and my understanding of MVP and Lean methods.
The Ambiguity of Startup Flexibility
Throughout the project, I often felt like we were going back and forth. Trying one thing, then another. Most of the time there was a justification like "this is a good opportunity and it fits our plan, we are a startup and we need to be flexible". That's a serious mistake on the part of the founder, who ultimately makes the key decisions.
The problem lies in misplaced expectations and overemphasis on every new opportunity. Flexibility is important, but it's dangerous to confuse it with softness. There must be a clear plan of solutions that have already been adopted. Flexibility is a controllable, manageable trait that can and should be changed. For example, a certain level of flexibility can be achieved by planning in the short term of 2-3 months. And all opportunities and new commitments should be strictly put in a long box.
Conscious structuring and control of communication, with a rational approach to the selection of opportunities - is one of the most important skills of the founder.
This is the end
Of course, these are not all the mistakes that were made during the project. They didn't happen all at once but accumulated from many events over time. I was sure until the last moment that the task would be solved and the valley of death would be passed. It is not worth dragging things out for too long on sheer faith in one's own strength.
In the end, it is more pleasant to believe in something new. And understanding the market becomes a more important factor and argument to start again. Use the experience, and try again, because you are not a beginner yet.
A lot of work has been done and a lot of effort, time, and money has been invested in the product. There is nothing to regret, and there is no need to worry about what has been done, even if it seemed otherwise before. In the end, the value is represented by knowledge and understanding of the market, the field, acquaintances, new skills, and acquired bumps. Of course, monetization will have to be done almost from scratch, but maybe the cycle will be shorter and time can be expressed in money (yeah, that's how I calm myself down :) ).
We dragged our feet on closing for a long time. As I see now, there were several suitable moments. During half of the year, Brigadier was rather dead than alive, however, we were looking for a miracle. It was psychologically difficult to make a decision, a habit was formed for the project. There was a dissonance in my head - "I have put almost everything into this, how can I give up?". So I had to go through all the stages of perceiving the death of the project - denial, anger, bargaining, depression, and acceptance. And even though the understanding came in the first stage, it was not possible to move immediately to acceptance, such a paradox.
I have gone through this path and in the end, I felt a strange feeling of emptiness and relief at the same time. It is worth accepting the death of the startup from the beginning. Remember that one way or another, everything will lead to it - whether it will be a failure like ours or the acquisition by a strategic investor. And of all the important decisions, the only ones left are the ones where we will either die or take off.