All posts

2 min read product · m&a · integration

Four acquisitions later: a product manager's guide to M&A integration

I led the discovery-to-delivery integration of four acquired businesses into Toptal's platform and operations. M&A integration is a product problem wearing a corporate costume.

Acquisitions are announced as strategy and delivered as integration. Between 2023 and 2024, as Lead Product Manager at Toptal, I led the discovery-to-delivery integration of four acquired businesses into the platform and operations. Most of what I believed about M&A before doing it was wrong, so here’s the version I’d hand my past self.

Integration is a product problem

The corporate framing of M&A — synergies, migrations, alignment — hides the actual work. An acquired business is a live product with users, revenue, tech debt, and a team that’s nervous about all three. Integrating it is product management:

  • Discovery first. Before any migration plan, you need the unglamorous inventory: what does this product actually do, for whom, and which parts drive the revenue you just paid for? Every acquisition we integrated had at least one load-bearing feature nobody mentioned in diligence.
  • A backlog, not a project plan. Integrations run for quarters and the ground shifts constantly. We ran each one as a prioritised backlog with a clear definition of done per stream — technical migration, operations, data, people — instead of a single grand Gantt chart that dies on contact.
  • Users don’t care about your org chart. The customers of the acquired product measure you by one thing: did the product get better or worse after the logo changed? Every integration decision eventually cashes out there.

The sequencing rule that saved us

When everything is urgent, sequence by irreversibility. Things that are hard to undo — domain migrations, data model mergers, account unification — get planned slowly and executed once. Things that are easy to undo — internal tooling, reporting, team rituals — get moved fast and adjusted live. Teams burn out when they treat everything with single-shot caution, and they cause incidents when they treat irreversible moves casually.

Keep one person accountable for the seams

Merged systems fail at the seams: the webhook nobody owns, the billing edge case between two subscription models, the analytics that silently double-count. Our fix was structural — every seam had exactly one named owner. Not a committee, not “both teams.” One person who could say yes, no, or not yet.

Why this experience compounds

Integration work is the fastest education I’ve had in how software businesses actually hang together — product, data, operations, and people, all coupled. It’s also where I first coordinated AI infrastructure at scale, which planted the seed for how I build products now.

If an acquisition lands on your desk: congratulations, you’re now the PM of a product you didn’t build, for users you didn’t choose, on a deadline someone else announced. Treat it as product work and you’ll be fine.

Get the next essay

Product, growth, and AI-assisted engineering — straight to your inbox, once in a while. No spam, unsubscribe anytime.