The pearl and the mussels
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.
Mussels
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.
Pearl
Two years later, inspired by the homepage of a product (WeDeploy) that I liked so much, I started to build a new product. This time, infinitely more modest. In addition, I was completely protected from the disappointment of no one paying for it. The product was open-source software, it was called Glorious Demo, and allowed a developer to use JavaScript to build an animation that simulated the development and execution of a code snippet. With very few lines of JavaScript, it was possible to create an animation that opens an editor, writes on it, opens a terminal, executes some commands, and returns responses. From that moment, it became possible to do with JavaScript what used to require animated GIFs.
The first positive feedback I get is from the guy who led WeDeploy at the time, Zeno Rocha. His tweet made the project reach almost forty stars on Github. Being for the first time in my life recognized by people who I didn't even know just echoed inside me as the greatest of all successes. A couple days later, on a Thursday night, I post the product on Product Hunt. On Friday morning, I wake up astonished by seeing Glorious Demo as the most upvoted product of the day. The project surpasses 300 stars and get featured as a trending JavaScript library on Github. One of the most popular publications in the world on CSS tweets about the project. A programmer in Seattle creates a website called Road To Glory that allows anyone to use Glorious Demo through a graphical user interface. Glorious Demo becomes a plugin for Hexo by the hands of a South Korean programmer. Blog posts are written in Arabic and Japanese.
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.