Platforms and Network Effects

A platform's value grows with each participant — design for adoption, not just function.

Each team that adopts a platform adds to its value for every other team, so value grows faster than adoption.

To an executive

A shared platform gets more valuable with each team that joins it. If teams use it because it helps them, not because they are told to, it is working.

To an engineer

Treat an internal platform as a product with self-service tools and support. Measure voluntary adoption, and read any need for a mandate as a sign it falls short.

The idea

Network effects occur when each new user makes a product more valuable for everyone else. Telephone networks, marketplaces and payment schemes all work this way. Platform businesses, unlike traditional pipeline businesses, create value by connecting participants, so scale and adoption matter as much as features.

Internal platforms show the same dynamic on a smaller scale. Each adopting team adds patterns, templates, shared knowledge and pressure to improve. Evan Bottcher describes a good internal platform as a compelling internal product: self-service APIs, tools, knowledge and support that make it easier for teams to use it than to build their own.

Why it works

Value grows faster than adoption. Each new participant benefits from everyone already there, and adds something for those who come next.

Pull beats push. Teams adopt what makes their work easier. A platform that has to be mandated is usually not yet compelling, and mandates hide that signal.

Shared foundations lower cost per team. Security, compliance and operations solved once in the platform need not be solved again by every team.

Where it applies

Internal developer platforms, where adoption decides whether the investment pays off.
Enterprise integration and data platforms, whose value depends on how many systems publish to and consume from them.
Partner and marketplace strategy, where the enterprise wants others to build on its services.
Operating model design, deciding what platform teams own and what product teams own.

How to apply

Treat the platform as a product, with a long-lived team, users, a roadmap and feedback loops.
Start with proven needs, harvesting solutions that teams have already built rather than guessing.
Seed adoption with a few high-value teams, and make their success visible.
Minimise time to first value, through self-service, good defaults and documentation.
Measure adoption and satisfaction, and treat low voluntary uptake as a product problem.

Example scenario

A mandated internal platform had only a handful of adopters after a year. Teams found it slower than their own scripts and worked around it wherever they could.

The platform team rebuilt it as a product: they interviewed teams, harvested the best existing pipelines and made deploying a new service a self-service step that took minutes. Adoption spread team by team without a mandate, and each new team's templates and fixes made the platform more useful for the next.

Questions to ask

Why would a team choose this platform if it were not mandated?
How does each new adopter make the platform more valuable for the others?
How long does it take a new team to get its first real value from it?

When not to use it

A handful of teams with very different needs, where a shared platform adds coordination cost without enough shared value.
Capabilities the market already provides well, where adopting a public platform beats building an internal one.

How it misleads you

Building the platform before validating demand. Many internal platforms are solutions looking for a problem, or existing hosting relabelled as a platform. Network effects also work in reverse: once teams start leaving, the platform loses value for those who stay.