September 28, 2019

Enterprise Software Is Dead

Going forward it’s all just business software.

by @awwstn

founder/ceo @capiche
awwstn's avatar

For decades, a stark distinction existed between enterprise software (targeting Fortune 2000 companies) and the rest of business software (targeting mid-market and SMB).

SMB could be a path to the enterprise, but the categories were vastly different. Different buyer personas, different brand goals, different product priorities, and different sales cycles.

Those differences are fading away. The distinction of enterprise software is becoming irrelevant. Going forward, it's all just business software.

Before we dive into this, let’s talk about what “enterprise software” was.

"No one ever got fired for buying IBM”

Enterprise software was generally bought by CTOs, CIOs, and CEOs. They’d make a choice largely based on what the analyst firms told them, and were incentivized to make the safest possible choice, not the best choice.

It didn’t matter much if their employees liked or hated the software, because they had no other choice. It didn’t matter if the software got less-than-ideal results, because the decision-maker was shielded by consensus. They could point to analysts who recommended a product, and other companies which made the same mistake.

The famous adage “no one ever got fired for buying IBM” really did sum up the way this industry worked. You could make a tool that solves a problem better than IBM, but few executives would risk their careers to try it out.

So, the vendors had to play within the rules of the established game. They had to climb up through SMB and then through mid-market, and finally break into the Fortune 2000. Each step along the way required a beachhead.

As they climbed, they had to continue impressing (and paying) the analyst firms. They’d wine and dine analysts and executives at swanky steakhouses and exclusive cigar lounges, because that was the way it had to be done. Of course it mattered if their products were good, but only to a point.

The way to win was to become the thing that executives could choose without taking a risk.

Then SaaS happened.


First came the cloud, then came SaaS. SaaS—with its monthly billing cycles and lightweight implementation processes—allowed companies (mostly SMBs at first) to try, buy, and switch tools with very low friction.

As has been covered ad nauseum over the years, this also made it orders of magnitude faster and cheaper to get a piece of business software to market.

SaaS unlocked whole new markets for tools covering narrow use-cases to become big. Categories like CRM, file-sharing, company communication, project management, and lots more suddenly became behemoths.

People started to get EXCITED about enterprise software.

We all knew SaaS would create tectonic shifts, but it wasn’t clear until the past couple of years just how significant those changes really were.

The Bottom-Up Revolution

First, and perhaps most significantly, he days of central IT making the buying decision for every person in a company started to fade away.

It started with a trend called BYOA (Bring Your Own App), where teams and individuals would go rogue and start using a tool that helped them solve something. Often, this behavior would begin in a team.

But then, tools started to grow virally within organizations. A small task-force would adopt Slack, then their wider team would adopt it. Then neighboring teams would adopt it. Then teams in other departments would adopt it. Then, eventually, executives would have no choice but to adopt it company-wide.

For the first time, these executives were facing a different source of pressure around adoption: Employees.

When the rank-and-file had no insight into the buying process and no familiarity with other tools on the market, they had no avenue to organize and push the organization to adopt new tools. But when they’ve been using an alternative solution, and know it’s more effective and makes them more effective, then they’ll stand up and demand it.

Developers were among the first employees to gain influence over buying decisions.

While "developer evangelism" has existed for decades, Twilio pioneered its modern form. They hired engineers for the sole purpose of travelling the world and meeting developers at hackathons and meetups. Their goal wasn’t to sell Twilio’s products—it was to help developers with whatever they were building, give away swag, and spread love in the developer community. Instead of shmoozing executives and analysts, they celebrated developers and the things they were building.

At the time, this seemed like insane approach for a company that would clearly only become huge via enterprise customers. No individual developer had any purchasing power.

But when Twilio started selling into the enterprise, every developer on earth knew who they were, and millions of them had used Twilio for side projects and knew Twilio’s developer evangelists in real life or online. For a procurement officer to choose anything but Twilio was a death wish. Twilio built an army of brand advocates who continue to deliver for them year after year.

In a silo, Twilio’s “Ask your developer” campaign wouldn’t have been remarkable. What made it remarkable is that any exec who listens to it, and asks their dev team what they think about Twilio, will discover a rare level of brand affinity and trust.

This shift toward bottom-up adoption happened slowly at first. Now it’s happening all at once.

Consumerization of Business Software

Businesses that are resistant to change and slow to try new things. If it’s not broken, don’t fix it. Consumers, on the other hand, are nimble and eager to find the next new thing. New consumer apps pop up with new paradigms and better user experiences, and we flock to them.

As software started to be adopted bottom-up, business units began acting like consumers. A small team will try a new thing on a whim, and if it doesn’t work, they'll move on. If it does work, they’ll keep using it, and even spread it across their organization.

Employees suddenly have a voice they never had in the past, even for software that is adopted centrally by the top of the organization. They’ve used the shiny new tools, they understand the pros and cons, and they have opinions.

