Ninety percent. That's the number Google Cloud reports for organizations planning to expand the reach of their internal developer platforms (IDPs). It isn't enthusiasm — it's a measurement: teams are doubling down on platforms, and the report's punchline is blunt: the winners treat the platform as a product and measure it by DORA-style outcomes, not by a laundry list of supported tools.
This is overdue. Platform engineering matured years ago in practice but lagged in discipline. The report crystallizes what the community has been experimenting with: product management for platforms (roadmaps, prioritization, SLAs), an outcomes-first success model (deployment frequency, lead time for changes, change-failure rate, time to restore service), and a design contract: opinionated golden paths that reduce cognitive load.
Three implications matter for senior platform engineers.
First, telemetry and SLAs must align to developer-facing outcomes, not infrastructure uptime alone. If your platform team still reports "number of integrations added" as success, you're building a catalogue, not a platform. Move dashboards toward metrics that correlate with developer velocity and reliability: deployment frequency for teams using the golden path, lead time for changes on self-service flows, and change-failure rate for platform-backed deploys.
Second, golden paths are not a rigidity exercise — they're your product's onboarding funnel. Start with a minimum viable platform (MVP) that removes the highest-friction journeys and iterate. The dangerous opposite is the "golden cage": dogmatic opinionation that forces teams into workflows they resent. Favor opinionated defaults with frictionless escape hatches and clear telemetry to detect when people bypass the path; that is how voluntary adoption becomes measurable ROI.
Third, ticket hell is a product failure. Community posts — many echoing Google Cloud — focus on replacing high-cost ticket-based ops with self-service pipelines surfaced through platform portals, automated audit trails, and explicit UX for failure modes. If your platform isn't converting the top manual support requests into pipelines and surfacing those as discoverable actions in the portal, you're running a cost center disguised as an engineering initiative.
Backstage's plugin-first evolution matters here. Smaller, focused plugins let teams iterate on golden paths incrementally instead of shipping a monolithic platform UI. Work on catalog and permission subsystems has made plugin boundaries more practical, supporting incremental product iterations and scoped SLAs.
A practical side-effect: platform leadership is now a career path. The report highlights platform product managers, platform engineers, and platform reliability roles as distinct specializations. That means different hiring profiles: you want people who can own roadmap trade-offs, measure developer outcomes, and write an SLO for developer experience the way SREs write service SLOs.
Final take: treat this like a market signal, not vendor cheerleading. The industry is moving from tool-centered automation to product-centered platforms. Teams that keep optimizing for "more integrations" or purely technical metrics (CPU, uptime) will find themselves irrelevant to their consumers — application teams. Platform teams that adopt product thinking, instrument DORA-style outcomes, and convert repeatable tickets into self-service flows will be the ones whose platforms actually scale across the org.
Within a year you won't be asked "what tools does your platform support?" You'll be asked "how has the platform changed deployment frequency and lead time for this quarter?" If your answer is still a list of connectors, start rewriting your roadmap.