60-70% of Platform Teams Fail Within 18 Months—Are We Building Products or Technical Projects?

General
1

The data from byteiota stopped me cold: 60-70% of platform teams fail within 18 months. At first, I thought this was about poor technology choices or lack of funding. But when I dug deeper, the root cause is more fundamental and uncomfortable.

We treat platform engineering as a technical project when it should be a product.

I’ve been CTO for 4 years at a mid-stage SaaS company, and I made this exact mistake with our first platform attempt. Let me share what failure looks like from the inside—and what we changed to turn it around.

How We Failed (2023-2024)

What we built:

  • Beautiful architecture: microservices, event-driven, GraphQL API
  • Impressive tech stack: Kubernetes, ArgoCD, Terraform modules
  • Dashboard with metrics: deployment frequency, MTTR, service health
  • Documentation: technical specs, API references, architecture diagrams

How we built it:

  • Platform team of 3 infrastructure engineers
  • “We know what developers need” mentality
  • Feature list based on what infra team found interesting
  • Launched after 10 months of development
  • Measured success by: uptime, response time, lines of code

What happened:

  • 12% adoption after 6 months (3 out of 25 product teams)
  • Teams called it “too complex” and “doesn’t solve our problems”
  • Platform team defensive: “They just don’t understand it yet”
  • Spent another 8 months adding features to increase adoption
  • Features were technical improvements, not user pain solutions

We failed because we built a technical showcase, not a product that solved developer pain.

The Pivot: Platform-as-Product (2025-Present)

After that failure, I made controversial changes:

1. Added a Product Manager to Platform Team

Hired someone from our product org to join platform team. The infra engineers were skeptical: “We don’t need a PM, we’re infrastructure.”

Within 2 weeks, the PM had:

  • Interviewed 15 developers about their biggest frustrations
  • Identified top 3 pain points (none of which our platform addressed)
  • Created user journey maps for different developer personas
  • Built a roadmap based on user research, not technical interests

2. Shifted Metrics From Technical to Adoption

Old metrics: uptime, latency, error rate
New metrics:

  • % of teams using platform for deployments
  • Time to first successful deployment for new services
  • Developer satisfaction (quarterly surveys)
  • % of developers who would recommend platform to colleagues

The shift was profound. Suddenly, a feature that improved uptime from 99.9% to 99.99% became low priority because developers didn’t care. A feature that reduced new service setup from 4 hours to 20 minutes became urgent.

3. Required User Research Before Any New Feature

New rule: Before building any feature, platform team must:

  • Interview at least 5 developers who would use it
  • Validate the pain is real (not assumed)
  • Test mockups/prototypes with users before coding
  • Define success metrics (adoption, not technical metrics)

This slowed us down initially but eliminated 70% of feature requests that would have been built and never used.

4. Public Roadmap with Voting

Created a public roadmap where any developer can:

  • See what platform team is building and why
  • Upvote features they need
  • Comment with use cases
  • Submit feature requests with problem descriptions

This transparency changed everything. Teams felt heard. Platform team got constant feedback. Political battles over priorities disappeared (let users vote).

The Results

18 months after the pivot:

  • Adoption: 68% of teams (up from 12%)
  • Developer satisfaction: 8.1/10 (up from 4.2/10)
  • Platform team velocity: Shipping 40% fewer features but 3x higher adoption per feature
  • Maintenance burden: Down from 70% to 30% of team time (because we’re not maintaining unused features)

The Hard Truth

The 60-70% failure rate isn’t about DIY vs managed, Backstage vs custom, Kubernetes vs something else. It’s about platform teams staffed with infrastructure engineers who think they know what developers need without asking.

Here’s the uncomfortable question: How many platform teams have a product manager?

In my experience, most don’t. They have talented infrastructure engineers building what they think would be cool, not what developers actually need.

What This Means for DIY vs Managed Debate

