I’ve been watching platform engineering teams struggle with the same pattern for the past 18 months, and the 2026 data confirms what many of us suspected: 45.5% cite developer adoption as their top challenge—not technical complexity, not budget constraints, not tooling limitations. Developer adoption.
Yet when I talk to platform teams, here’s what I hear: “We built this amazing CI/CD pipeline with 40% faster deployments.” “Our internal developer platform has 50+ capabilities.” “We standardized on Kubernetes and created golden paths for every use case.”
Great. How many developers are actually using it?
Crickets.
The Uncomfortable Truth: We’re Building Infrastructure, Not Products
The data is stark:
- 80% of organizations now have platform teams
- But 60-70% of platform projects fail to deliver impact
- 22% of teams report high satisfaction with internal platforms
- Average internal adoption rates hover around 10% outside of Spotify
Meanwhile, 36.6% rely on mandates to drive adoption. And 29.6% admit they don’t measure success at all.
Let me translate this into product language: We’re building products nobody wants, forcing people to use them, and then not measuring whether they’re actually valuable.
If a product team shipped a feature with 10% voluntary adoption and needed mandates to hit 30%, we’d kill that feature immediately and ask hard questions about product-market fit. But somehow when it’s “internal infrastructure,” we call it success and ask for more budget.
Developers Are Customers—They Just Have Different Buyers
Here’s the fundamental misunderstanding: platform teams think developers are “users” they control. But developers are actually customers with choices.
They can:
- Work around your platform
- Ignore your golden paths
- Build shadow platforms
- Advocate against platform adoption in retrospectives
- Leave for companies with better developer experiences
When you recognize developers as customers, everything changes. You start asking different questions:
- What job are they trying to get done?
- What pain point does our platform actually solve for them?
- Why would they choose to use this over alternatives?
- What does success look like from their perspective?
These are basic product thinking 101 questions. Yet platform engineering treats them like radical concepts.
The “If You Build It, They Will Come” Trap
I see platform teams making the same mistake early-stage startups make: falling in love with the solution before validating the problem.
They spend 6-12 months building technically excellent infrastructure. They create comprehensive documentation. They design beautiful architecture diagrams. They present at internal tech talks.
And then… developers don’t adopt it.
Why? Because the platform team optimized for what they thought developers needed instead of what developers actually need. They built the platform they wanted to build, not the platform developers wanted to use.
Sound familiar? It should. It’s the classic product failure pattern—just wrapped in infrastructure clothing.
What Platform-as-a-Product Actually Means
The most successful platform teams I’ve seen treat their work like a product:
1. User research before building
Talk to developers. Observe their workflows. Understand their actual pain points—not what you assume they need.
2. Jobs-to-be-done framework
Developers don’t want “a CI/CD pipeline.” They want to ship code safely without thinking about infrastructure. Big difference.
3. Measure what matters
Not platform uptime. Not number of features. But: time from idea to production, developer satisfaction, voluntary adoption rate.
4. Iterate based on feedback
Ship smaller, get feedback, improve. Don’t build for 12 months and unveil the grand vision.
5. Design for segments, not averages
Backend engineers, ML engineers, frontend engineers, data engineers—they all have different needs. One golden path might work for 30% and create friction for 70%.
The AI Wildcard
Here’s what’s interesting about 2026: AI might actually force platform teams to get product thinking right.
Developers can now describe what they need, and AI can translate that into infrastructure configurations. The value proposition of platforms shifts from “standardization and compliance” to “removing toil and enabling capabilities.”
Platforms that already treat developers as customers will thrive. Platforms that rely on mandates and ignore adoption? They’ll become obsolete faster than DevOps did.
Questions for the Community
I’m curious about your experiences:
-
If you’re on a platform team: Do you measure developer satisfaction? Do you do user research with your developers? What does “success” mean for your platform?
-
If you’re a developer using (or not using) internal platforms: What would make you choose to adopt a platform? What friction points make you avoid them?
-
For leaders: How do you balance standardization needs with developer autonomy? When does a mandate make sense vs when should adoption be voluntary?
The 45% struggling with developer adoption in 2026 suggests we’re treating platform engineering as an infrastructure problem when it’s fundamentally a product problem. Maybe it’s time we admitted that and started applying product thinking—before AI forces our hand.
What do you think? Am I missing something here, or are we collectively ignoring Product Management 101?