Comparison
Platform as a productvsPlatform engineering
Platform as a product
the platform team runs interviews, publishes a roadmap and measures adoption, because their users can always route around them.
Running an internal platform with product discipline — users, research, documentation, versioning, deprecation policy and voluntary adoption. The argument for it is that mandated platforms accumulate resentment and workarounds, whereas a platform teams choose is one that solved their actual problem. The practical test is whether the team could name their users' three biggest complaints without asking.
Full entry →Platform engineering
a team's output is not a feature but the thing forty other engineers use to ship features safely.
Treating internal infrastructure capability as a product built by a dedicated team for other engineers. It exists because the alternatives both fail at scale: every team solving deployment, secrets and observability separately, or a gatekeeping operations team that becomes a queue. Its characteristic failure is building a platform nobody adopts, which is why adoption rather than completeness is the metric that matters.
Full entry →