Taking on Category Leaders
It’s well-known that each software category usually has just two or three players, with a clear #1 gorilla whose products sales eclipsed all others combined. The gorilla emerges because everyone wants to buy the #1 product. Who would want to buy the second best, right? Customers, who don’t purchased the #1 product, probably do so because of lack of familiarity and knowledge about the product category, pricing differences, or very specialized needs.
The conventional wisdom is that, after a certain point when the two or three players have been determined, it becomes impossible for new entrants to emerge. After all, the established players already have a headstart in sales and in completed development work, which the new entrant would have to match; they also understand the customers and the market better.
I somehow think the position of each of the established players is actually far more vulnerable. Just as FOX was able to enter a market owned by the triopoly, ABC, NBC, and CBS, a new software company can potentially displaced any or all of the three established players.
A company that does plan on developing software in a market with established players, however, should not attempt to simply duplicate the work of the early players. That’s a losing strategy.
A new company, in order to be successful, should pursue a radically different, preferably more futuristic, design and solve a different set of problems, which are architecturally difficult for those early players to match. There is still probably a core 20% of the product used by 80% of the customers, that will necessarily have to be duplicated, regardless. Ideally, the design would lend itself to higher development productivity, so that any feature gap can close over time; if not, it may be possibly to score productivity wins by using newer tools such as managed code. Early players are often stuck with the development tools of earlier generation; Microsoft Excel, for instance, developed since the mid-1980’s, is still based on C and somewhat constrained by assumptions and decisions made in a 16–bit, pre-Unicode, and pre-GDI+ era.
The early players will waste time continually adding less relevant features to their best-selling products to satisfy an ever smaller proportion of their customer base. Even after the new company ships the first version of its product, the big players may not even notice or take seriously the threat from the small newcomer until it’s too late, especially since the newcomer’s product appears to be missing a lot of features they support. What they miss is that the newcomer is building an entirely different, more compelling set of features that will accumulate over time. Also, strong, dramatic differences provide a reason for customers to opt for the newcomer's product instead of the market leader's, because the leader's product is not actually a superset and the purchase question now becomes which set of features is more aligned to the customer's needs.
Take, for example, code editors: There are many different commercial code editors, all of which are essentially similar to each other, since they are all text-based. However, if I were building a code editor, today, I would actually be abandon the text metaphor and develop an editor that graphically depicts a parse tree of the source code. This approach allows the editor to manipulate code at a higher level and depict the code in a more user-friendly manner. Refactoring, automated documentation, code formatting and so on are far easier to implement at this level.