LinkedIn "wisdom"

by "Stavros"

The strategic mistake of letting platform engineering teams operate without a clear product mandate—treating infrastructure as a cost center that 'just supports the business' instead of an internal product with users, roadmaps, and adoption metrics

BY STAVROS · MARCH 24, 2026
The strategic mistake of letting platform engineering teams operate without a clear product mandate—treating infrastructure as a cost center that 'just supports the business' instead of an internal product with users, roadmaps, and adoption metrics infographic

The proof is indisputable.

THE INSIGHT

I've been thinking about why so many platform engineering investments quietly fail. The answer is simpler than people want to admit.

Most organizations treat their internal platform team like a cost center. "Infrastructure." A support function. No product manager. No roadmap informed by user research. No adoption metrics. No feedback loops.

Then leadership is surprised when developers route around the platform entirely.

Recent analysis estimates 60 to 70% of platform engineering teams fail to deliver meaningful impact, with nearly half disbanded or restructured within 18 months. About 45% of platform teams don't measure any success metrics at all. You can't run a product without measuring outcomes.

The consequences show up everywhere. Shadow IT accounts for 30 to 40% of IT spending in large enterprises. One case study found 12 product teams had each independently built their own API rate limiting, logging, and error handling. Eight CI/CD pipelines. Three monitoring stacks. All because the official platform didn't meet developers where they were.

The 2024 Atlassian/DX survey found 69% of developers lose 8+ hours per week to inefficiencies. For a 500 developer org, that's roughly $6.9M a year in lost productivity.

Evan Bottcher defines a platform as "a foundation of self-service APIs, tools, services, knowledge and support arranged as a compelling internal product."

"Compelling" is doing a lot of work there. Compelling means voluntary adoption. The CNCF Platform Engineering Maturity Model captures this. Lower maturity relies on mandates ("extrinsic push"). Higher maturity achieves "intrinsic pull," where users choose the platform because the value is obvious. Mandates are a sign your platform has a product problem.

Spotify treats Backstage as an internal product with dedicated product management, user research, and continuous feedback. They see 99% voluntary portal adoption. Organizations implementing the same technology externally? Adoption stuck around 10%. Same tech. Completely different outcome.

When platform teams operate with product discipline, they achieve 2 to 3x developer velocity and 40 to 50% cognitive load reduction. Without that discipline, they become "technically impressive ghost towns."

Only about 21.6% of platform teams have a dedicated product manager. Nigel Kersten says it plainly: "The reason most enterprises fail at these initiatives is that they try to implement them via project management rather than product management."

Gartner predicts 80% of large software engineering organizations will have platform teams by 2026. The market is projected to grow from $5.8B to over $47B by 2035. The investment is pouring in. The product thinking mostly isn't.

If your platform team has no product manager, no user interviews, and no adoption metrics, you're running an infrastructure project and hoping developers show up. They won't. They'll build their own thing, quietly, on a credit card.

THE EVIDENCE

Platform teams without product managers are set up to fail

The data is unambiguous: 60–70% of platform engineering teams fail to deliver meaningful impact, byteiota and the root cause isn't technical — it's the absence of product thinking. When organizations treat internal platforms as infrastructure projects rather than products with users, roadmaps, and adoption metrics, developers route around them, shadow IT proliferates, and millions evaporate in duplicated tooling. Yet only about one-third of platform teams today have a dedicated product manager. [1][2] The gap between how organizations staff platform teams and how those teams need to operate explains why so many expensive platform investments become, as one analyst put it, "technically impressive ghost towns." [3]

This research compiles concrete survey data, expert frameworks, and case studies to support a core thesis: platform teams need product managers and customer empathy just as much as external-facing teams do.

The "platform as a product" framework: what Team Topologies actually says

The intellectual foundation for this argument comes from Matthew Skelton and Manuel Pais's Team Topologies (2019, 2nd ed. 2025) [4] and Evan Bottcher's canonical 2018 definition published on martinfowler.com. [5] Bottcher defined a digital platform as "a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product." [6][7] Skelton and Pais adopted this definition wholesale, making it central to their framework's fourth team type — the platform team. [8][5]

Three concepts from Team Topologies are especially relevant:

Cognitive load as the North Star. Martin Fowler's summary of the book's key insight: "The primary benefit of a platform is to reduce the cognitive load on stream-aligned teams." [9] Platforms should absorb extraneous cognitive load (deployment commands, provisioning, compliance) so developers can focus on germane load — the business domain work that actually creates value. When platforms add complexity instead of removing it, they violate their reason for existing.

