A purpose for the product
February 24, 2019
There’s a constant tug of war between building a product with superior capabilities or one that is boring but solves a problem. Which one would you prefer?
As I look back, I’ve the committed the crime of giving into the allure of a grand technology, or a great engineering process in past. As an engineer, it is always exciting to learn awesome stuff, work on the cutting-edge. At times these are deciding factors in choosing what to build. Back in 2012ish, we built a beautiful nosql based error analytics system with classification etc.. We followed test driven development with excellent code coverage. It was a fantastic learning opportunity and probably one of the best teams I worked for. We were technically quite strong, product was probably ahead of the times (?), yet we failed to get business.
Few years later, we were building a test platform. I and a close friend/colleague would often ponder over something we used to call moving the needle. Every feature or fix should move the needle, i.e. be better than the last state of being. Building the best test platform out there was our dream. It was an extreme high bar to jump over. We tried taking a few bets, some of them worked, and a few didn’t take off. There were times we would imagine our team had everything required to be the best test platform, but we were not there (yet). We kept pushing step by step, brought a closed platform to the open source world, freed bunch of debt in the IDEs and did several great releases. All good so far.
Except we missed one thing: we went after the awesomeness of being the best. We (secretly) rejoiced in providing capabilities no one else had in the market. That made us happy.
We lost sight of the actual customer pain. Some of that illusion of greatness took a setback when we realized some of the greatest capabilities are not the most used feature. Guess what - the boring tasks still beat the shiny new feature by a wide margin. We thought, may be we should have invested more on the shiny feature. It didn’t take off because of so and so reasons.
The allureness of best still followed like a shadow. Now the problem was externalized. Externalization masked retrospection and we got frustrated thinking we are awesome but rest of the world blocked our journey to be the best :D
I know it sounds ridiculous. Well, fast forward a few months and projects, I got my zen moment during a lecture. The speaker firmly proclaimed Software is a means, not an end. The best product out there is the one achieves the desired outcome without writing those million lines of code. The best product is the one that everyone assumes to have always existed.
So the best test platform is the one solves the stupid boring problems in a simple way. It is so intuitive that nobody needs to learn to use it. It adapts to the beginners and experts alike; once the users are experts, it makes them better. Success is to see it used everywhere, being ambient and solving problems without the noise of being the best.