Designing Products and Businesses: The Stack Fallacy

I recently came across a fascinating idea in Anshu Sharma's "Stack Fallacy" article (2016):

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

As an example in the software world:

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.

When people talk about product ideation, the stack fallacy is a natural corollary to "build what you know" and "use your own products".

To run with the ERP example: at Kwiat (a DTC diamond jewelry company), we were ERP users and knew exactly what we needed from a system. This informed our vendor selection, ERP design, and also helped us design custom features around the ERP to support our workflows.

We had a software partner who worked with us, but their primary expertise in writing software, not selling jewelry. They, however, were that was continually trying to innovate upwards. Said another way, they were trying to solve other people's problems, rather than things they were familiar with.

They would design sell-through systems and inventory management platforms, and monitoring tools for clients up the stack. As such, they were constantly trying to figure out what to build, how it should work, and were turning to us for user-testing. Needless to say, I never saw their products become 'naturally' usable and interesting.

In the best cases, the vendor – whether it be the tech partner (such as SalesForce) or an independent product creator (case above) can provide guidance on what the technology can enable, and can aggregate insights in how other clients are using it.

At worst, the platform is dictating how our workflows need to conform to it, and loses nuance with regard to the day-to-day 'lived realities', forcing workflows to move to more informal channels outside of the implemented systems.

This is also the case at Pager (a care communication, coordination, and collaboration platform), where I currently work. We run our our own clinical command center, and so we're the first natural user of the technology platform we build and deploy for clients. This informs the features we build and helps us stay two steps ahead of our clients' needs. As a SaaS company, we're using our own technology and innovating down the stack to replace vendors with solutions specialized to what we need.

This also informs my personal projects and companies. Dragon Blood Balm was born out of my cofounder and my needs as climbers. Recommended.Systems is a byproduct of innovation down the stack: as a marketer and research, I had to build the tools I need to do my job because no one vendor was properly identifying the challenges. So we're constantly pushing down the stack, rather than up.

So that's the core lesson: innovate downwards. If you're looking for "business ideation," you're likely not going to find a good product-market fit. Most naturally successful products and businesses that I know scratch their own itches, or evolve out of solving their own problems – or problems with which they're deeply familiar with -- first.