Platform as Product: When Your Internal Customers Fire You

General
1

Three months ago, my platform team shipped what we thought was our masterpiece. We’d spent 18 months building an internal developer platform—beautiful CI/CD pipelines, automated provisioning, the works. We demoed it to standing ovations. Then we measured adoption: 10%. Ten percent.

The other 90%? They were still using their own Terraform scripts, clicking through cloud consoles, and building their own tooling. We hadn’t been fired yet, but the writing was on the wall.

The Platform Reckoning Is Here

Here’s what I’ve learned watching this play out across the industry: Platform engineering is exploding, but most platforms are failing. Gartner says roughly 80% of engineering organizations will have platform teams by 2026. We’re already at 55% in 2025. This is becoming table stakes.

But here’s the uncomfortable truth: 45% of platform teams struggle with developer adoption, and 18% deliver no measurable results. We’re building platforms nobody wants to use.

Your Developers Are Your Customers Now

The fundamental shift that many platform teams miss: developers are your customers, and adoption must be earned, not mandated.

This isn’t just philosophy—it’s competitive reality. Your developers have alternatives:

  • Cloud provider consoles (AWS, GCP, Azure)
  • Infrastructure-as-code tools they already know (Terraform, Pulumi)
  • Managed IDP vendors (Cortex, Port, Humanitec)
  • Just… building it themselves

When your platform doesn’t solve their problems better than these alternatives, they route around you. Quietly at first, then openly. And suddenly your 18-month investment is gathering dust while developers ship features using tools you don’t even know about.

What Product Thinking Actually Means

In my financial services background, I’ve seen what happens when you treat platforms as products:

1. User Research Comes First
Talk to your developers before building. What’s slowing them down? Where do they waste time? What would make their lives measurably better? The platform my team built was what we thought developers needed, not what they actually asked for.

2. Golden Paths Over Feature Lists
The data shows that 40% of platform teams can’t demonstrate value within twelve months. Why? They’re building features instead of solving complete workflows. A Golden Path—a well-supported, automated route from code to production—is worth more than fifty disconnected features.

3. Adoption Is Your North Star Metric
Not features shipped. Not infrastructure covered. Adoption. If developers aren’t using your platform, you’re not creating value. Period.

4. Documentation and Onboarding Are Products
At my previous company, we rebuilt our platform docs three times before developers stopped asking the same questions. If your devs can’t self-serve in 15 minutes, they’ll build it themselves in 15 days.

The “Fire You” Moment

Here’s what happens when your internal customers choose alternatives:

Your platform team becomes a maintenance burden instead of a force multiplier. Leadership starts questioning the investment. Engineers leave because they’re stuck maintaining something nobody uses. New hires ask why the company isn’t using standard tools. Eventually, someone proposes shutting the whole thing down and adopting a vendor solution.

I’ve watched this happen at two companies now. It’s brutal, demoralizing, and completely avoidable.

What I’m Doing Differently This Time

After our 10% adoption wake-up call, we pivoted:

  • Talked to 30 developers about their actual pain points (not what we assumed)
  • Started with ONE Golden Path for our most common service type, not everything at once
  • Shipped an MVP in 6 weeks instead of a “complete” platform in 18 months
  • Measured developer satisfaction weekly, not quarterly
  • Made the platform team available in Slack channels where devs actually hang out

Six months later? 65% adoption and climbing. Developers are asking us when we’re adding support for their use cases. The difference: we’re solving their problems, not ours.

The Question Every Platform Team Must Answer

If your developers had a budget and could choose any platform—yours, a vendor, or building their own—would they choose yours?

If the answer is no, you’re not building a platform. You’re building technical debt.

Platform engineering isn’t going away. But the mandate-and-mandate approach is dead. In 2026 and beyond, platforms that treat developers as customers will thrive. The rest will get quietly replaced by teams that do.

For platform leaders here: How are you measuring developer satisfaction with your internal tools? And what’s the one thing you wish you’d known before building your platform?

2