If you’re an executive making a buying decision in 2019, sure, your board won’t fire you for making a conservative choice. But a mutiny in the rank-and-file will take you down just as fast. So you need to buy a tool that your employees like, and that they find useful. You need to care about design and user experience just as much as SLAs and Magic Quadrants.

I’m not sure if anyone has been fired for refusing to buy Slack, but I do know that a whole era of executives’ lives got a heck of a lot harder until they finally agreed to buy Slack.

Number of Tools Companies Use

Over the past 15 years, the number of software tools that companies use has exploded, across all sectors of the market.

A recent study by Okta showed that the number of apps in use has increased by 68% for large companies and 43% for small and mid-size companies since 2015. What does this shift mean for enterprise software? Solutions that once scraped by as thrown-in features of enterprise suites (think: performance management, team communication, file-sharing, etc.) are now competing against well-funded SaaS companies hyper-focused on that single solution space (think: Lattice, Slack, Box).

It also means that the days of “set it and forget it” enterprise contracts are gone. After a vendor closes an enterprise customer, they no longer can count on years upon years of lock-in. Starting day 0, they are competing with products offered by other vendors, as well as an endless stream of upstarts and alternatives that can now be tested and bought quickly, inexpensively, and at a scale as small as an individual or a single team.

Rate of Adoption and Switching

With the removal of gatekeepers who blocked new tools from entering enterprises, and the overall increase in the number of tools in use, comes another huge shift: companies are changing tools more frequently than ever.

In the old days, IBM would close a new customer, then send a team out to install $250,000 worth of hardware on-prem in that company’s office. If that customer wanted to switch, they’d need to gut all this hardware out of their office, pay 6 figures to another company, and go through months of migration. The executive who could make the call to do all of this had little incentive to try something new, even if it had the potential to be better.

So, a signed contract with an enterprise customer meant years—if not decades—of revenue for a vendor.

Today, all it takes is a few people in an organization to abandon WebEx for Zoom in a few clicks.

This ease of switching is obviously a challenge to the incumbent model and is beneficial to the upstarts. But it’s not all gravy for the upstarts, either. Just as easily as that team jumped onto Zoom, they can jump onto the next tool.

To be clear: Lots of companies still use annual contracts and multi-year contracts, and certain types of software (e.g. payroll) are much harder to just test out/switch on a whim. But, that’s just a difference in degree. This is a trend that is impacting every single category of enterprise software.

This increase in liquidity leads to more rapid feedback cycles, so it’s creating a healthier market overall. But when companies can switch providers 5x, or 10x, or 100x easier than before, it changes the entire dynamic.

Number of Tools on the Market

There’s another clear trend as a result of all of these changes: The number of business software products on the market has exploded.

Why has this happened?

  • More businesses have moved more of their operations online and to the cloud, so the overall market is expanding.
  • When it cost tens of millions just to get to market, products needed to cover a relatively wide offering in order to justify big prices and long contracts. Today, you can build a billion dollar business selling into the enterprise at $5 or $7 or $11 per user per month. So, with more companies covering narrow solution spaces, there’s room for more products on the market.
  • The path to the enterprise is shorter and easier than ever, and the capital environment is frothy, so new products are popping up constantly
  • And finally: The market has fragmented massively. Where companies once aimed to buy a single product suite that covers a wide range of tools, we’re seeing more companies build big businesses that cover a narrow business need.

Enterprise Software Is Dead

So what does all of this mean?

Enterprise software is dead. It’s all just software for the workplace now.

Of course, penetrating a Fortune 500 company is still different than penetrating a 75 person startup. But the gap is shrinking, fast.

Products can no longer win by simply convincing decision-makers. They need to deliver a delightful experience to end-users up and down an organization. This is a shift from an addressable customer-base of ~5,000 executives in the Fortune 500 to an addressable customer-base of millions of people throughout these companies.

The market is more liquid than ever. Where vendors once competed on annual cycles, now they compete every single day. Before the ink dries on an annual contract, people within an organization are already eyeing the up-and-coming competition.

And finally, brands matter, in new ways. These vendors once sought brands that represent stability and reliability. Today, they can’t win if they aren’t cool.

Sure, no one ever got fired for buying IBM. But no one ever bragged about their company adopting IBM. When companies adopted Slack, they did.


Click here to tweet this essay (you can edit the tweet before sending). Capiche is on a mission to drive transparency in business software. To see what real companies are actually paying for hundreds of SaaS products, visit

What's the best way to get feedback about a design or product?

Do you have a favorite survey or poll tool to get feedback, or a unique process to get actionable insights from your users about your design, product features, pricing, and more? There was an inte...

What's the best tool for building a customized API documentation?

Let's say you have an API you want to document and you want to: - Let your users test their calls to the API thanks to a "playground" like the one on the Figma API - Be able to customize it to matc...

The community for power users.