What didn't work: failing with 5 startups before not failing with one
Before Loki.ai became a financially sustainable venture, I failed with 5 other startups over 5 years. Here is what I learnt.
May 29, 2020
I ran my first "business" when I was a high-school student in 2009, selling t-shirts to orientation groups as the President of my high school's entrepreurship club. We made around $25,000 in revenue from it, but weren't allowed to keep any of the profits. I thought that I had entrepreneurship all figured out at the age of 17, but later realized that selling in markets where you are not a well-liked and well-known monopoly is a far cry from selling t-shirts to your friends in high school.
I have recently received emails from people whose internship offers and job offers have been retracted, and some who have been laid off. They have asked for advice on whether it's worthwhile to try and launch a startup at this time so they can make the most of a bad situation. This post is an attempt to share my experience about the issue without directly answering the question – in hopes that readers will make up their own mind.
I have run 6 product-based startups since graduating from high-school, and have failed miserably at 5 of them. All 5 failures had different causes, and the lessons learnt from them have made my 6th attempt something that hasn't failed so far (3 years and counting).
Failure 1: Qualitics
I worked on my very first startup in 2012, at the age of 20. We created a smart analytics system that created automated alerts when a manufacturing process deviated from its specifications (or, in Quality control parlance, went "out of control").
To do this, we built a tool that allowed users in developing countries to enter quality measurement data through an SMS (this was before smartphones were as cheap as they are now), and get automated alerts if our algorithm detected that the specifications of the production output deviated too much from the norm.
Why this failed: Our target customers (small manufacturing companies in India) did not find much value in this product because quality was not a top-of-mind concern for them. Production was, and our offering did not help with production at all. Also, we had real-time electronic records of all quality data, which would have been difficult to forge and modify later on (something that is a common practice in India). Larger companies that saw value in this already had automated systems and got no benefit from our product.
My role in this: I was the business-side founder. I worked with two very talented developers (Rahul and Meng Xin) to create the product.
Lesson learnt: It’s important to learn how to code if you want to iterate on product quickly based on user feedback. I was trying to sell the product in India, but the two developers I worked with were both in Singapore at the time. This led to an inability to quickly iterate on the product. While quicker iteration would not have saved this idea, it motivated me to learn how to code. I was the technical founder in all subsequent projects.
Failure 2: The After Sales
After Qualitics failed, I did a B2B marketing internship in 2012 and learnt that customer churn is a major concern for many B2B companies. I though that creating real-time customer report cards to quantify churn risk would solve a real need in the market. To address this, we created theAfterSales in 2013 – a dashboard for identifying customers you may lose before you lose them.
Why this failed: We did not have a good understanding of how the industry works, and did not offer any integrations with pre-existing tools (Salesforce and other CRMs). Instead, we expected users to input data into our own systems. This was a no go for customers
My role in this: I was the product person and developer. I worked with two friends on this – another technical co-founder (Jing Ping) and a business co-founder (Yash).
Lesson learnt: Domain expertise and understanding of an industry is critical for products to take off. A fancy dashboard is useless if data entry is a pain.
Failure 3: Quiztra
In 2014 (my last semester in college), I stopped going to classes and instead focused on becoming a better programmer by bingeing on Coursera, edX, and Stanford online courses. I also launched Quiztra – an e-learning tool for college and pre-college students. It tracked students’ performance across topics, understood their strengths and weaknesses, and gave them more difficult questions for topics they were already strong in, and easier questions for topics they were weak in.
I pursued this idea for a really bad reason – I wanted to get hands-on experience building a B2C product, and working on an ed-tech idea seemed like the most accessible way to do this at the time.
I created a SaaS service that executed this. First, I tested this out with a bunch of NUS students for an introductory Math course (roughly 100 users) two weeks before the exam period and saw encouraging results in user retention. After graduating from college, I tested this with coaching centres in India for 6 months, and added more functions (including a student report card, bubble sheet scanning, and more)
Why this failed: I did not have any content of my own. While the technology was fairly useful, not having any original content (in this case, exam questions) made it difficult to do much with it. I tried to partner with cram schools in India to push this forward, but didn’t receive much interest from them beyond requests for more suggestions after which they would consider the product (I have since learnt that this a polite way for potential customer to say no). They were running wildly profitable companies that provided in-person coaching, and didn’t see much point in going digital (which they thought would reduce profitability).
My role in this: I started out with a friend (Arjun) who was critical in early product strategy and in getting user feedback within NUS. But was by myself when I moved to India to try this out with coaching centres in hopes of addressing a larger market.
Lesson learnt: Thinking strategically about the value ecosystem of a startup is super important before one spends months building a product. I should have realised that the lack of original content would be a problem, and that coaching centres would not have an incentive to go digital.
Failure 4: Deepo
This was the first (and so far, only) time that I had worked for someone else. I was working at a startup called Gimmie at the time, and the CEO wanted to branch out into a new company. We created an automated analytics platform and recommendation system for media and ecommerce companies. We asked users to add a small javascript snippet to their site. Once this was done, we would automatically add content or product recommendations to their websites (think a better version of “read next” recommendations). At the same time, we built an analytics tool that provided the same functionality that real-time analytics tools like Chartbeat do.
My role in this: I led product and data science for the company. Our CEO (David) led business, while our CTO (Keang, a college classmate) led the technical infrastructure. We managed to get multiple companies – large and small – to try this out (including very large sites like Hardwarezone and Khaleej Times)
Why this failed: This could have worked under different circumstances. My CTO and I were both relatively inexperienced at this time. While we managed to get the system working and add value to clients, we did not have a high uptime and some of our systems crashed whenever we had to handle traffic for more than 5 million pageviews a day. Moreover, we found it difficult to raise money to hire senior people as much of the equity in the parent company had already been given out to investors — leaving very little room for additional capital. I felt that it would be difficult to continue growing the company if we were unable to hire senior infrastructure people or raise more money, and left the company in December 2015. Deepo was shut down as a standlone entity in January 2016.
Lesson learnt: Being great at data science is not enough for building a big data company. One needs to also be a good engineer to build systems that perform well at scale. This was a lesson I took to heart and doubled down on becoming a good data engineer afterwards.
Failure 5: The Broadline
This was an attempt at reimagining a media company from scratch. I wanted to completely reimagine journalism for the web, from building a new CMS to treating personalization as an foundational priority, to building better tools for research and data visualisation. I did not have much hope of this succeeding as a standalone entity, but wanted to do this as a proof of concept for larger media companies.
I set up a news website and Facebook page called The Broadline, and built a custom CMS, recommendation engine, and research tools. Also learnt how to engage with and grow an audience through Reddit and Facebook. The site never really took off, but had just under 10,000 monthly users at its peak.
Why this failed: I never tried hard enough to make this succeed. In the back of my head, I wanted to use it as a proof of concept to showcase technical capabilities to larger media companies who I could then sell other services to. To that end, it worked really well and helped me land some customers that I continue to serve to this day.
Aftermath
Going through these failures was a fairly painful process, but it was also a fantastic learning experience. The lessons learnt with Deepo and The Broadline helped me improve as a developer and as a thinker, while the lessons learnt from previous startups helped me learn the ropes of creating products.
If you are considering launching a product right now, be aware that it may not succeed. But if you iterate quickly, keep your expenses low, and learn from your mistakes – launching a product is very likely to help you improve your skills. If you have time on your hands, I would strongly recommend launching a product if you treat it as an opportunity to serve your users and improve your skills (rather than a get-rich-quick scheme).
Have feedback, or open to sharing your own experiences?
If you have feedback about this post, or want to share your own cybersecurity stories, please @ me on Twitter at @rishdotblog.