Entrepreneurship is not for weak hearted. This thought came across my mind during my recent project with an American client who is building an online platform for south east asian markets. (NDA agreement doesn't allow me to name the startup.) This post is not about that project but just few lessons and realisations.
For any business to be successful the offering should be better than competitors to stand out. The offering can be a service or a product.
When we speak of internet based startups, more so about the startups where user do everything online as compared to the startups having just the informational website and main business/service is offline, the product is the website, apps and the backend systems which enable consumers do certain things.
Everyone outside a startup ecosystem, and even a few inside it, might think that success is all about making the right decisions and the creativity or the idea, but speaking the truth, most early stage startup founders spend 90% of their time building the product which is executing the decisions taken in the 10% of the time. This execution is the part called hard work which is equally critical for success as much as taking the right decisions and being creative.
This "building the product" comprise of designing, coding, testing and deployment. Out of this the design again takes less than 20% of the building the product. Actually building the product is 20% design, 20% coding to build it, and 60% testing and bug fixing.
Building the product is 20% design, 20% coding to build it, and 60% testing and bug fixing.
This may take out all the glamour from the word of "starting a startup", but this is the reality which a bootstrapped startup's founders have to go through. If you have funding, and you are getting it developed by someone else, even then the testing and making it right is the part of the process that you just can't escape.
It may sound the easiest but testing the same thing everyday for few months which is almost never works for a long time in a particular way and then making the developers understand what exactly is wrong and then checking again if the fix that devs have pushed is a very monotnous work. Even the UI part and making a webpage look beautiful takes a lot of iterations.
If you are not a part of the IT industry or have no coding or product development experience then it becomes even more daunting. If you do not understand how the software development process work from inside you are bound to get frustrated and depressed as a startup founder and make the team despressed as a result which can cost you pretty much your startup.
It is very important to set your expectations right while trying to build a product. Talking strictly in the terms of an internet based product that you are trying to build.,I have a few things to say. First of all get above petty things like an apology or allegation or things like who said what. Those things may serve you good if your intention is to drag someone to court. If your focus is anything else than building the product that you have set out to build you will most probably fail. Your focus should be to get the bugs fixed and not why the bugs are there and who should be blamed for this. Developers don't have a hobby to plant bugs so that they have to labelled as bad coders. Just get over it.
Also one of the most important thing is that there is nothing like a stable codebase. It is the version of codebase which is stable. Every time you make a change to a codebase it becomes unstable and it needs to be tested again and bugs need to be fixed to be able to be relaiably stable. And truth is that defects can always be there. No system is perfect in the world. Even google and facebook codebase is not bug free. And that is why they give away bug bounty. The enterprise level solutions that big companies provide can only promise for a "support" and can't claim that nothing will go wrong ever.
Why Do Bugs Happen?
- Bugs are there because there is some condition, some scenario which has been untackled in the code.
- There can also be bug if there is a spelling mistake in code or some silly thing happens by mistake.
- One of the fix is made for fixing a bug that was caused by reason given in point 1. and it was not fixed for all the impacted areas of code.
The second kind of bug is rare and it gets identified in the development itself. And even if it gets passed to the test environment it gets identified. The first kind of bug is something that is the most common. The third kind of bug needs to be fixed with the help of rigorous testing whenever any fix is pushed to test environment.
Getting Real
It is best to accept that human error will happen. The developer will miss out certain use case and the bug of 1st kind will occur. Expecting that no bug of first kind will happen is like assuming that your business plan will be executed word by word and there is no chance of it getting changed midway. A piece of software is certain lines of characters written to make some logic. The more time developer gets to plan out the logic the better the logic becomes and cover more and more scenarios. But usually what happens in the real world is that there is always time constraint and as a result almost always developers just rush to finish the work.
So the only solution is to be patient and go through the testing and bug fixing part of the work. It may take time but this is something which separates the successful startups from the failed ones. Someone correctly said:
It is always less crowded when you go that extra mile.
This phase of the work can even give you some more ideas about improving the product by adding new features but my advice will be to hold horses and get the stable and tested version of code deployed before making more changes to a codebase which has progressed towards stability. Do not make it unstable again by getting some new coding done for new features.
Analytics
Setting up analytics and conversion funnels can help a great deal in identifying the areas of the product which needs optimisation and areas which need a second look for identifying any major UX issues which are not exactly bugs but may have been giving hard time to users do things that your product offer.
