- Capital Gains
- Build, Buy, or Borrow
Build, Buy, or Borrow
The Economics of Companies Acquiring What They Could Make In-House
Adobe's deal to acquire Figma was recently scotched over antitrust concerns. The deal and its eventual falling apart raises many questions, but among these, one question stands out: why do companies buy competitors in the first place, instead of building substitute products? This question is worth asking because, in many cases, they do build the substitute product, sometimes in parallel with the acquisition: Google launched Google Video in 2005, and then bought YouTube in 2006.1 Google didn't have to do that; for example, when they were worried about Twitter, they didn't respond by buying it, or by building a short-form that directly cloned Twitter's features; they licensed tweets and displayed them inline in search instead.
Companies constantly face the question of what to outsource, what to insource, and what to acquire. This is implemented as a corporate development question, but a lot of the reasoning comes down to product.
The first consideration is how mature the challenged product is when a new threat emerges. Figma is a big problem for some parts of the Adobe suite, but not for others, and it fits a use case somewhat different from Adobe's own: Adobe wants their product to be used by a design professional who spends much of their day thinking about how things should look and what the optimal way to display some information is. It's hard to build a full-featured product that's also useful for someone who has built some useful service and later decided that they want to ditch their painfully old-school user experience, but also doesn't want to just borrow some template (because then their service look like every other just-barely-launched product). This challenge made a lightweight, collaborative-by-default product that could be used by marketers and engineers (rather than just designers) an effective new entrant, and once it got early adopters, it could follow the same path that many others do: solve one problem well, then grow your overall suite of offerings at a pace that keeps up with your fastest-growing customer, and you'll end up building a comprehensive solution to an entire category of problems, organically.
Unable to squeeze everything into a single product, Adobe actually built a competing product, Adobe XD. It's a distant #2 to Figma, though, and earlier this year, when the acquisition looked more certain, Adobe stopped allowing new customer signups. (This may be one reason Figma grew 40% in the last year ($, The Information): part of the breakup fee for the merger was paid in advance through Adobe's preemptive integration of Figma into their existing lineup!)
Oddly enough, XD was actually an older product than Figma, having been announced in 2015 and launched in beta in early 2016; Figma came out a few months later. But Adobe was still reacting to a competitive threat, just a different one: Sketch. Adobe's original reasoning was the obvious: they have more engineering resources, a more recognizable brand name, and existing customer relationships. If they can match another product feature-for-feature, the Adobe version will sell better.
That model has worked in a few different areas, with Teams' share gains against Slack as the most recent example. But it relies on a big if: Sketch and Figma were betting their entire business on a single tool, at least at first, while Adobe's superior distribution meant that they could cannibalize themselves faster than a competitor.
An incumbent has a dangerous kind of information advantage: if they know where to look, they'll see cracks in their model before the challenger knows what's going on. Every big contract renewal is an opportunity for customers to consider their options, and the relative value of those options informs their own negotiating posture.2 So when a challenger product starts really working well, and is a few quarters away from winning some big deals, the owner of whatever product is being challenged will know it’s coming.
But some acquisitions are less about one company buying its biggest competitor, and more about a company buying a small competitor in order to accelerate its attack on a bigger one. This happened in office suites: in the 80s, Microsoft realized they needed presentation software, so they bought PowerPoint, which had been launched by an independent company (and which made a lot more sense when sold alongside Word, Excel, and later Outlook). When Google was going after that exact office suite with browser-based products, they bought Writely for its document editor and Zenter and Tonic Systems for slides.3
In deals like this, the key calculation is not just whether a competing product can be launched, but when. Google recognized something in office software that was close to what Figma saw in design tools: there was an opportunity to build a browser-based tool that was multi-user by default, and the faster that tool launched the harder it would be to replicate. This was a particularly enticing opportunity because Microsoft still had a network effect from file formats, but Google could offer a superset of these features in its own tool. Offering Excel outputs but better-than-Excel inputs is basically a way to steal the value of a standard out from under the company that created it (and standards, in this case, are very much a race).
There is one last category of company interactions worth thinking about: some companies achieve M&A-like synergies by cooperating rather than buying and selling. This fits many of the strategic arguments for an acquisition: it's a way to neuter a competitor (making them a complement rather than a competitor means sharing distribution, but it also means tying that distribution to offering something distinct from the core product). This happens a lot when the products don't have a distinct user interface: payments, for example, tends to be a complex supply chain where networks, balance sheets, checkout pages, and fraud detection are handled by an ever-changing mix of companies. It's also common in the layers of cloud computing that are closer to the infrastructure than to the end user. It's rare when the product has a user interface, though not impossible: Google has cultivated an ecosystem of integrations for its products (Chrome plugins, tools that use Sheets as a backend, Gmail-first email clients like Superhuman, etc). Microsoft software is also the substrate for countless other products, from niche automations in Excel to most of the PC gaming industry.
Cooperation is a default, but it doesn't always work. Ironically, strategic acquisitions end up being a way to resolve uncertainty: if two companies work together, it's often unclear upfront which of them is deriving the biggest advantage. When a big tech company gets a key feature by partnering with a small startup that happened to build it first, are they keeping that startup alive long enough to ship their own version of the feature? Or are they accidentally creating the company that will render them irrelevant? Sometimes it's hard to tell, and it's generally hard to structure a deal around hedging this possibility. In cases like that, the easiest choice can be buying the company outright.
Read More in The Diff
Acquisitions and the build/buy/partner question are a running theme in Diff pieces on corporate strategy, including:
1. YouTube remains the top user-generated video site, and also fits Google Videos' niche as the best video search product.
2. That's not a complete advantage, though. What they don't see is the customers who never even consider them, and who merrily grow alongside the challenger product. This often happens when the new product is cheaper and simpler than what it's replacing: by the time prospective customers actually look like customers, they're already locked in to some other product.
3. It might be optimistic to speculate that both companies had to acquire their slide deck product because both recognized that memos are superior to presentations for conveying complex information. There are some Google powerpoints floating around, albeit mostly about the business side rather than technical issues. But the documentation Microsoft produces in lawsuits skews to lengthy emails instead.
Share Capital Gains
Subscribed readers can participate in our referral program! If you're not already subscribed, click the button below and we'll email you your link; if you are already subscribed, you can find your referral link in the email version of this edition.