This hits way too close to home :sweat_smile:

My startup failed for a lot of reasons, but one of the biggest was that we built what we thought users needed instead of what they actually asked for. We were so in love with our solution that we forgot to validate the problem was even painful enough for people to pay for it.

Platform teams seem to fall into the exact same trap—and honestly, it might be even harder because your “users” are sitting 20 feet away from you. The proximity creates this false sense of understanding. You think you know what devs need because you were a dev, or because you work with them every day. But understanding and assumption aren’t the same thing.

The Design System Parallel

I’ve had to learn this lesson the hard way with design systems too. When I started leading our design system at Confluence, I thought I knew exactly what product teams needed—reusable components, design tokens, all the technical stuff I’d read about.

Two months in? Adoption was maybe 15%. Teams were still building their own buttons and inputs because our system was too hard to use. Not technically—it worked fine. But the learning curve was steep, the docs assumed too much knowledge, and the components were organized the way I thought about design, not the way engineers thought about implementation.

We had to completely flip our approach: treat product teams as customers. Run user research on internal teams. Make the “happy path” dead simple. Obsess over documentation and onboarding. Build components for the 80% use case first, not the edge cases.

Sound familiar? :bullseye:

The Accessibility Angle

Here’s another thing: if your platform isn’t accessible and intuitive, developers will route around it—just like users route around inaccessible interfaces. And I mean “accessible” in the broad sense: Can someone onboard in 15 minutes? Is the documentation written for humans, not robots? Are error messages helpful or cryptic?

When tools are hard to use, people build shadow tools. In product design, that looks like every team creating their own component library. In platform engineering, that looks like… exactly what Luis described. Terraform scripts, cloud consoles, DIY solutions.

Question for Luis

You mentioned talking to 30 developers about their pain points. How did you structure those conversations? Did you use formal user research methods (like Jobs-to-be-Done interviews), or was it more informal “what’s frustrating you?” chats?

I’m curious because I’ve found that how you ask matters as much as who you ask. Devs (like designers, like everyone) often tell you what they think you want to hear unless you dig deeper into their actual workflows.

Also—65% adoption is incredible! What was the one change that moved the needle most? The weekly satisfaction surveys? The MVP approach? I’d love to steal… I mean, learn from your playbook :grinning_face_with_smiling_eyes:

3

Luis, this is such an important conversation. The product approach is absolutely necessary—but I want to add the organizational dynamics piece that I think gets overlooked.

The Incentive Misalignment Problem

Here’s what I’ve seen happen at three different companies: Platform teams get measured on features shipped and infrastructure coverage, while product engineering teams get measured on feature velocity and customer outcomes.

When platform teams say “we built 47 new capabilities this quarter,” leadership nods approvingly. But nobody asks: are developers actually using those 47 capabilities? Are they solving real problems? Are they making product teams faster?

Meanwhile, product engineers are being pressured to ship features as fast as possible. If your platform adds friction instead of removing it, they’ll route around it—not because they’re difficult, but because their performance review depends on velocity.

Your 10% adoption story? I’d bet the other 90% weren’t being stubborn. They were being rational actors in a system that rewarded shipping features, not adopting internal platforms.

What Changed When We Fixed The Metrics

At my current company, we completely restructured how we measure platform success:

  • Removed “features shipped” from platform OKRs
  • Added “developer satisfaction score” (we survey monthly)
  • Added “time saved per developer” as a key metric
  • Tied platform team bonuses to adoption rates, not delivery velocity

The shift was subtle but powerful. Instead of asking “what features can we build?” the platform team started asking “what problems can we solve?” Instead of celebrating launches, we celebrated adoption milestones.

The Hard Data on Platform ROI

Your numbers align with what I’m seeing across the industry:

  • 35% of platform teams deliver measurable value within six months
  • 40% can’t demonstrate value within twelve months
  • 45% struggle with developer adoption from the start

That last number is the killer. If you can’t get developers to adopt your platform in the first 6 months, you’re unlikely to turn it around without major changes. The window for proving value is narrower than most teams think.

