Twilio announced the acquisition of Segment in October 2020 for about $3.2 billion in stock and closed it in November 2020, adding a customer-data platform alongside its messaging and voice APIs. Buying a product in an adjacent domain buys that domain's boundary along with its code. What does the acquirer gain, what does it pay, and when does that bill arrive?
Show the full answer Hide the answer
What is gained, quantified
Three things, in order of how quickly they arrive.
- Time. A customer-data platform is years of work: identity resolution, a connector estate in the hundreds, schema governance and a privacy surface. Buying compresses a multi-year roadmap into a closing date, which is why the price of an adjacent-domain acquisition is usually set by time rather than by the cost to rebuild.
- A customer list in the adjacent domain, which is the part a build never gives you.
- A working boundary. The acquired product already decided what a "user", an "identity" and an "event" are, and it ships with those decisions tested against real customers.
What is paid
Two bounded contexts with two definitions of the same noun. A communications API models a recipient as a phone number or an email address with a deliverability history. A customer-data platform models a person as an identity graph that merges device, cookie, email and account across sources. These are not reconcilable by renaming fields, because the identity model differs in cardinality: one person has many addressable endpoints, and one addressable endpoint can belong to several resolved identities over time.
The bill is paid in one of three currencies and you must pick:
| Choose | Gains | Pays |
|---|---|---|
| Leave the boundary intact | No migration risk; both products keep shipping | Two identity models forever; cross-product features need a mapping layer that drifts |
| Merge onto one model | A single customer record; cross-sell features become cheap | A multi-year migration on both sides and a period where neither product's roadmap moves |
| One-way integration behind an adapter | Cross-product features in quarters not years | An anti-corruption layer that nobody owns at budget time and that becomes the constraint |
When the cost becomes visible
Not at closing and not in the first year. It arrives the first time the combined product is sold on a promise that spans both domains, because that promise needs one answer to "who is this person". That is typically 12 to 30 months after the deal, which is after the integration budget has closed and the acquired team's retention packages have vested.
The second visibility point is the privacy surface. A deletion request has to resolve in both models, and a mapping layer built for feature work is usually not built to be authoritative about erasure.
How to keep the option to reverse
- Name the boundary in writing at closing, with one of the three options above chosen, an owner, and a budget line that exists after the integration programme ends.
- Keep the adapter one-directional. Bidirectional sync between two identity models is the state from which no reversal is possible, because neither side is authoritative.
- Instrument the mapping layer's miss rate from day one. A rising share of unmatched identities is the earliest signal that the two models have diverged, and it is invisible unless someone counts it.
When this is the wrong answer
When the adjacent domain is actually the same domain. If the acquired product's core noun is already your noun, merging is the cheap path and preserving two boundaries is pure cost. The test is not organisational: write down the aggregate's identity and its invariants for both products. If they match, merge; if the cardinality differs, do not pretend it does not.