Photo by Carlos Muza on Unsplash

Salesforce spent $28 billion acquiring Slack in 2021. Today, Microsoft Teams—a feature bundled into Microsoft 365—dominates the workplace communication space. This wasn't supposed to happen. Slack had valuation magic, a devoted user base, and enough engineering talent to challenge the status quo. Yet within three years of being absorbed into a massive enterprise conglomerate, it became another module in Salesforce's bloated ecosystem.

This pattern repeats across software. Oracle bought NetSuite for $9.3 billion, only to watch Shopify eat their lunch in e-commerce platforms. Adobe acquired Figma's competitor Typekit, but Figma—started by two brothers in 2012—became the design standard for teams everywhere. These aren't stories about bad acquisitions. They're stories about what happens when organizational size becomes a liability instead of an advantage.

The Feature Trap: When Complexity Becomes Currency

Enterprise software companies operate on a fundamental assumption: more features equal more value. A Salesforce customer might use 15% of available features, but the company charges for access to all of them. This model made sense when software was sold through salespeople, implemented by consultants, and measured by total cost of ownership.

But something shifted. Slack proved that users would prefer a tool with 20% of the features if those features were flawlessly executed. Figma demonstrated that web-based collaboration beats installed software with twice the capabilities. Notion showed that flexibility beats specialization for knowledge workers tired of learning seven different applications.

The problem runs deeper than user preference. When your revenue depends on enterprise contracts worth $500,000+ annually, every feature request from a major account gets prioritized. Your product roadmap becomes a democracy where the largest customers have the loudest votes. You end up building for the needs of 3% of your user base while alienating the other 97%.

A mid-market SaaS founder I spoke with recently described it perfectly: "We removed a feature nobody used. It was in the product for seven years. The one enterprise customer who had requested it in 2016 threatened to leave. We spent two engineers for six months supporting a feature used by 0.03% of our revenue-generating base."

The Speed Problem: Democracy at Scale

Here's what most people don't understand about large organizations: they're actually slow. Not because individuals are lazy. But because coordinating across teams, getting legal sign-off, managing security reviews, and achieving consensus takes time. A lot of time.

Basecamp famously limits projects to six-week cycles. Netflix pairs big ambitious goals with small team sizes. These aren't management theories—they're direct responses to the physics of how human teams actually work. When you have 5,000 engineers coordinating on a single product, a small decision requires dozens of meetings.

A startup with 30 engineers can ship a major feature in two weeks. By the time a 500-person enterprise software company schedules the kickoff meeting for that same feature, the startup has already shipped it, collected user feedback, and released version two.

Figma shipped collaborative cursors (showing what each team member is doing in real-time) in 2017. Adobe Photoshop got real-time collaboration features in 2021. That four-year gap wasn't about engineering capability. Adobe has 20,000 employees and more resources than Figma could dream of. The gap existed because large organizations can't move like small ones.

The Customer Expectation Paradox

Enterprise software companies face a strange bind: their biggest customers expect the product to do everything, so they build everything. Then new customers arrive, look at the 47-tab interface, and buy something simpler instead.

Stripe understood this. When they entered payment processing, the market was dominated by 20-year-old incumbents with bloated admin panels and Byzantine APIs. Stripe's CEO Patrick Collison made a deliberate choice to build for developers first, enterprise features second. The result? A $95 billion company that made legacy payment processors look like they were built in the 1990s (they were, but it looked worse after Stripe existed).

The sales model matters here too. When your sales team closes $2 million annual contracts, they're incentivized to promise custom features, integrations, and capabilities. The engineering team then builds those features, even if 20 other customers are asking for something completely different. You optimize for customer retention at the cost of product clarity.

A startup has the opposite problem—and advantage. They have to say "no" constantly. No custom features. No special integrations. No hand-holding. This discipline forces them to build something so good that customers use it exactly as designed, without demanding changes.

The Talent Problem Nobody Discusses

Working at a startup is exciting because you can see the impact of your work immediately. A bug you fix at 4pm might affect 50,000 users by 6pm. You ship code and watch adoption curves change in real time.

Working at a massive software company is different. You might spend six months building a feature that gets rolled out to 0.4% of customers as part of a larger release. The impact is diffused. The feedback loop stretches from months to quarters. Good engineers leave because they want to feel like they're building something, not maintaining infrastructure.

Meanwhile, startups attract engineers who are willing to work for equity and chaos because they want to build something real. That's not a morale issue—it's a structural advantage. The best software gets built by people who feel the weight of their decisions.

The Path Forward for Big Companies

Some enterprise software companies have figured this out. The Revenge of the Middle Manager: Why Companies Are Suddenly Hiring Again After Years of Cuts documents how some organizations are regaining agility by restructuring how teams operate and make decisions.

The winners will likely be companies that can do something counterintuitive: shrink their focus. Microsoft did this with GitHub, largely leaving it alone. They could have integrated GitHub into Visual Studio for Office 365 Enterprise customers. Instead, they let it stay lean and focused. That restraint created the $21 billion acquisition that actually justified the price tag, years later.

The $47 billion question isn't about which software company will win the next wave of consolidation. It's whether the biggest companies can resist the gravitational pull toward complexity long enough to realize that simplicity is the last remaining competitive advantage in software.