The thinnest viable platform (TVP). Skelton describes this as "the smallest set of APIs, documentation, and tools needed to accelerate the teams developing modern software services and systems" [10] — and emphasizes it could be as minimal as a wiki page. [11] The principle resists over-engineering and forces platform teams to start from genuine user needs rather than technical ambition. [12]

Voluntary adoption over mandates. Manuel Pais at PlatformCon: "Instead of mandating that devs use a platform, it's best to create one that proves itself as the easiest option for getting the job done productively." [13] Skelton reinforces this: "Platforms of the past were great big massive things, very difficult to use — black boxes and teams had to use them — it was mandatory to use these things and it was awful." [12][14] The CNCF Platform Engineering Maturity Model codifies this progression — Level 2 relies on "extrinsic push" (mandates), while Level 3 achieves "intrinsic pull" where "users choose to use platforms because of the clear value they provide." [15]

The Thoughtworks Technology Radar has moved "applying product management to internal platforms" all the way to Adopt — its strongest recommendation — stating: "Applying product management to internal platforms means establishing empathy with internal consumers (read: developers) and collaborating with them on the design." [16]

The numbers: developer friction, wasted time, and the productivity tax

Recent surveys paint a stark picture of what happens when internal tooling lacks product discipline.

Time hemorrhage is massive. The 2024 Atlassian/DX State of Developer Experience report (2,100+ respondents) found that 69% of developers lose 8+ hours per week to inefficiencies — roughly a full workday. [17][18] For a 500-developer organization, that translates to approximately $6.9 million annually in lost productivity. [19] The 2025 edition raised this further: 50% of developers now lose 10+ hours per week, [20] with 90% losing 6+ hours. [21] Separately, Cortex's 2024 survey of engineering leaders found 58% estimate developers lose more than 5 hours per week to unproductive work, [22] with the leading blockers being "gathering project context" and "waiting on approvals" [23] — both [23] symptoms of fragmented, poorly product-managed platforms.

Developers are dissatisfied and ready to leave. Only 23% of developers report satisfaction with DevEx improvements at their organization (Atlassian/DX 2024). [24] Two-thirds of developers consider leaving their roles when dissatisfied with developer experience, and 86% of engineering leaders believe retaining top talent will be "nearly impossible" without improving DevEx. [25] The Stack Overflow 2024 Developer Survey (65,000+ respondents) [26] found 52% cited tooling issues as a productivity blocker, while 67% cited technical debt.

Onboarding reveals the platform gap. Cortex found 72% of organizations take more than one month for new hires to submit their first three meaningful pull requests, [23] with 18% taking over three months. [23] Companies with well-product-managed platforms tell a different story: Spotify cut engineer onboarding time in half, [27] Shopify accelerated developer onboarding from 5 days to 4 hours, [28] and one platform team compressed a two-week onboarding process to 2 hours. [29]

Platform teams aren't measuring what matters. Perhaps the most damning statistic: approximately 45% of platform teams do not measure any success metrics at all (Humanitec State of Platform Engineering Vol. 3, 2024). Another 26.64% answered "I don't know" when asked whether metrics had improved since implementing their platform. [30][30] You cannot run a product without measuring outcomes — and nearly half the industry isn't even trying.

What happens when the product mandate is missing

The consequences of treating platforms as cost centers rather than products are well-documented.

Most platform initiatives fail. Analysis from The New Stack (January 2026) estimates 60–70% of platform engineering teams fail to deliver impact, [31] with nearly half disbanded or restructured within 18 months. The root cause, per the analysis: "platform teams treat their work as a technical project instead of a product. Most platform teams are staffed with infrastructure engineers who think they know what developers need without actually asking." [32] This is the "Field of Dreams" anti-pattern — build it and they will come — which virtually never works in platform engineering. [33]

Adoption craters without product thinking. While Spotify reports 99% voluntary portal adoption internally, organizations implementing the same underlying technology (Backstage) externally see adoption rates stuck at roughly 10% [34] on average. [35] The technology is the same; the difference is that Spotify treats Backstage as a product with dedicated product management, user research, and continuous feedback loops. A Spotify internal study found Backstage users are 2.3× more active in GitHub, create 2× as many code changes in 17% less cycle time, and deploy 2× as often [36] as non-users.

