Why do acquired products die inside big companies?

THE SHORT ANSWER

They die in a predictable three-step pattern I watched run three times inside Salesforce. First the team loses its constraint, the scarcity of money, people, and time that forced sharp decisions. Then it inherits the parent's process, the reviews and planning cycles and approval chains built for a giant org. Then it stops shipping, because the velocity and focus that made it worth buying have been engineered out. The cause of death is almost always the same: the parent removed the forcing function and added friction in its place.

I have been inside three acquisitions at Salesforce. Different teams, different decades, different products, across the Marketing Cloud, Quip, and Slack-era waves. The autopsy reads the same every time. If you have ever watched a sharp acquired team go quiet a year and a half after the deal closed and wondered what happened, here is the pattern. It is more predictable than anyone in corp dev wants to admit.

First the constraint disappears

A startup is fast for reasons people misremember. We tell ourselves it is the talent, the passion, the mission. The real engine is the constraint. A startup has too little money, too few people, not enough time, and that scarcity forces brutal prioritization. You cannot build the wrong thing for six months because you will be dead in four.

Then the deal closes and the parent removes the constraint. Suddenly there is budget, bodies, effectively infinite runway. It feels like a gift. It is the first cut. Without the constraint, the ruthless prioritization that made the team fast has no reason to exist. Nobody decides to slow down. The forcing function just quietly switches off.

Then the process moves in

Now the team inherits the parent's operating system. Reviews, planning cycles, security and legal and brand gates, cross-functional alignment, a quarterly cadence built to coordinate thousands of people. Each piece is defensible on its own. But the aggregate is a system designed for a ten-thousand-person org, and you just dropped a forty-person team into it. The team that used to decide and ship in a week now waits three weeks for alignment, two for review, a whole planning cycle to even get on the roadmap.

The loop that made them fast ran in days. The parent's process stretches it to quarters. Same people, same talent, a loop that is now ten times longer. And output is a function of loop length.

By the time it stops shipping, the third step is automatic. What confuses leadership is that everything looks fine. The team is staffed, the people are still good, they are busy, in meetings, producing documents, sitting in reviews. High activity, low output. That is the signature of a team that has lost its loop. Nothing happened to the team. Something happened to the system it lived in. Velocity was never a property of the people alone. It was people plus a short loop plus a hard constraint plus the authority to decide, and integration broke all three.

The acquirers who avoid this treat velocity as the asset they paid for. They keep the team small enough that it still has to make hard tradeoffs, give it a clear outcome to own, and assign a senior sponsor whose actual job is to stand between the forty-person team and the ten-thousand-person operating system and take the process tax personally. The parent's instinct is to integrate, standardize, support. The right move is usually to isolate, protect, constrain. The resources were never the asset. The loop was.

AI-native acquisitions will fail the same way, only sharper. When build capacity stops being the bottleneck, approval latency becomes the bottleneck. A team that can go from customer outcome to shipped prototype in a day is fast because nothing sits between the decision and the build. Drop it into a heavyweight review process and the AI advantage is gone, because you just reintroduced the one bottleneck AI removed.

So if you are about to acquire a team, name its loop before you touch anything else. For every piece of parent process you apply, ask one question. Does this lengthen the loop? Defend the loop like it is the asset. It is.

SOURCES

THE LONG VERSION

RELATED ANSWERS

Last reviewed 2026-07-31 · 4 min read