How startups I worked with failed

I probably won't have to convince you why you should read failure stories. I usually don't trust people who say they have never experienced/explored failure. It is said that only eternally optimistic persons can become startup CEOs. But if you don't explore the world of failure, you only have the glass half full. A startup CEO makes a lot of choices in a day and you often don't have enough time to make the informed decisions and these stories can help you become confident in making these (good or bad) decisions.

I have experience working in small startups to large enterprises. Among the startups I worked for, most are defunct or focusing on different product than they originally set out to do. When I reflect on why those startups failed, I see a similar pattern of wrong choices made, so I believe if someone from these startups has set out to seek on what not to do, they would have survived.

I will write on this topic in two parts, where this post will focus on the management part, while the next post will focus on the technical and product part of what not to do (or what I could have done better).

Disclaimer: I haven't had my own venture so far, so my impressions might be biased but nonetheless I'm presenting them in hope that someone might find them useful.

The problem of market research

This is something common in all the startups I have worked so far to a varying degree. Startups X and Y I worked for, just had an idea and zero market research on what the target audience wants. They started out with an idea. Searched on the internet if something similar exists, since they couldn't find it (May be because of lack of searching skills?) they immediately hired a designer to sketch out some mock-ups.

Startup X was started by a few developers. So after the mock-ups, they started developing MVP but they never defined a fixed set of features for the MVP. So they spent 2 years on developing and perfecting the product, making sure the UI/UX is at the level of fortune 500 companies. After that, they started to feel that their code base is bloated with so many refactoring. I joined them into their third year and asked to remove bugs and make the code base a bit cleaner. They are thinking about market launch as soon as the product is stable and thereafter, they will do the re architecture of the entire application. That soon time came two years later, when they decided its now or never to penetrate the market. By this time, there were already a few competitors in the market, but the CEO had faith in the product because their UX was perfect, even though it was still riddled with bugs. Developers worked on the product for about 4 years before anyone outside of the group saw the product. I will leave it to your imagination of what follows once someone from the target audience sees the product.

Startup Y was a bit better. They had clear set of features for their MVP. I was their first hire and I delivered the MVP within 3 months and they tested it with the close family members and found that the designs don't seem to be UX friendly. So now, they hired another designer who created a completely unrelated set of but very impressive mock-ups. I reworked the UI components entirely and added a few more critical features. After another three months, another MVP was ready. They tested the product with another set of family members, and we refined a few features. Now comes the time to show it to selected target audience beta testers. The story spirals downward from here, which brings me to my next point.

The problem of priorities

They are thinking about market launch as soon as the product is stable and thereafter, they will do the re architecture of the entire application. Y had an influencer for marketing in their space, so they acquired the users fairly quickly, but the users weren't converted to paying users after their trial period. They tested the product with another set of family members, and we refined a few features. With the influx of so many feature request, management tried to focus on developing small features first so that they could retain those users who just asked for those small features. However, tye management didn't realize that the bigger missing features were also critical for those users, they just didn't reported it. After a while, the company ran out of funding and stopped all the development and just focused on the marketing and sales. At that point, most of the feature requests were completed, but the users were just moved on from the product. It was a very simple mistake of setting priorities, but that was the major reason for the company's downfall.

Company X was already in a bad shape technically, the product was already feeling bloated and developing new features broke a lot of things even though there were a large number of unit tests. After the management started demoing the product to the potential customers, they realized a few features that they thought are very important, turned out aren't actually necessary and a few features they never thought of having were so important that the product can't be launched without them. We ripped out those unnecessary existing features (which took the most of the time because of the bloated code base) and added those necessary ones (which didn't take that much). But a year passed doing those things and we couldn't test the product much before we had to release it to the user. If the management had done a good market research and haven't waited that long to show it to the potential customers, then they could have saved a lot of time.

The problem of user retention

Company Y didn't just have the problem of priorities for user retention although that was the major contributor. Their product was kind of like Airbnb or Uber where you don't succeed just by acquiring users that provide services. You also need users who purchase these services. Company X focused solely on improving provider experience to generate revenue, but failed to capture and retain the other side of the market which is essential for the providers to use the platform in the first place.

The problem of scalability

Once you have a product out in the market, you have very limited time to fix bugs and scale your product. It is good to think about scalability when you start out but you don't necessarily need to implement or optimize your application that way from the get go. Doing that, would lead to bloated code base like Company X had and that would slow down your development cycle, introduce bugs, complicate architecture, and at the end, harder to maintain and scale. Company X thought about scalability from the start but start-ups usually change feature set every few weeks and that is why you should optimize something only when the need arises. Once company X released their product, they needed a full-time person just for supporting one client. The product couldn't scale to multiple clients as is and costing the same.

The problem of time

Sometimes you do everything right like Company Z I worked for did. They had good market research to back up the demand for their product. They created a very good architecture that supported scalability, and they were truly agile. From idea to release took about a week. They had an in-house tester/user for their product. They even got partnership with top two tech giants. That partnership allowed them to reach the global market in the matter of months. They clearly balanced both sides of their user base. This feels like a success story but the startup Z still failed. There was no problem but the problem of time. The company was just early with their product. I am sure the company would have survived, had they started working on it a few years later.

TLDR;

There could be a number of ways a start up could become an ancient history. This tale mentioned how a few decisions had made that possible for a few companies that I worked for. And sometimes even when you do everything right, your start up might fail with the reasons beyond your control. But that shouldn't discourage you because every experience is an opportunity to learn more.