Executive Sponsorship Is Non-Negotiable

One more thing that doesn’t get talked about enough: platform teams need air cover from VPs and CTOs.

When product teams push back on platform adoption, someone with authority needs to be able to say “this is a strategic investment, and we’re committed to making it work for everyone.” Not as a mandate, but as a signal that leadership will invest in solving real problems.

Platform teams also need the authority to say “no” to feature requests that don’t serve the 80% use case. Without executive sponsorship, they become a feature factory for the loudest voices instead of a strategic multiplier for the entire org.

Question for the Group

How do you balance platform team autonomy (they need space to build) with developer needs (which change constantly)? I’ve struggled with this—give platform teams too much runway and they build ivory towers. Give them too little and they become reactive ticket-takers.

What’s the right cadence for developer feedback loops? Weekly check-ins feel too frequent, quarterly feels too slow.

4

Coming from the product side, I’m fascinated by this discussion because internal platforms ARE products—they just have a captive customer base, which makes teams lazy about product management.

Let me share how we’d approach this in consumer product development.

Customer Development 101: Talk to Users Before Building

When we build external products, we don’t start with features. We start with Jobs-to-be-Done interviews:

  • What are you trying to accomplish?
  • What’s blocking you today?
  • What workarounds have you tried?
  • How much is this problem costing you (time, money, frustration)?

Platform teams should do the same thing. Before building a CI/CD pipeline, understand: Why are developers “hiring” a platform? What job are they trying to get done?

Common jobs I’ve seen:

  • “I need to deploy code without waiting for DevOps tickets” (speed)
  • “I need to meet compliance requirements without becoming an expert” (safety)
  • “I need to replicate production environments for testing” (consistency)
  • “I need to onboard new engineers faster” (scalability)

Each of these jobs has different solutions. If you build one platform that tries to be everything, you’ll be mediocre at all of them.

Your Developers Have Competitive Alternatives

Luis mentioned this, but I want to emphasize it from a market dynamics perspective.

Your developers aren’t forced to use your platform—they have alternatives:

  • Direct cloud consoles (AWS, GCP, Azure) - high control, high complexity
  • Infrastructure-as-code tools (Terraform, Pulumi) - flexible, requires expertise
  • Managed IDP vendors (Cortex, Port, Backstage-as-a-service) - fast setup, less customization
  • Roll their own - maximum flexibility, maximum maintenance burden

Each alternative has trade-offs. If your internal platform doesn’t win on at least ONE dimension that matters to developers, they’ll choose something else.

Product-Market Fit for Internal Tools

We obsess about product-market fit for external products, but treat internal tools like “build it and they will come.” That’s backwards.

Here’s how I’d measure platform-market fit:

Quantitative:

  • Adoption rate (are developers choosing to use it?)
  • Activation rate (how fast from signup to first value?)
  • Retention (do they keep using it, or abandon after one try?)
  • NPS for internal developers (would they recommend it to new hires?)
  • Time-to-value (how fast can someone deploy their first service?)

Qualitative:

  • Would developers “buy” your platform if they had budget?
  • Do they proactively ask for new features, or passively accept them?
  • Would they be upset if you shut it down tomorrow?

If the answer to that last question is “no” or “I don’t know,” you don’t have product-market fit yet.

The Build Trap for Internal Platforms

One more thing: I’ve seen platform teams fall into what we call the “Build Trap” in product—shipping features to feel productive instead of solving user problems.

Shipping 47 platform capabilities in a quarter sounds impressive. But if none of them measurably improve developer velocity or satisfaction, you’ve just accumulated technical debt.

Better approach: Ship one Golden Path that makes developers 2x faster at the most common task. Then expand from there.

Challenge to Platform Leaders

If your developers had budget and could choose ANY platform—yours, a commercial vendor, or building their own—would they choose yours?

If not, why not? What would need to change?

And for Luis specifically: How do you prioritize feature requests from developers? Do you use a framework like RICE, or is it more intuition-based?

