← Writing
May 14, 2026·6 min read

Product Teardown: How Figma Killed a $20 Billion Adobe Acquisition

Figma didn't win by being better design software. It won by changing who design software was for. A breakdown of the product decisions that made Adobe pay $20B to stop them.

In 2022, Adobe announced it would acquire Figma for $20 billion. The deal was eventually blocked by regulators, but the fact that Adobe felt compelled to make the offer at all is the real story. Figma had grown to the point where Adobe — the company that had owned design tooling for thirty years — saw no path to competing with it.

This is a breakdown of how Figma got there, and what product builders can take from it.

The market Figma entered

Adobe Illustrator and Sketch were the dominant tools for UI/UX design when Figma launched in 2016. Both were desktop applications. Both were file-based: you worked on a local file, saved it, version-controlled it manually, and shared it by sending the file around. Collaboration meant emailing PSDs, syncing through Dropbox, or waiting for someone to close the file so you could open it.

The design workflow was, by the standards of modern software, absurd. An entire team of designers working on the same product would be in different files, at different stages, with no reliable way to know which version was current.

Figma's founding insight was that design collaboration was the same problem that Google had already solved for documents — and the solution was the same. Put everything in the browser. Make it real-time. Kill the file.

Browser-first as a distribution strategy

The decision to build Figma in the browser was not just a technical choice. It was a distribution strategy.

Desktop apps have a procurement problem. Someone has to download them, IT has to approve them, licenses have to be purchased. Browser-based tools don't have that friction: you click a link, you're in the tool. The zero-install path collapsed the gap between "I want to try this" and "I'm using this."

This mattered especially for Figma because design tools are inherently collaborative. Designers share work with developers, with product managers, with stakeholders, with clients. When sharing a Figma file means sending a URL that anyone can open in a browser — no account required to view, no software required to comment — the reach of the tool multiplies with every share. Non-designers started using Figma without intending to. They opened a link to leave a comment and found themselves inside a tool that was actually navigable.

That passive adoption of non-designers was the flywheel. Developers who lived in Figma files started requesting Figma. PMs who gave feedback in Figma started buying Figma for their own teams. The tool grew laterally, outside of the design org, in ways that Sketch — which required a Mac and a license — never could.

What Figma actually understood about design work

The product decisions that made Figma work go deeper than browser delivery.

Figma's component system — the ability to define a button once and have every instance of it across every file stay in sync — solved a problem that every design team has and nobody was addressing well. Sketch had symbols. InVision had overlays. Neither made the design-to-implementation handoff clean. Figma made it cleaner by treating the design file as a source of truth that developers could inspect directly: hover over any element, see the exact CSS values, copy them out.

The inspect panel was a quiet product insight. Design tools had always been for designers. Figma noticed that the output of design work was consumed by developers, and it built for the consumer, not just the producer. Developers who could get values directly from Figma stopped needing to redline documents. The back-and-forth compression that created shortened review cycles.

The multiplayer as a product value, not a feature

Every company that builds real-time collaboration treats it as a feature. Figma treated it as the product.

The difference is visible in how Figma communicated about itself. It didn't say "Sketch, but with collaboration." It said design should be collaborative from the start, not collaborative as an afterthought. The multiplayer cursor — seeing where your teammate is, what they're working on, in real time — is not a productivity feature. It's a signal about how the product thinks about design work. Design is not a solo activity that sometimes requires handoffs. It's an ongoing conversation between designers, developers, and everyone else who has an opinion about what gets built.

That framing attracted a generation of designers who were tired of the isolation of the old workflow. And it attracted companies who wanted their design process to look more like their engineering process — version control, shared sources of truth, real-time review.

Why Adobe had to buy it

Adobe's problem is the same problem any incumbent faces when a better-designed competitor appears in its market: by the time the threat is obvious, the cost of competing is prohibitive.

Adobe could have built a browser-based collaborative design tool. It has the engineering resources. What it couldn't do was ship something competitive without it being built around a different set of assumptions than the ones that had made Adobe successful. Adobe's products are built around files, around the desktop, around the professional individual creator. Figma was built around collaboration, the browser, and the team.

You can't graft those assumptions onto each other. Adobe tried with XD. It didn't work.

So they offered $20 billion to acquire the problem. Regulators blocked it, which means Adobe still has to figure out how to compete with Figma. That's a harder problem now than it would have been in 2016.

The product lesson

Figma's trajectory runs on a principle worth naming explicitly: collaborative workflows beat feature parity, every time, in any market where the output of the tool is consumed by more than one person.

If someone else has to open the file, review the design, implement the spec, or approve the decision — then collaboration is not a nice-to-have. It's the core product requirement. And if your tool treats it as a feature rather than a foundation, a Figma-style competitor will eventually come along and take your market.

The question to ask when building in any category: who else touches the output of this tool? Build for them too.