Stack fallacy has caused many companies to attempt to capture new markets and fail spectacularly. When you see a database company thinking apps are easy, or a VM company thinking big data is easy  — they are suffering from stack fallacy.

Stack fallacy is the mistaken belief that it is trivial to build the layer above yours.

Comic credit: XKCD

Mathematicians often believe we can describe the entire natural world in mathematical terms. Hence, all of physics is just applied math. And so on and so forth.

Stack fallacy  — “just an app”

In the business world, we have a similar illusion. Database companies believe that SaaS apps are “just a database app” — this gives them false confidence that they can easily build, compete and win in this new market.

As history has shown, Amazon is dominating the cloud IaaS market, even as the technology vendors that build ingredient, lower-layer technologies struggle to compete  — VMware is nowhere close to winning against AWS, even though all of AWS runs on virtual machine technology, a core competency of VMware; Oracle has been unable to beat Salesforce in CRM SaaS, despite the fact that Oracle perceives Salesforce to be just a hosted database app. It even runs on their database!

Apple continues to successfully integrate vertically down  — building chips, programming languages, etc., but again has found it very hard to go up the stack and build those simple apps — things like photo sharing apps and maps.

History is full of such examples. IBM thought nothing much of the software layer that ran their PC hardware layer and happily allowed Microsoft to own the OS market.

In the 1990s, Larry Ellison saw SAP make gargantuan sums of money selling process automation software (ERP) —  to him, ERP was nothing more than a bunch of tables and workflows —  so he spent hundreds of millions of dollars trying to own that market, with mixed results. Eventually, Oracle bought its way into the apps market by acquiring PeopleSoft and Siebel.

Why do we keep falling for the stack fallacy?

The stack fallacy is a result of human nature  — we (over) value what we know. In real terms, imagine you work for a large database company  and the CEO asks , “Can we compete with Intel or SAP?” Very few people will imagine they can build a computer chip just because they can build relational database software, but because of our familiarity with building blocks of the layer up,  it is easy to believe you can build the ERP app. After all, we know tables and workflows.

The bottleneck for success often is not knowledge of the tools, but lack of understanding of the customer needs. Database engineers know almost nothing about what supply chain software customers want or need. They can hire for that, but it is not a core competency.

In a surprising way, it is far easier to innovate down the stack than up the stack.

The reason for this is that you are yourself a natural customer of the lower layers. Apple knew what it wanted from an ideal future microprocessor. It did not have the skills necessary to build it, but the customer needs were well understood. Technical skills can be bought/acquired, whereas it is very hard to buy a deep understanding of market needs.

It is therefore no surprise that Apple had an easier time building semiconductor chips than building Apple Maps.

Google, Facebook, WhatsApp

Google is a great example. It owned our email graph and our interest data (search), yet found it very difficult to succeed in what looks like a “trivial to build” app  — social networks.

In fact, this is the perfect irony of stack fallacy. You can build things higher up the stack. It is just that often it is not clear what to build.

Product management is the art of knowing what to build.

The stack fallacy provides insights into why companies keep failing at the obvious things —  things so close to their reach that they can surely build. The answer may be that the what is 100 times more important than the how.