Octocash. That was the name of the product that I, and two colleagues, launched four years ago. Starting to build a product in the early stage of your career is such a great experience. Every member overflows optimism. Optimism is so abundant that nothing more is necessary to develop the product. The level of enthusiasm is so high that understanding profoundly a problem becomes optional. After designing a logo and the first application views, we worked hard until putting the product in the market. Visitor after visitor, we begin to measure a bitter result of zero conversions. So we sadly realized that it required more than just opening the store to make a business succeed.
Still disappointed, we started to figure out the possible reasons that dared to drain our ocean of optimism. The bets have started. Most of them pointed out a missing feature as the principal cause. Users do not convert because the product don't do this. Users do not convert because the product don't do that… Very quickly, we had a big pile of work to do. The more we discussed, the more features we would like the product to have. We believed that with each new feature added to the product, we would be increasing the chances of someone to pay for it.
Given that long list of feature to do, and not believing that we would be delivering anything that competitors did not already do, I decided to quit the project. Even though we were very excited, I concluded that a complete lack of understanding about the problem made us unable to deliver anything that would delight our customers. We were trying to convince ourselves that the product could succeed by gathering as many mussels as possible, not noticing that we had no pearls to offer.
Now, eighteen months after launch, that small product made with 80 commits reaches 3,000 stars of popularity on Github, and the project's website counts tens of thousands of visits from over 150 countries. I have no doubt that in November of 2018, I had accidentally discovered a pearl.
Impact over features
If missing features use to be the explanation for the low engagement of the users, perhaps the real problem is not that, but the fact that existing features simply don't delight anyone. In the book Rework, Jason Fried and David Hansson comment on competition and the number of product features in a section called Underdo your competition. Surpass your competitors by doing less, not more.
Conventional wisdom says that to beat your competitors, you need to one-up them. If they have four features, you need five (or fifteen, or twenty-five). If they're spending 0,000, you need to spend $30,000. If they have fifty employees, you need a hundred.
This sort of one-upping, Cold War mentality is a dead end. When you get suckered into an arms race, you wind up in a never-ending battle that costs you massive amounts of money, time and drive. And it forces you to constantly be on the defensive, too. Defensive companies can't think ahead; they can only think behind. They don't lead; they follow.
Once in a while, we may find ourselves in a situation where the product is considered behind a competitor because it has fewer features. A situation where the success of the product necessarily consists in surpassing the big list of features that the competitor already offers. At that moment, we may fall into the temptation to drive the product towards a path that is unable to surprise our clients. We can absurdly conclude that our product will delight our customers when it delivers the same features which competitors already do. Believing that we will beat a competitor by having more features than having the right features is like to gather mussels. It does not matter how many of them you can pile up, they will never beat the impact caused by the bright of a tiny pearl.