I recently met and spent a few hours with one of our "competitors" who had dedicated over 10 months of his life to building what he thought would be the best data compare tool for SQL Server and then a lot more time trying to promote his work. Now disillusioned he was on a quest to salvage what he could from this investment. I asked him how he made the decision to develop a data compare tool for SQL Server and here is his rationale he presented:
- I have a lot of experience with SQL server;
- Building a tool that compares data in two SQL databases seemed like an easy thing that I could do in a couple of months so the risk wouldn’t be very big;
- There were a lot of data compare tools in the market so there must be a strong demand for such tool.
I asked him what went wrong and here is what he said:
- This turned out to be a lot harder than I thought. Instead of two months I quit my job and spent 10 grueling months and I still wasn’t happy with the results.
- Two months after the release I had gotten a handful of downloads mostly from acquaintances and zero feedback.
I tried to make him feel better by telling him that he was just unlucky but in fact luck is the last thing one can blame for a situation like this. This is the result of what plagues many of the programmers I have known over years, namely;
- Overestimating their ability while underestimating the effort required to get something done;
- Misjudging the market;
- Often believing they know better than the customer what the customer really wants!
The candid conversation I had with him made me think about this. The software business is a great business if you pick the right product and introduce it at the right time but if one of those two factors is wrong then it is a terrible business. Unlike in many other businesses there is basically nothing that can be salvaged in the case of a failed software business. The World's hard drives are cluttered with billions of lines of code that have never seen the "joy" of actually "doing something for real" – they have only been "called upon" by their creator during the development. It is kind of sad!
So before you jump into developing some “me too” tool just because you think you can do it please stop and ask yourself a few questions (not an exhaustive list by any means):
- What is my goal? What will success look like?
- Who am I building this tool for? How will this tool help them? How much are you really willing to pay for such tool if one was available today? Don’t overestimate this! In fact whatever number you spill out first divide it by two.
- Who are the competitors? How is the market divided between them? Which ones do you believe you can take market share from and why do you believe that?
- Have I thoroughly investigated the competing products? What do they do right? Where do they lack?
- How fast can I bring this product to market (whatever time you come up please double or triple it)? How likely it is that during this time one or more of the competitors will release new and improved products that may pre-empt your move?
- What will be that “killer” feature that is going to make the customers choose your product instead of those more established competing products?
- What if things don’t work out? What is my risk?