Platform as a Product

The most common kind of Internal Product Team in a software organisation is a Platform Team: the team that owns CI/CD, environments, observability, the data substrate, or any other capability that multiple Stream Teams depend on. Platform Teams that succeed treat their platform as a product. Platform Teams that fail treat it as infrastructure that other teams must use.

Goal

To run platforms as products with real customers, real success metrics, and real consequences for failing to serve those customers, without falling into the failure mode where the platform becomes a mandated dependency that nobody wants to use.

The four characteristics of a good platform

1. Voluntary adoption is the success metric

A platform succeeds when Stream Teams choose to use it. If teams are routing around the platform by building their own auth, their own notifications, their own deployment scripts, that is the most important signal a Platform Team can have. It means the platform is too rigid, too slow, too narrow, or too painful for the use case in question.

The temptation when adoption is low is to mandate it. "All teams must use the platform for X." This makes the adoption number go up and hides the underlying problem. Six months later the Platform Team is still being routed around, just less visibly. A year later the platform is full of half-used features that don't fit anyone's actual workflow.

The hard discipline is to treat low adoption as the team's most important problem to solve, not as a compliance issue for the Stream Teams.

2. Small core, plus extensions

Platforms work best when the core covers the genuinely common case and explicitly allows extensions for cases the core does not handle. The pattern: a small core that everyone uses, with clean extension points for the unusual situations.

The opposite pattern, a large core that tries to handle every possible use case, produces a platform that is too complex for the common case and still doesn't handle the edge cases well. The Platform Team spends most of its time managing the core's complexity rather than improving it.

A practical heuristic: the Platform Team should be able to explain the core in five minutes. If it takes longer, the core is too big.

3. The rule of three

Don't pull something into the platform the first time two teams need it. Wait until a third team has the same need before deciding it belongs in shared infrastructure.

The reason is that the first two cases rarely tell you the right shape of the abstraction. Each team built theirs to fit their specific need. The shared shape becomes obvious only when you can see three independent implementations and ask what is actually common across all three. Productising too early bakes in the shape of one team's needs and forces the others to live with it.

4. Separate Core Platform from Data Platform

Two of the most common platforms in a tech organisation, Core Platform and Data Platform, serve different consumers, change at different cadences, and need different specialisms.

Core Platform owns the substrate that every Stream Team needs to run software: CI/CD, environments, deployment, observability, common services. Its consumers are developers; its cadence is continuous; its specialism is platform engineering.
Data Platform owns the cross-stream data infrastructure: event streaming for Stream Teams to publish their domain events, the downstream analytics warehouse Stream Teams populate from those events, ML platform substrate (feature stores, training and serving infrastructure), data quality tooling, and database hosting as a paved-road service. Its consumers are Stream Teams (publishing events, using the database service) and analysts (consuming the warehouse). Its specialism is data engineering. Crucially, each Stream Team still owns its own operational data store inside its bounded context. The Data Platform team owns the substrate for cross-stream analytics and ML, not the source-of-truth data.

Combining them produces a team that is both too broad and chronically overloaded, with neither half getting the focus it needs.

How Platform Teams succeed

A few practices that distinguish Platform Teams that work from those that don't:

They have Product Managers. Platform Teams need someone who understands their users (Stream Teams) and can prioritise. Engineering-only Platform Teams usually build features the Platform Team thinks are interesting, not the ones the Stream Teams actually need.
They run the same kind of continuous research as Stream Teams do. The team interviews developers, watches them work, runs prototypes past them. The Stream Team is the customer; treat them like one.
They publish quality metrics. SLOs for platform availability and performance. Time-to-onboard for new users. Voluntary adoption rate. The Platform Team holds itself accountable to numbers, the same way it expects Stream Teams to.
They invest in onboarding and migration. The platform's adoption depends on how easy it is for Stream Teams to start using it. Time spent on better docs, examples, and migration scripts pays off proportionally more than time spent on new features.

Anti-patterns

Platform-as-mandate. "All teams must use this." The team that mandates the platform also accumulates the resentment when it doesn't fit.
Platform-as-prison. The platform is technically usable by Stream Teams but every change requires going through the Platform Team. Effective lead time goes up rather than down.
Big core, no extension points. The platform tries to handle every case. Most cases are handled badly.
No Product Manager. The team builds what it finds interesting. Stream Teams build their own thing on the side.
Combined Core + Data Platform. Neither half gets the attention it needs. Both halves underperform.