What I learnt from 3 failed projects
Failure is the tuition you pay for knowledge.
When you venture into the unknown, failure is to be expected.
Failure is the tuition you pay for knowledge.
Sometimes, that price is high. Sometimes, it’s low.
From failure, you can find knowledge.
I would not be describing failure in those words were it not for these three failed projects.
There have been other failures as well that have contributed to my general perception of the phenomenon but in this article, I shall only be covering these three instances of failure.
Here are my learnings.
My first failure showed me that I had no idea what I was doing
The project started off with a classic mistake.
Mistake #1 — starting a business with someone you barely know.
One of my cofounders I had met only twice before asking if he wanted to start something with me. That was my mistake. I barely knew him and yet, caught up by the enthusiasm of startup talk, I talked of starting a business and asked whether he would be interested in partnering up.
The other was a high school friend who was doing a technical degree and who I assumed had the technical ability to build whatever I wanted built.
The first work-product we created was a pitch-deck.
A pitch-deck.
It was a lively pitch-deck, full of references to academic articles about the problem we were trying to solve. I thought that made us domain experts. The confidence that came from producing slide after slide of market research created the illusion of progress. I was thrilled.
So this was what it was like to run your own company.
A month into the project, I got rid of one of the co-founders. It seemed like he was not contributing much to the project. In retrospect, the “firing” was done unceremoniously. His equity share? Requisitioned. His contributions? Acknowledged, but in my mind not enough to justify his continual involvement.
I had made another classic mistake. Stressing over equity but as a result, lowering the chances of the project’s success.
Mistake #2 — stressing over equity without realizing the worthlessness of equity at the start of a startup (and probably for the first 5 years of your startup’s existence).
More of nothing is still nothing. That should have been my mentality, and I should have done everything to ensure that all could be done to drive the project forward and attach value to the equity that I had so meticulously distributed.
I have since changed.
And to top it all off, I recruited the wrong technical cofounder, a friend who had technical skills but no track record of developing side projects.
Mistake #3— recruiting the wrong kind of technical cofounder.
I should have reviewed his Github more thoroughly. But I didn’t. The lack of contributions to this repositories should have raised a red flag. It did, but I did nothing to address that red flag. All I had was hope. Hope that every red flag could be overcome through a receptive market and strong product.
Mistake #4 — unclear roles.
As the de facto leader of the startup, my job was to define everyone’s workflow, at least initially. I was in charge of defining the MVP spec. Instead, I delegated that to my technical cofounder. Meanwhile, my other cofounder thoroughly researched the market. His research was good, but without talking to customers, we had no idea what to do next. With no product, no users, and a messy workflow, the destiny of my first venture was clear.
Since then, I’ve learnt about how to recruit cofounders and how difficult that process can be. I’ve gone through 3 cofounders since this project, 2 of whom I recruited on LinkedIn. It is my belief that all good technical cofounders have one quality in common —they build iteratively and incrementally, with a structure of the end product in mine. In short, they build for scale, which is important when you’re iterating quickly on your product.
I brought some of my learnings to my second venture, but I had not given myself enough time to reflect on them to avoid making a few more mistakes.
My second failure taught me that the problem matters
We abandoned the project after realizing that neither of us was experienced enough to build out a payments product. Our intentions were good and my technical cofounder this time came off as scrappy and hungry, but we simply had no idea how to start.
We had decided to build a payments product, but neither my cofounder nor I knew anything about the payments space. I did as much research as I could, but since my technical cofounder could not alone build the entire payments system, it seemed like our product was doomed from the start. This time round, however, we established a very strong understanding of the market we were targeting, and even went out and interviewed potential users, a huge leap forward from my first project where our users were simply figments of our imagination.
We got on phone calls with stakeholders (that I got through cold-emailing), drew out rough user personas, and discussed at length the specs for our MVP. Eventually, the project collapsed as we found ourselves confused about how to start the MVP. Our problem was that there were already a lot of competitors solving the problem we were solving. While our product promised benefits, they seemed marginal to our users (think a few cents saved here and there) and the risk of using a new provider without a brand name worried them. While people we spoke to were interested in the technology we would use to help them save money, we did not look like the team to produce the product.
Mistake #5— sometimes, you just don’t have the right team to produce the product.
I remember getting a phone call from my technical cofounder, who admitted with great honesty that he simply felt like he did not have the chops for the job. We parted amicably and I have a fond recollection of that phone call, which, while hard to accept in the moment, I now see as an admirable feat on part of my technical cofounder. It takes great self awareness and honesty to admit that one simply does not have enough to accomplish a task. It was his admission that prompted me to move on to my third project, a legal tech project.
My third failure taught me that the road is long
This project lasted over a year. This time, I recruited a technical cofounder over LinkedIn. After 50+ LinkedIn messages, I stumbled across an alumnus. After a few brief messages, we decided to work together. For the first few weeks of the project, we worked on other business projects together and found that we worked quite well together. We then started the project, which morphed into two different projects. Neither took off and upon reflection, it was because I could not define the product vision. I was too indecisive, too rushed into my decision-making, which resulted into muddled product development. After a year and a thousand dollars of outsourced software development, we put an end to the project and perfunctorily agreed to resume the project at a later date.
The mistake I made in this project was a simple one.
Mistake #6— I acted as an operator without a vision.
Without a vision, we did everything. Everything felt important. Everything was a priority, which meant nothing was.
This bled into our MVP, which became a mis-mash of random features. We had a spec, but the spec was full of features. As the product owner, I claim full responsibility.
Without a vision of who would be using the product, I also failed to talk to enough users.
After launching, one person used the product.
And that was that.
It’s alright to make mistakes. Just be sure to reflect on what went wrong and what you can do differently in a similar situation to reach the outcome you want. Build, measure, learn. Build meaning try, measure meaning evaluate the effectiveness of your decisions, and learn meaning understand what went right and what went wrong.
Failure is simply feedback, a natural feature of the build, measure, learn feedback loop (a concept from the book Lean Startup).
A ticket to improvement.
