Platform as a product debate

A lot of internal developer platforms started as junk drawers. One team added a deployment tool. Another added a secrets tool. A third added a service catalog. After two or three years, developers were clicking through five interfaces to ship one change, and nobody could explain which path was the “right” one anymore. That is the mess platform engineers have been arguing about in recent DevOpsCon discussions: stop treating the platform like a pile of tools and start treating it like a product. (devopscon.io) That shift sounds cosmetic, but it changes who the platform is for. A product has users, and in this case the users are internal software developers. A platform team working like a product team has to study what those developers actually do, where they get stuck, and which steps should become self-service instead of support tickets. The New Stack’s reporting on platform engineering panels framed it bluntly: your colleagues are your customers, and the platform has to be something they want to use rather than something they are forced to work around. (thenewstack.io) This is the backdrop to the current “platform as a product” debate. DevOpsCon’s 2026 Platform Engineering Summit describes platform engineering as the foundation of modern developer experience, with self-service adoption, governance, automation, and lower cognitive load all bundled into the platform itself. In other words, the platform is no longer just the plumbing under software delivery; it is the interface that decides whether a developer’s day feels fast and predictable or slow and confusing. (devopscon.io) The phrase “cognitive load” shows up again and again because it names the real tax teams are trying to remove. Every extra deployment rule, account boundary, approval path, and infrastructure option forces developers to carry more system knowledge in their heads. Atlassian’s definition of an internal developer platform centers on abstracting that complexity behind a self-service layer, so developers can build and deploy software without manually stitching together pipelines, configurations, and environments each time. (atlassian.com) That is why platform teams are moving away from tool sprawl. Tool sprawl is not just “too many vendors.” It is the condition where each tool brings its own workflow, permissions model, terminology, and failure mode, leaving developers to translate between them. Platform engineering guidance from Microsoft and AWS both push the same remedy: create a coherent platform experience that improves developer productivity while still maintaining security, compliance, and cost control. (learn.microsoft.com) (docs.aws.amazon.com) That coherence is where governance enters the story. In older setups, governance often meant a gate at the end: a review board, a manual approval, or a blocked release. In the newer platform view, governance is built into the path itself through policy automation, reusable templates, and pre-approved workflows. DevOpsCon’s summit language reflects that shift by pairing platform strategy with governance automation, policy-as-code, secrets management, and measurable developer-experience outcomes. (devopscon.io) The same conversation is now expanding beyond human users to machine users. As coding assistants and automated agents become part of software delivery, a platform has to serve not just people reading dashboards but systems reading structured context. That is where the recent emphasis on machine-readable context comes from. HubSpot’s documentation team described this change directly in 2025: newer developer workflows increasingly depend on coding agents and integrated development environments that expect structured, machine-readable answers rather than long, prose-heavy documentation pages. (developers.hubspot.com) That helps explain why docs-first application programming interface design keeps surfacing in platform circles. Docs-first design flips the usual order. Instead of building an interface and documenting it later, teams write the contract first: what the service does, what inputs it accepts, what outputs it returns, and what rules surround it. Microsoft’s web application programming interface guidance says clear documentation is part of platform independence and loose coupling, because clients should be able to use the interface without knowing the internal implementation. (learn.microsoft.com) In 2026, that same contract is doing double duty. It still helps humans understand a service, but it also gives agents a structured artifact they can parse. Andreessen Horowitz argued in its analysis of the Model Context Protocol that documentation is becoming a core part of machine-facing infrastructure, with companies needing clear, machine-readable formats and protocol servers built from existing docs. Anthropic makes a related point from the agent side: context engineering is about curating the information systems need at inference time, not just writing a better prompt. (a16z.com) (anthropic.com) That is also why platform practitioners are warning against “Franken-platforms.” DevOpsCon’s recent write-up of Russell Miles’s keynote uses that term for platforms that have grown into contradictory systems with unclear dependencies and overlapping processes. The image is useful because it captures a common failure mode: a platform assembled from many good parts that no longer forms a usable whole. (devopscon.io) The proposed fix is not “buy one giant product.” It is to design a reference architecture and a small number of golden paths that fit the organization’s actual workflows. PlatformEngineering.org argues that reference architectures matter because successful internal developer platforms are assembled from tested patterns rather than improvised one-off combinations. AWS makes a similar case in more operational terms, recommending clear architectural boundaries such as shared services accounts and standardized access patterns. (platformengineering.org) (docs.aws.amazon.com) That leaves the platform team with a job that looks less like central operations and more like product management. They need a roadmap, user research, adoption metrics, support channels, and a clear statement of which workflows the platform owns. DevOpsCon now explicitly frames platform return on investment in terms of developer-experience metrics, adoption data, and feedback loops, which is product language applied to internal infrastructure. (devopscon.io) The reason this debate is gaining force now is that the old compromise has stopped holding. When software teams shipped only for humans, messy internal systems could limp along on tribal knowledge and heroics. Once companies want fast self-service, stronger governance, and machine-readable context for agents, the platform has to become simpler on the surface and stricter underneath. The current message from DevOpsCon and platform practitioners is that the internal platform cannot just be a collection of tools anymore; it has to be designed, documented, and governed like a product people and machines can both reliably use. (devopscon.io) (thenewstack.io)