This is why the “DIY is dead” narrative resonates: Managed solutions like Roadie succeed not just because they’re managed—but because they’ve done the product work. They’ve:

  • Interviewed thousands of developers
  • Identified common pain points
  • Built opinionated workflows that solve real problems
  • Iterated based on user feedback across hundreds of companies

DIY platforms fail because teams skip the product discipline and jump straight to building.

Questions for the Community

  1. Does your platform team have a product manager? If not, who’s doing user research?

  2. What metrics do you use to measure platform success? Are they technical metrics or adoption metrics?

  3. How often do you interview developers about their pain points? Before building features or after they’re done?

  4. What % of your last 10 features had >50% adoption? If it’s low, you’re building a technical project, not a product.

The platform engineering movement is maturing. It’s time we stop treating platforms as infrastructure projects and start treating them as products with users.

Sources: Platform Engineering 80% Adoption: 70% Fail Within 18 Months, Platform Engineering Predictions 2026

2

Michelle, this hits so close to home it’s uncomfortable. Your story about treating platform as a technical project instead of a product is exactly what we’re doing at my financial services company.

We Made the Same Mistake

I read your description of how you failed in 2023-2024 and realized: we’re currently in that failure state right now.

Our situation:

  • Platform team: 2 infrastructure engineers (both came from ops backgrounds)
  • No product manager (“we’re technical infrastructure, why would we need PM?”)
  • Feature prioritization: what the platform team thinks is cool/important
  • Success metrics: deployment success rate, API response times, system uptime
  • User research: zero. We assume we know what developers need because we were developers once

The wake-up call:
Your data point about 70% of feature requests being eliminated through user research? That’s the number that stopped me. If we interviewed developers before building, would 70% of what we’ve built never have been built?

I suspect the answer is yes.

The Product Manager Question

Your point about hiring a PM for the platform team is controversial internally. I raised it last month and got pushback:

From platform team: “We don’t need a PM, we’re infrastructure. PMs are for customer-facing products.”

From product org: “Why would platform engineering need product management? You’re building internal tools, not revenue-generating features.”

But here’s what I realized: The platform team is solving for the wrong customer. They’re optimizing for technical elegance, not developer productivity. A PM would force us to:

  • Define who our users are (different developer personas)
  • Understand their jobs-to-be-done
  • Measure success by adoption, not uptime
  • Ruthlessly prioritize features by user impact

The Metrics Shift

Your before/after metrics comparison is powerful:

What we measure now:

  • 99.8% uptime
  • 250ms average API response time
  • 94% deployment success rate

What we should measure:

  • What % of teams actually use the platform?
  • How long does it take a new service to go from idea to production?
  • Would developers recommend our platform to other teams?
  • What % of developer time is spent fighting our platform vs building features?

This shift is hard because our current metrics make us look great. But they don’t measure the thing that matters: are we making developers more productive?

The Hard Question You Forced Me to Ask

After reading your post, I interviewed 5 developers yesterday (your “interview at least 5” rule). Here’s what I learned:

  1. They don’t understand what problems our platform solves. They know it exists but can’t articulate why they’d use it.

  2. The teams using our platform (40%) use it because we mandated it (compliance requirements), not because it makes their lives better.

  3. The #1 pain point developers cited: Setting up local development environments takes 2-3 days. Our platform doesn’t address this at all.

  4. What our platform does well: Deployment automation, audit logging. But these solve compliance problems (leadership cares), not developer problems (developers care).

  5. The features our platform team is most proud of: Ranked last in developer priorities.

This is humbling. We’ve spent 2 years building the wrong things.

What I’m Going to Change

Based on your playbook:

  1. Hire or borrow a PM from product org (even 20% time would help)
  2. Switch primary metrics from technical to adoption
  3. Require user interviews before building any new feature (steal your 5-developer rule)
  4. Create public roadmap with developer input (transparency + voting)

The hardest part will be getting platform team to accept this. They’re talented engineers who take pride in technical excellence. Telling them “your technical achievements don’t matter if developers don’t use them” is going to hurt.