Shadow IT fills the vacuum. When the platform doesn't serve developers, developers serve themselves. Gartner estimates shadow IT accounts for 30–40% of IT spending in large enterprises, [37] with the Everest Group putting the figure above 50% for cloud spend. [38][39] One case study found that across 12 product teams, each team independently built its own API rate limiting, logging, and error handling — with wildly different quality levels. The organization maintained eight CI/CD pipelines and three monitoring stacks when two deployment options and one observability platform would have sufficed. [40] Tool sprawl at this scale costs an estimated $1 million annually per development team. [41] Context switching between [21] an average of 7.4 disconnected tools consumes 6–15 hours per week for 75% of developers. [42][41]

The companies that got it right prove the model. Netflix achieved 85% self-service for developer tasks and a 90% reduction in support tickets [31] through a product-managed platform approach. [31] PagerDuty saw 3× faster service creation after adopting a product-managed portal — median time dropped from 75 hours to 25. [43] Aggregated industry data from Gartner shows high-maturity platform teams achieve 40–50% cognitive load reduction, [31] 2.5× faster deployment frequency, and 50% fewer production incidents. [44] One case study documented a 28:1 ROI on platform investment — $2.76 million in annual benefits against $98,000 in platform cost. [20]

Platform engineering is surging, but the PM gap persists

The discipline is growing fast. Gartner predicts 80% of large software engineering organizations will have platform engineering teams by 2026, [45][46] up from 45% in 2022. [47] A Google Cloud/ESG study of 500+ IT professionals [48] found 55% of organizations have already adopted platform engineering, [49] with 90% of adopters planning to expand. [48][49] The PlatformCon community has exploded from 7,000 attendees in 2022 [50][5] to over 40,000 in 2025. [51] The platform engineering tools market is projected to grow from roughly $5.8 billion in 2025 to over $47 billion by 2035 at a ~23% CAGR. [52]

Yet the product management gap remains the industry's blind spot. The 2023 Puppet State of DevOps report found product managers are present in only about one-third of platform teams. [2] A 2025 platformengineering.org analysis reported only 21.6% have dedicated Platform Product Managers, while 25.4% have "no product mindset at all" — which the authors called a "maturity ceiling." [53] Gartner explicitly recommends "adopting a product management approach to developing internal platforms" [54] and "appointing a platform engineering product owner to prioritize first steps based on user and developer experience research." [55] The CNCF Maturity Model makes product management an explicit requirement at Level 3 ("Scalable"), including staffing "roles not traditionally found in internal-serving teams, for example, product management and user experience." [15]

Thoughtworks has gone further, flagging "miscellaneous platform teams" — those without clear customers or product mandates — as an anti-pattern on their Technology Radar: [56] "Unfortunately we're seeing the 'platform team' label applied to teams dedicated to projects that don't have clear outcomes or a well-defined set of customers. As a result, these miscellaneous platform teams struggle to deliver due to high cognitive loads and a lack of clearly aligned priorities." [57][58]

The strongest expert voices making this argument

The expert consensus is remarkably unified. Here are the most quotable voices:

Nigel Kersten, former Field CTO at Puppet and 11-year co-author of the State of DevOps Report, delivers perhaps the sharpest formulation: "I very strongly believe that the reason most enterprises fail at these sorts of initiatives is that they try to implement them via project management rather than product management. Treat your internal user base as a market of users, and the solutions you build as products for those users." [59]

Evan Bottcher (Thoughtworks) set the standard in 2018: [6] "Platforms must be compelling to use, they cannot stand on a mandate alone." [60][61] He adds that a platform is more than software — "it is documentation, and consulting, and support and evangelism, and templates and guidelines." [6][7]

Gregor Hohpe, author of Platform Strategy (2024) and former Google Cloud CTO office member, warns: "Many in-house platforms are outdated by the time they're launched, restrict rather than enable users, and face a certain demise when their use is mandated in a last-ditch effort to make the economics work." [62]

Camille Fournier, Head of Platform Engineering at Two Sigma and co-author of the 2025 O'Reilly book Platform Engineering, is direct: "Make sure your platform teams include a mix of software engineers, operations engineers, and product managers. This balance is crucial for creating effective and cohesive internal platforms." [63] She also urges teams to "instrument your systems early not just for operational and performance metrics, but also for usage metrics and data about how the people are using the product, so that you can make better product decisions." [64]