5

As someone who’s lived through the full platform engineering journey—from early DIY attempts to commercial solutions—I want to add the strategic and investment perspective.

The Build vs. Buy Decision Is Back

For the past 5 years, “build your own platform” was the default answer. Backstage was open-source, Kubernetes was mature, and every company thought they could build the next great internal developer platform.

But here’s what we learned: DIY platforms stall due to plugin debt and maintenance burden.

At my company, we spent 18 months building on Backstage. We got something working, achieved maybe 20% adoption, and then hit a wall. Every plugin update broke something else. Version conflicts made upgrades take weeks. Our platform team spent 80% of their time on maintenance, 20% on new features.

Sound familiar? This is the hidden cost of DIY that nobody talks about in the launch blog post.

Why We Switched to Managed Platforms

Last year, we made the strategic decision to sunset our DIY Backstage instance and adopt a managed platform (we went with Cortex, but Port and Humanitec are solid alternatives).

The shift was transformative:

  • Platform team went from 6 engineers to 2 (the others moved to product teams)
  • Adoption jumped from 20% to 75% in 4 months
  • Time-to-production for new services dropped from 3 days to 4 hours
  • Our platform engineers focus on Golden Paths unique to our business, not plugin maintenance

The ROI calculation was simple: the annual cost of a managed platform was less than the fully-loaded cost of TWO platform engineers—and we were able to redeploy four engineers to revenue-generating work.

What Platform Engineers Should Actually Build

Here’s the strategic insight: platform engineers should build the 20% that’s unique to your business, not the 80% that’s commodity infrastructure.

Every company needs:

  • Service catalogs
  • CI/CD pipelines
  • Infrastructure provisioning
  • Observability dashboards
  • Secrets management

These are table stakes. Use vendor solutions or mature open-source tools. Don’t reinvent them.

What you SHOULD invest engineering time in:

  • Golden Paths specific to your compliance requirements (HIPAA, SOC2, PCI-DSS)
  • Workflow automation unique to your product architecture
  • Custom integrations with your legacy systems
  • Developer experience tailored to your team’s skill levels

The Foundation Technologies That Matter

Two technologies form the baseline for platform engineering in 2026: Kubernetes and Terraform/OpenTofu.

If you’re not building on these foundations, you’re creating technical debt. Everything else—service catalogs, portals, automation—should be layered on top of these standards.

We’re also seeing OpenTofu gaining momentum as teams move away from Terraform’s licensing changes. The community energy around OpenTofu is exciting.

Executive Sponsorship Is Critical

Keisha mentioned this, and I want to emphasize it from the CTO perspective: platform success requires executive-level sponsorship and budget.

Most platform failures I’ve seen aren’t technical—they’re organizational:

  • Platform teams are understaffed (2-3 engineers expected to serve 100+ developers)
  • Platform teams lack authority to say “no” to feature requests
  • Platform teams are measured on output (features) instead of outcomes (adoption)
  • Platform teams don’t have dedicated product management

If your company treats platform engineering as “something the DevOps team does in their spare time,” you’ve already lost.

Start Small, Prove Value, Scale

Luis mentioned starting with ONE Golden Path for the most common service type. This is the right approach.

Here’s what an MVP platform looks like:

  • Automate deployment for your most common service type (probably REST APIs)
  • Provide self-service database creation with guardrails
  • Implement basic observability out-of-the-box
  • Document everything for 15-minute onboarding

Ship that in 6-8 weeks. Measure adoption. Iterate based on feedback. Expand to the next service type.

Don’t try to boil the ocean. Nobody needs a “complete” platform on day one.

The Hard Truth

Many platform initiatives fail because they’re underfunded, understaffed, and lack executive support. If you’re being asked to “build a platform” with 2 engineers and no budget for tools or training, push back.

Platform engineering is infrastructure investment. It requires the same rigor, planning, and funding as any other strategic initiative.

For the leaders here: Are your platform teams empowered to succeed, or are they set up to fail?