But the data is clear: 60-70% failure rate because we treat this as a tech project, not a product.

How did you handle the culture shift with your platform team? Did any of them resist the product-oriented approach?

3

As someone who leads a design system (which is basically a platform for design/frontend teams), this entire thread validates what I’ve been saying for years: platforms need design thinking.

Design Systems Learned This Lesson Early

The design system world figured out the product mindset before platform engineering did. Here’s why:

Early design systems (2015-2018):

  • Built by frontend engineers who “knew” what designers needed
  • Focused on technical architecture (component APIs, theming systems)
  • Measured success by: number of components, test coverage, build times
  • Adoption: terrible (10-20% was common)

Modern design systems (2020+):

  • Treat designers and developers as users/customers
  • Start with user research: what are your pain points?
  • Measure success by: adoption rate, time saved, satisfaction
  • Have design system PMs or dedicated product owners

The parallel to platform engineering is uncanny.

My Design System Success: Product Thinking

Here’s what made our design system succeed where internal platforms are failing:

1. User Research is Non-Negotiable

Before building ANY component or pattern:

  • Interview 3-5 designers who would use it
  • Validate the pain is real (not assumed)
  • Test prototypes with actual users
  • Define success metrics (adoption, not technical metrics)

Example: Our platform team wanted to build a “powerful, flexible data table component with infinite configuration options.” Sounds great, right?

User research revealed: Designers needed 3 simple table patterns (list view, detailed view, comparison view). The “flexibility” would have made it unusable. We built 3 opinionated components instead of 1 flexible one. Adoption: 85%.

2. Usability Testing Before Launch

Platform teams ship without watching anyone use their work. Design systems can’t get away with that.

We do:

  • Prototype testing (low-fidelity mockups)
  • Alpha testing (real component, friendly team)
  • Beta testing (multiple teams, gather feedback)
  • Launch (with onboarding and support)

This catches 80% of “seemed like a good idea but developers hate it” problems BEFORE we invest in production code.

3. Treat Documentation as a Product

Platform teams write docs for themselves (technical specs, API references). Design systems write docs for users:

  • Getting started guides (not architecture diagrams)
  • Use case examples (not comprehensive option lists)
  • Copy-paste code snippets (not “refer to API docs”)
  • When to use / when not to use (opinionated guidance)

Our most-used documentation? The “recipes” section with copy-paste examples for common patterns. Our least-used? The comprehensive API reference.

4. Public Roadmap with Voting

Exactly what Michelle described. We use:

  • GitHub Discussions for feature requests
  • Quarterly surveys asking “what’s blocking you?”
  • Monthly office hours where anyone can ask questions
  • Public roadmap showing what we’re building and why

This transparency kills the “why aren’t you building feature X?” political battles.

The Platform Team Without Designers

Here’s what bothers me: How many platform teams include designers?

In my experience: almost none. They have:

  • Infrastructure engineers (build the backend)
  • Frontend engineers (build the UI)
  • Maybe a PM (prioritize features)

But no designers. So you get:

  • Usable systems that look terrible (adoption suffers)
  • Beautiful UIs with awful UX (adoption suffers)
  • No user research, usability testing, or design thinking

Michelle’s platform team transformation is great—but adding a designer alongside the PM would have made it even better.

The Question Platform Teams Need to Ask

Michelle asked: “How many platform teams have a product manager?”

I’ll add: “How many platform teams have a designer?”

If your platform has a UI (and most do: dashboards, portals, configuration pages), you need someone who:

  • Understands user research and usability testing
  • Can prototype and test before building
  • Thinks about user experience, not just functionality
  • Advocates for users when engineers want to build “powerful” (complex) features

Platforms without designers build for themselves, not their users.

My Challenge to Platform Teams

Next time you want to build a feature:

  1. Sketch it (don’t code it)
  2. Show the sketch to 5 developers
  3. Watch them try to accomplish tasks with your sketch
  4. Note every point of confusion, friction, or frustration
  5. Redesign based on feedback
  6. Repeat until developers succeed without help