Paula Kennedy (Syntasso co-founder) frames it most practically at QCon: "You've got user research. You've got design. You've got sales. You've got marketing. You've got product management. We know how to do all of these things, but what we don't see is people applying those same practices to their internal product." [65]

And Charity Majors (Honeycomb CTO) captures the movement's energy: "What I love about the platform engineering movement is that it has brought design thinking and product development practices to the operational domain." [66]

Conclusion: the data makes the case for a product mandate

The research converges on a clear conclusion. When platform teams operate without product discipline — no PM, no user research, no adoption metrics — the failure rate reaches 60–70%, [31][31] adoption stalls at ~10%, [67][35] and organizations bleed millions in shadow IT and duplicated tooling. When they operate with product discipline, they achieve 2–3× developer velocity, [44] 40–50% cognitive load reduction, and near-universal voluntary adoption.

The most underappreciated insight may be this: only 21.6% of platform teams have a dedicated product manager, [53] yet product management is the single strongest predictor of platform success. The Thoughtworks Technology Radar, Gartner, the CNCF Maturity Model, the DORA research program, and virtually every recognized expert in the field now explicitly recommend it. [16] The question is no longer whether platform teams need product managers — it's why so many organizations still haven't hired one. As Nigel Kersten puts it: you're running product management whether you know it or not. [59] The only question is whether you're doing it well or failing by default. [59]

  1. Kratix — https://platformengineering.org/blog/what-does-a-platform-product-manager-do
  2. The New Stack — https://thenewstack.io/why-successful-platform-engineering-teams-need-a-product-manager/
  3. Jellyfish — https://jellyfish.co/library/platform-engineering/metrics/
  4. Medium — https://maa1.medium.com/team-topologies-book-review-ecaad8d9e165
  5. Kratix — https://platformengineering.org/blog/the-story-of-platform-engineering
  6. martinfowler — https://martinfowler.com/articles/talk-about-platforms.html
  7. Martin Fowler — https://martinfowler.com/articles/platform-prerequisites.html
  8. Team Topologies — https://teamtopologies.com/book
  9. Martin Fowler — https://martinfowler.com/bliki/TeamTopologies.html
  10. GitHub — https://github.com/TeamTopologies/Thinnest-Viable-Platform-examples
  11. Thoughtworks — https://www.thoughtworks.com/radar/techniques/incremental-developer-platform
  12. Team Topologies — https://teamtopologies.com/key-concepts-content/what-is-a-thinnest-viable-platform-tvp
  13. Kratix — https://platformengineering.org/talks-library/platform-as-a-product
  14. Team Topologies — https://teamtopologies.com/key-concepts-content/what-are-the-core-team-types-in-team-topologies
  15. cncf — https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
  16. Thoughtworks — https://www.thoughtworks.com/radar/techniques/applying-product-management-to-internal-platforms
  17. Getint — https://www.getint.io/blog/improving-developer-productivity-integrated-tool-ecosystems
  18. atlassian — https://www.atlassian.com/blog/developer/developer-experience-report-2024
  19. ShiftMag — https://shiftmag.dev/developers-waste-8-hours-weekly-on-inefficiencies-like-technical-debt-3956/
  20. byteiota — https://byteiota.com/platform-engineering-roi-2026-80-adoption-reality/
  21. Atlassian — https://www.atlassian.com/blog/developer/developer-experience-report-2025
  22. Cortex +2 — https://www.cortex.io/post/how-to-measure-developer-productivity
  23. Cortex — https://www.cortex.io/report/the-2024-state-of-developer-productivity
  24. Atlassian — https://www.atlassian.com/software/compass/resources/state-of-developer-2024
  25. Oobeya — https://www.oobeya.io/blog/state-of-developer-experience-in-2024-key-findings-and-highlights
  26. Stack Overflow — https://survey.stackoverflow.co/2024/
  27. Spotify Engineering — https://engineering.atspotify.com/2020/04/how-we-use-backstage-at-spotify
  28. Everyday IT — https://www.ai-infra-link.com/how-platform-engineering-transforms-devops-in-2026-a-scalable-operating-model/
  29. Valorem Reply — https://www.valoremreply.com/resources/insights/blog/azure/developer-onboarding-cut-your-ramp-time-in-half-with-this-framework/
  30. Kratix — https://platformengineering.org/blog/takeaways-from-state-of-platform-engineering-2024
  31. byteiota — https://byteiota.com/platform-engineering-80-adoption-70-fail-within-18-months/
  32. The New Stack +2 — https://thenewstack.io/internal-platforms-are-products/
  33. DEV Community — https://dev.to/_steve_fenton_/platform-engineerings-patterns-and-anti-patterns-4gfa
  34. The New Stack — https://thenewstack.io/spotifys-backstage-roadmap-aims-to-speed-up-adoption/
  35. SoftwareSeni — https://www.softwareseni.com/the-platform-engineering-adoption-paradox-why-89-percent-install-but-only-10-percent-use/
  36. Spotify Engineering — https://engineering.atspotify.com/2024/4/supercharged-developer-portals
  37. Josys — https://www.josys.com/article/article-shadow-it-shadow-it-definition-2024-statistics-and-solutions
  38. Zluri — https://www.zluri.com/blog/shadow-it-statistics-key-facts-to-learn-in-2024
  39. LeanIX — https://www.leanix.net/en/wiki/apm/shadow-it
  40. Jellyfish — https://jellyfish.co/library/platform-engineering/when-to-adopt/
  41. Port — https://www.port.io/state-of-internal-developer-portals
  42. byteiota — https://byteiota.com/tool-sprawl-costs-devs-15-hours-weekly-the-1m-crisis/
  43. Spotify — https://backstage.spotify.com/discover/blog/pagerduty-switches-to-spotify-portal
  44. Devopstales — https://www.devopstales.com/devops/how-platform-engineering-reduced-developer-cognitive-load-by-40-spotifys-backstage-journey/
  45. Sedai — https://sedai.io/blog/sedai-recognized-in-gartners-first-platform-engineering-hype-cycle
  46. Be Informed — https://www.beinformed.com/gartners-top-10-tech-trends-2024-embracing-platform-engineering/
  47. Ahead +3 — https://go.ahead.com/gartner-platform-engineering
  48. Google Cloud — https://cloud.google.com/blog/products/application-modernization/new-platform-engineering-research-report
  49. DEV Community — https://dev.to/meena_nukala/platform-engineering-in-2026-the-numbers-behind-the-boom-and-why-its-transforming-devops-381l
  50. Kratix — https://platformengineering.org/blog/platformcon-2023-highlights
  51. Sessionize — https://sessionize.com/platformcon-2025/
  52. Cervicornconsulting — https://www.cervicornconsulting.com/platform-engineering-market
  53. Kratix — https://platformengineering.org/blog/platform-engineering-maturity-in-2026
  54. Gartner — https://www.gartner.com/en/newsroom/press-releases/2023-11-28-gartner-hype-cycle-shows-ai-practices-and-platform-engineering-will-reach-mainstream-adoption-in-software-engineering-in-two-to-five-years
  55. Gartner — https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering
  56. Thoughtworks — https://www.thoughtworks.com/en-de/radar/techniques/platform-engineering-product-teams
  57. Thoughtworks — https://www.thoughtworks.com/en-cn/radar/techniques/miscellaneous-platform-teams
  58. Thoughtworks — https://www.thoughtworks.com/radar/techniques/miscellaneous-platform-teams
  59. InfoQ — https://www.infoq.com/articles/platform-engineering-roadmap/
  60. The New Stack — https://thenewstack.io/platform-as-a-product-in-4-steps/
  61. Mia-Platform — https://mia-platform.eu/blog/platform-as-a-product/
  62. Architectelevator — https://architectelevator.com/book/platformstrategy/
  63. Substack — https://www.lennysnewsletter.com/p/engineering-leadership-camille-fournier
  64. InfoQ — https://www.infoq.com/news/2020/08/fournier-internal-platform/
  65. InfoQ — https://www.infoq.com/presentations/platform-engineering-trends/
  66. Charity — https://charity.wtf/
  67. Humanitec — https://humanitec.com/spotify-backstage-everything-you-need-to-know

EDITORIAL BRIEF

Commissioned from our research desk. Subject to final editorial discretion.

The strategic mistake of letting platform engineering teams operate without a clear product mandate—treating infrastructure as a cost center that 'just supports the business' instead of an internal product with users, roadmaps, and adoption metrics. Discuss how this gap leads to shadow IT, duplicated tooling, and engineers routing around the platform rather than through it. Reference Team Topologies concepts and survey data on developer experience and internal platform satisfaction scores. The takeaway is that platform teams need product managers and customer empathy just as much as external-facing teams do.