Platformization at Segment

Turning a product suite into extensible infrastructure

The situation

When I joined Segment, the product had grown fast. Multiple teams were shipping features, but they were rebuilding the same underlying primitives—ingestion pipelines, identity resolution, event processing—in slightly different ways.

I used an analogy internally to explain the problem: The supply closet is a mess. Only the executive admin knows how to get stuff, where stuff lives. We want team members to go in and grab whatever they need. But we need to organize the room itself before worrying about what specific things people want to do with the items.

Applications teams were integrating directly with the Compute Platform, each reimplementing segmentation and sync logic. This caused slowdowns and inconsistencies that customers experienced as unpredictable behavior across products.

The company had scaled from startup to growth-stage, but the architecture still reflected the "move fast, ship features" phase. That approach had been right for its moment. It wasn't right anymore.

The insight

The core problem wasn't technical debt in the usual sense. It was a missing abstraction.

But the insight wasn't just "we need APIs." It was that we were conflating the computation with the use case. Segmentation—the act of defining and computing a group of users—was tangled up with Audiences, which was one specific application of that computation.

Segmentation needed to exist as its own primitive. A building block that Audiences, Journeys, Computed Traits, and future products could all consume.

This reframe changed the conversation from coordination (getting people to behave differently) to architecture (giving them something better to build on). It also changed the debate from "who owns what" to "what's the right abstraction."

The principle I took from this: When you see the same problem solved three times in three places, you're not looking at an execution failure. You're looking at a missing platform.

What I did

Defined the platform boundary. Not everything should be a platform. The risk of premature abstraction is real. I mapped which capabilities were genuinely shared—Compute (segmentation + augmentation), Sync (destination management)—versus which were product-specific applications that should stay owned by feature teams.

Drove the conceptual alignment. In one pivotal meeting, the team was stuck debating "audiences API vs segmentation API." I proposed we stop that debate entirely and instead treat segmentation as its own primitive that audiences would consume. That reframe—computation separate from use case—shifted the conversation. We left aligned on a phased approach we could all execute.

Built the case for investment. The real alternative wasn't "platform vs. no platform." It was "absorb the slowdown now to build shared infrastructure, or defer it and pay a higher refactor tax later." I recommended absorbing it now.

The resistance was rational. Platform work meant roadmap slowdown in the short term. Teams would lose some ownership. I had to make the case that this wasn't about org charts—it was about leverage. Build once, benefit everywhere.

Shipped in phases, not all at once. Rather than build a full Audiences API upfront, we started with segmentation API alone. Teams could create segments programmatically, see them appear as audiences in the UI, and prove value before we added sync capabilities. This let us ship faster and build adoption before investing in the full abstraction.

Created three platform teams. Restructured the organization to separate platform concerns (Compute, Orchestration, Observability) from product concerns. Each platform team owned a clear surface area with explicit contracts to the rest of the org.

The results

The impact showed up as absence of friction rather than dramatic wins.

Previously, launching a new campaign type meant rebuilding segmentation logic from scratch. Afterward, new products like Predictive Traits could consume the segmentation primitive directly, cutting development time significantly.

Enterprise customers experienced faster deployments. Adding a new integration started to feel like configuration rather than implementation. Support tickets about "why doesn't X work with Y" dropped.

Internally, teams stopped rebuilding the same primitives. The platform teams didn't become bottlenecks—they became accelerants. Feature teams shipped faster because they could rely on infrastructure that actually worked.

The numbers: 400+ integrations running on the unified platform. Enterprise deployment time down 20%. Platform work contributed to $50M+ in ARR growth.

What I learned

Platform wins are felt as absence. You don't get a "wow" moment. You get fewer escalations, faster onboarding, quieter launches. The success metric is problems that stop happening.

Adoption is a product problem. If teams don't use your platform, it doesn't matter how well-architected it is. Treat internal developers as customers. Make the right path the easy path.

Boundaries matter more than mandates. You can't coordinate your way to platform consistency. You have to draw boundaries that make the right behavior natural.

Local optimization kills global scale. Teams optimizing for their own velocity will always outpace central coordination - unless you give them infrastructure that's genuinely better than what they'd build themselves.

See all work · Read about Teams · Read about Snapchat · Email me