Then build the feature.

This process takes 2-3 days and saves months of building the wrong thing.

4

Michelle, your transformation story is a perfect example of what I mean when I talk about “product-led platform teams.” I want to add the organizational structure lens because I’ve seen product-minded platforms fail due to reporting structure.

Who Owns the Platform Team?

In my experience, platform success correlates with where the team sits in the org chart:

Platform teams that struggle:

  • Report to CTO or Infrastructure VP
  • Optimized for technical excellence
  • Measured on system metrics (uptime, latency)
  • Users are “internal customers” (secondary priority)
  • Feature requests compete with infrastructure improvements

Platform teams that thrive:

  • Report to VP Engineering or Head of Developer Experience
  • Optimized for developer productivity
  • Measured on adoption and satisfaction
  • Developers are primary stakeholders (not infrastructure)
  • Feature prioritization driven by developer impact

My Company’s Structure

When I joined as VP Engineering, platform team reported to our CTO. They were:

  • Technically brilliant (99.99% uptime, impressive architecture)
  • Poorly adopted (28% of teams)
  • Defensive about low adoption (“developers don’t understand the value”)
  • Building features CTO found interesting, not what teams needed

I convinced our CTO to move platform team under my org. Changes:

1. Reporting Structure Shift

Before: Platform Team → Infrastructure Director → CTO
After: Platform Team → Developer Experience Lead → VP Engineering (me)

This meant platform team’s success was measured by: Are product teams shipping faster? Not: Is infrastructure stable?

2. Joint Planning with Product Teams

Platform team now joins quarterly planning with product teams:

  • Product teams share roadmaps and blockers
  • Platform team identifies common pain points
  • Prioritization is collaborative, not dictated
  • Platform features tied to product team velocity

This killed the “us vs them” dynamic. Platform team stopped seeing product teams as users who “don’t get it” and started seeing them as partners.

3. Embedded Platform Engineers

We embedded one platform engineer with each product team for 1 sprint per quarter:

  • Platform engineer shadows product team
  • Sees firsthand where platform creates friction
  • Brings insights back to platform team
  • Product team gets dedicated platform support

Impact: Platform team built features based on observed pain, not assumptions. Adoption jumped from 28% to 61% in 9 months.

The Metrics Alignment Problem

Michelle’s metrics shift (technical → adoption) only works if leadership measures platform team correctly.

If CTO evaluates platform team on:

  • System uptime
  • Incident response time
  • Infrastructure cost optimization

Then platform team will optimize for those metrics (even if developers are miserable).

If VP Engineering evaluates platform team on:

  • % of teams using platform
  • Developer satisfaction scores
  • Reduction in time-to-production

Then platform team will optimize for developer experience.

Incentives drive behavior. You can hire a PM, do user research, and create public roadmaps—but if platform team is rewarded for uptime instead of adoption, they’ll prioritize uptime.

The Hard Conversation with Your CTO

Luis mentioned his platform team doesn’t have a PM because “we’re infrastructure, not a product.” This is an org design problem.

The conversation I had with our CTO:

  • Platform team should optimize for developer velocity, not infrastructure elegance
  • Move them under VP Eng where their metrics align with product delivery
  • CTO retains infrastructure org focused on: reliability, security, cost

This was hard for our CTO (felt like losing control of important team). But once metrics aligned with goals, everything improved.

Questions for Platform Teams

  1. Who do you report to? If it’s Infrastructure/CTO, are your metrics aligned with developer productivity or infrastructure reliability?

  2. How often do you interact with product teams? If it’s only when they file tickets, you’re not close enough to users.

  3. What % of platform team bonuses/promotions are based on adoption vs technical metrics? If adoption doesn’t affect compensation, it won’t be prioritized.

  4. Do platform engineers ever embed with product teams? If not, how do they understand user pain?

Michelle’s product-as-platform approach is correct—but organizational structure has to support it.