Howdy Visitor

"The secret of success is to do the common things uncommonly well" ~ John D. Rockefeller Jr.

Lecture# 101 on startup failure

This is the story of my startup that was active between the years 2013 to 2015. I don't know if I should even call it a startup or not because it got failed even before picking up any pace, but let's just call it a startup for the lack of a better definition. So today I'm going to talk about all the things that went wrong, rather I did wrong that led to its failure. And although this is about my startup, the same principles apply to any product you are building or planning to build. Please note that this post is not about what to do in a startup, it's about what not to do in a startup.

Before I begin with all the mistakes, let me quickly talk about the startup itself, its background, and the idea behind it. So the name of my startup was MCQStreet.com, and in case you are wondering MCQ stands for Multiple Choice Questions. Back in mid-2013, an idea came to my mind to start a website that will cater to a specific use case and persona. All I had in mind was this, a teacher should be able to quickly assess the performance of his/her students, perhaps after a certain class, in a seamless manner and without worrying about physical question papers, answer sheets, etc. A teacher should be able to quickly prepare an MCQ-based question paper online, distribute it among students and get the assessment/performance details immediately after the test. It sounded like a great idea at the time because "online assessment" was growing at the time but not in such a scale or volume that we see nowadays. So I made the most feature-rich website that I could build and launched it, but nothing much happened after that. People came to the website, checked it out, and then left. I tried many things e.g. added new features, even made a video covering all the key features, but nothing worked. Eventually, I decided to close down the curtain in mid-2015. So, why am I writing this now? I realized many things over the years that I did wrong that led to its failure, and I want to share those with you. And as I said earlier, although the mistakes I'm going to talk about here are related to my startup, the same principles apply to any product you are building or planning to build, so you should watch out and avoid these mistakes.

Below are a few of the key things that I did wrong and you should avoid to not fail in your startup or product. I know there are other factors as well but this can be your starting point.

Not testing your hypothesis: When you think about a problem to solve, that's your hypothesis. You need to first test your hypothesis even before thinking about a solution. You need to do some user research, run ads, talk to potential users or customers to figure out if your intended users or customers are facing this problem and if this is the right problem to solve. Of course, you can also look at direct and indirect competitors to see what they are offering to solve the similar or same problem, but that's an extension of what you can do to test your hypothesis. And while you are at it, don't get into the trap of analysis paralysis. Remember, you might not be the user of your product, so just because you think of something as a problem, that doesn't mean that your target users or customers will also see this as a problem. So this was the first and foremost problem in my startup - I didn't test my hypothesis, I thought about a problem and straightaway went into building the solution. 

Not releasing MVP: We, as developers, want our solution to be perfect and feature-rich in the first go, we don't want to settle on anything less than complete, especially when you starting your startup journey and you are building the solution yourself. Don't make this mistake. When you are building the product or solution, think about the core feature or set of features that your product or solution has to have to solve the problem, include only that feature or set of features in your product or solution, and then release your MVP (Minimum viable product). The sooner you launch your MVP, the better feedbacks or validated learning you will get, and you will be able to iterate quickly to improve the product or solution. So this is a mistake I did in my startup - I spent almost a year building the most feature-rich product that I could build at the time and released it one go, I didn't release any MVP to get any feedback or validated learning.

Not gathering or paying heed to feedback: Feedback can be qualitative and quantitative. An example of qualitative feedback could be verbal or written feedback from your user or customer, and an example of quantitative feedback could be the acquisition rate of your product or solution. Both kinds of feedbacks are useful in assessing the progress of your product, and it depends on your product which one would be most beneficial for you. I'm not going to dive much into the details as this is very product-specific and you can Google to find plenty of articles covering this topic i.e. which performance metric to chose for your product? when to collect feedback? what is the right time to collect feedback? etc. This is probably where I made the biggest blunder, I didn't collect any feedback (be it qualitative or quantitative) other than the number of users who have signed up on MCQStreet.com. I didn't talk to any of the existing users or potential users, I didn't ask questions to gather feedback on things like, what things did they specifically like about the product? what they didn't like about the product? etc.

Focusing too much on fundraising: People, quite often, start looking to raise funds before or immediately after launching the product. I did this mistake too in my startup. You have to realize that there are many companies and businesses out there that run in bootstrapped mode even after becoming successful, so you have to figure out which one would be good for your company or business. I might throw in revenue here as well, but again, these two are product-specific decisions.

Not knowing when to stay on course and when to pivot: Feedback or validated learning is an excellent way to decide whether to stay on course or pivot. It is our natural tenacity to keep the product and company moving forward, even if feedback says otherwise. We keep on trying things to make the product successful. Now, the timing of the "whether to stay on course or pivot" decision may be debatable but you should be open to feedback and flexible enough to pivot if such need arises. In my startup, I was not in a position to make this call because I wasn't collecting any viable feedback, which eventually led to its failure.

Not focusing on the problem: This is about the mindset. People start with a problem in mind and, sometimes, get deviated while or after building the solution, they start thinking about the massive user base that they think their product or solution will fetch, they start visualizing their solution as a multi-billion dollar enterprise, etc. I know it's fairly natural for any one of us to think like that, but you should continue to keep your focus on the problem i.e. what problem are you solving and why are you building this solution or product? Unfortunately, this was one of the problems in my startup as well, I got deviated after releasing the solution and started thinking about a massive user base that I thought my solution will fetch, I stopped focusing on the problem and started thinking about how can I make this a business. I know, I know, I was that naive back then.

I know there are numerous other things that you need to take care of to make your startup or product successful, so you can think of these as chapter# 1 of that list. But having said all these, don't get discouraged and quit if your startup or product fails. Remember, great products fail too, but people don't stop trying because of failures.

Author: Rajdeep Paul | Dated: July 23, 2021 07:34 PM(IST)
«  Previous post Next post  »