You shouldn’t be chasing perfection in projects.

It’s 11 PM, 12 January 2020, I have been working secretly on a project that allows teachers to teach and store their coding lectures completely online on a local level, inspired in part by Scrimba (People who program, specifically in JavaScript or Python know what I’m talking about).

It’s been a tiring day and I finally take a sigh of relief as one of the biggest features I had been working on for a long time is finally done. I say to myself: “This might be it! I can finally launch this to be used by teachers and their students.” In fact, I was so relieved that a vital feature was introduced that I thought I could roll it out tomorrow and start advertising it and putting it up on the “Startup Ideas” subreddit so everyone validates that I am a genius and praises my idea.

I went to sleep happy that I had a productive day, got stuff done and was ready for an exciting next day. It was right at the moment I was about to fall asleep that my brain went into over-analyzing mode. In the next fifteen minutes, I realized that well, many things could be done for the user to like the app I built, even more, just a tiny bit more.

So my over-analyzing brain threw potential feature after feature at me which I couldn’t dodge, and the important thing about the features was that the features weren’t incremental add-ons on top of the existing app, they were basically features crucial to be implemented, yet just not crucial enough to delay the launch of the app. I had been working on the project for roughly 2 months, all alone, had set up the entire infrastructure and stack myself from whatever I had learned in various previous internships and freelance gigs I had undertaken, and of course, was pretty proud of it. So as my brain suggested feature after feature my natural instinct was to confide in the thought that:

“Yeah, we can add that later, of course, people using it first-time don’t expect it to be perfect!”

However, as the pile of features grew larger and larger I turned to:

“Yeah, the user does need these features, even though I am creating my first service, if the service isn’t good enough, they will simply go away.”

The above is a completely justified statement when you are building something for the first-time for someone else to use, you obviously want it to be flawless and as good as any other service like it, if not better, which it should be for attracting users in the first place. After all, what does your service offer that the others like it do not? (Except when you’re tackling a market no competitor is present in, in that case, stop reading and go run to release it to your target audience!)

Add to that the fact that customers in the digital economy have gotten used to using fully-featured apps and services with basically everything out of the box the moment they purchase it or start using it, and you will understand what was going through my mind at that point. The app needed to be Perfect! Otherwise, the users I was targeting weren’t going to use it, at least that’s what I thought. The ‘just a tiny bit more’ was the empty part of the glass that never really filled no matter how much water I poured into it!

To give the reader some context, this was probably the third time in around 2 months that I was thinking I had reached the MVP stage of my app, and then had stopped the launch or postponed it because I thought the app wasn’t ‘ready’ or ‘ready-enough’ for usage by people. The people I envisioned at that time to reach those conclusions were probably people who would close the app, uninstall it, and never look back at it the moment a loader appeared on their screen for more than a second, or whenever they encountered an error message on their screen that read something they had no idea about, or when they wanted a feature and couldn’t find it.

Yet again, the above fear was justified, people are like that, and those thoughts also have a lot to do with the fact that I myself might be one of those people who wouldn’t use an app that was incomplete, or even looked slightly incomplete, yet, here I was, trying to push out an app that itself might have lacked some features that users might want. From these experiences I have learned one thing very well:

An app or product’s first release to the public is often incomplete and is followed by a hope that people use a product that you might not use yourself if you were in their shoes.

And the fear is even more real if you are hoping even before the first launch or completion of your project. In fact, the fear can be so overwhelming that you might start wishing that people not use your project so you don’t get any complaints regarding it in the first place, which again, is something I did (This is also a reference to The Lean Startup).

In reality, first time users of an app are more forgiving, especially if your app does what it’s supposed to and what the user needs, less some additional glitter on top. This is one of the biggest reasons an MVP or a Minimum Viable Product exists in the first place, and an MVP is an extremely good way to test whether your app caters to the needs of a lot of people, because if the MVP is used by a lot of people and the user churn rate is low, congrats my friend, you have just built a product that given its flaws and lack of features, is being used because it delivers its core promises well or serves the needs of its users well.

Make note of the above paragraph pretty well, because it is what the rest of the article is based on.

---

Mistakes Starters make on a project that makes them abandon it or never release it to the public:

• Trying to over-optimize things (In my case: code) delaying launch.
• Trying to solve problems that do not exist.
• Adding features to products that the end-user/target user does not need.

Why Perfection chasing is bad during project beginnings:

1. The first reason why perfection shouldn’t be chased in a project that is just taking shape is because of course, it’s the beginning, today YouTube has an architecture that can support billions of people watching videos simultaneously, but at the beginning, optimizing for that scale and robustness would have only bogged the project development down and might have even gotten people laughing at the guys coding YouTube into existence.

2. Another reason is that a product only needs to do what it promises to well enough for the users to get hooked, and coming back, perfecting it is wasting time that could be spent on improving the project after the user has gotten their first taste of the product.

3. Perfecting a product delays launches and end-user reach, and again, the whole point of a first launch is mostly to test whether there is scope in the market for a product like that, if you spend so much time on perfecting features, over-optimizing things before you even have your first release out, you might discover that you created something that the end-user might not even want, which is much worse than releasing a basic product in the market and then realizing the same thing.

4. Most of the features and perks in the product you might think that the end-user needs, might not be required (Unless of course if an end-user survey has revealed otherwise.) since the user might not even feel that they need it. For example, today we have come to expect ‘stories’ to be a basic feature of almost every social networking service, let’s assume Instagram founders had a bright idea of a photo-sharing app, now if they had decided then that their users might want to share photos in 10 different ways like they do today, that would not have been ideal certainly, in fact, it might have been confusing and counter-productive to dump so many features at a naive user, instead products are meant to be incremental, building on top of the previous iteration.

5. No matter how hard you try, you can’t release a perfect product. Google still has backend issues with their products, there are bugs in Instagram, unexpected crashes on our favourite websites happen and Amazon and Microsoft have poor design consistency in their products, even though the youngest of the above companies is over 8 years old! But do we stop using them? Probably not, because they deliver their core propositions pretty well, and that’s all end-users need.

Another good example of point number 5 would be InsideSherpa, it’s a great website, but it’s got parts of it that are unpolished, but thousands still use it because it provides value to its users.

All the above is no excuse to not have a “good” product, it’s just an argument against trying to release a “perfect” product pre-maturely (Which is never going to happen).

Okay, so if perfection doesn’t work? What does?

1. Research your target audience and know what they need beforehand to save on development time.
2. Build your product to the point it fulfils its core promises well, and nothing more for testing with your target audience.
3. Spend an optimal amount of time optimizing core features, nothing more.
4. Release the product to the audience and build incremental changes over received feedback.
5. Be open to the fact that not everything will be perfect no matter what you do.

These above points can save you a ton of time, and you can take this from me, the product I launched to my target audience was what they never needed, and get this, bigger corporations launched competing products (I doubt they knew what I was building, of course.) that performed much better, at that moment, the time I wasted building features that the end-user did not need cost me a significant loss in the amount of market I could capture, which soon turned to 0, and I probably need to pivot my business model completely. Another mistake I made was that I simply didn’t research what the target audience needed.

My product started as a side-project, and I had no idea I would ever think of it turning to something that someone else could use, which is ironic considering you build something with the goal of it being used by someone else eventually.

I request whoever is reading this to not make the mistakes I made, and those mistakes certainly serve as a reminder to me.