Platform Strategy
How I Think
The mental models I return to — on platforms, on AI, on what makes product work last.
The distinction that matters most
Every product decision sits on one side of a line: are you building an application, or are you building a platform? It sounds like a technical question. It isn't. It's a strategic one — and getting it wrong is expensive.
Applications solve a defined problem for a defined user. They can be tight, fast, and useful. From zero to one, the application approach wins. You ship, you learn, you iterate.
Platforms are different. A platform is a foundation that lets othersbuild — internal teams, external developers, partners, eventually AI agents. The goal isn't to solve A problem. It's to create the conditions in which many problems can be solved, faster and at scale.
The scaling curves look completely different. Applications scale by adding people and code. Platforms scale by adding use cases, builders, and leverage. Once the foundation is solid, the platform compounds. The application stalls.
The trap I've seen at every company — Salesforce, Medallia, Seismic, ZoomInfo — is this: teams that believe in platform thinking still fall back into application habits under delivery pressure. Shipping the next feature feels safer than investing in APIs, schemas, metadata, and events. But every shortcut taken below the surface is a tax paid later with interest.
Four principles of a true platform
Over fifteen years building platforms at B2B SaaS companies, I've found that real platforms — not just things called platforms — consistently embody four principles. Miss any one of them and the whole thing wobbles.
Openness — API-first, not API-eventually
Expose services and data through robust, well-documented APIs from day one. If it isn't accessible externally, it isn't truly a platform. API-first flips the order — design for the external consumer first. That constraint forces clarity — clean contracts, consistent schemas, real documentation. The discipline you apply building for customers raises the floor for everything internal too.
Discoverability — metadata as a first-class citizen
Even great services are useless if no one can find or understand them. Metadata — clear definitions, schemas, documentation for every data object, service, and action — is what makes a platform navigable for humans and machines alike. In the agentic era, an AI that can't discover your capabilities is an AI that can't use them.
Interoperability — a canonical data model
You can't enable reuse without shared meaning. A canonical data model is a common language: a standard definition of what a company, a person, an opportunity, an event means across every service that touches it. Without it, every team builds their own siloed version of reality, and integration becomes translation — slow, brittle, and never quite right.
Dynamic adaptability — event-driven, not batch
The era of nightly batch jobs is over. When something changes — data, behavior, system state — every downstream service that cares should know immediately. Event-driven architecture is non-negotiable for real-time intelligence. A common event schema, paired with a global event bus, is what transforms a collection of services into a living system.
Why AI changes the calculus
AI agents are coming — faster than the cloud did, faster than mobile did. And they expose exactly which platforms were built on solid foundations and which ones were just applications wearing a platform badge.
An AI agent needs clean data to reason about. It needs discoverable capabilities to act on. It needs interoperability to move across systems. It needs events to know when the world has changed. Every one of these requirements maps directly to the four platform principles above.
Most vendors are racing to ship agents. Shipping an agent is easy. Making an agent genuinely useful — that's the hard part, and it's almost entirely a platform problem, not an AI problem. Agents don't work well on brittle, one-off systems. They need the foundation we should have been building all along.
The companies that will win the agentic era won't be the ones that shipped the flashiest demo. They'll be the ones that already had the foundation in place.
The organizational dimension
Platform strategy isn't just a technical choice. It's an organizational one.
Building a platform requires investing below the surface — in things that don't show up in a demo, don't get customer applause at a launch, and don't drive next quarter's numbers directly. That's a hard sell inside any organization, especially ones under growth pressure.
The product leader's job is to hold the line on that investment while keeping the business moving. That means being able to articulate the cost of not building the platform — the tax that accumulates every time a team bypasses the foundation and builds directly for the application. Easy to forget. Expensive to ignore.
The best teams I've worked with treat platform investment like infrastructure maintenance: not glamorous, not optional, and deeply connected to everything else they want to build.