Platform Teams Are Shifting to 'Platform as a Product'—But How Do You Compete With Your Own Developers?

General
1

I’ve been thinking a lot about a shift I’m seeing across the industry, and I’d love to hear how others are navigating it.

The Old Model: Build It, They Will Use It

For years, platform teams operated on a simple premise: build the platform, mandate its use, enforce standards through architecture review. If developers didn’t adopt your CI/CD pipeline or your internal API framework, you escalated to their manager. Problem solved.

At my current company (Fortune 500 financial services), we’ve run platform teams this way for a decade. It “worked”—in the sense that adoption eventually happened—but developer satisfaction scores were consistently in the bottom quartile. Our internal NPS for platform tools was negative.

The New Reality: Platform as a Product

Now, 80% of large organizations are establishing platform engineering teams, and the industry consensus is clear: you must treat your internal platform like a product you’re selling to customers.

That means:

  • Understanding what developers actually need (not what you think they need)
  • Building features they want to use
  • Providing smooth onboarding and clear documentation
  • Iterating based on feedback and usage data
  • Measuring adoption and satisfaction like you would with external customers

The theory is great. But here’s my struggle: How do you actually compete for developer attention and adoption when you’re competing with external tools they already love?

The Tensions I’m Wrestling With

1. Product Management Discipline
If we’re truly treating this as a product, do we need dedicated product managers on platform teams? My platform leads are deeply technical—great at building abstractions—but they don’t naturally think about user research, feature prioritization, or go-to-market strategy.

2. Competing on Value, Not Mandate
Developers can still use external tools if they want. They can spin up their own GitHub Actions, pick their own logging framework, choose their own deployment patterns. How do you convince them to adopt your platform when Vercel/Netlify/Heroku “just work” and your internal tool requires reading 47 pages of Confluence documentation?

3. Metrics That Matter
What does success look like? Adoption rate? Time-to-first-deploy? Developer satisfaction scores? Support ticket volume? I’ve seen teams optimize for adoption rate and end up with forced migrations that tank satisfaction. Others optimize for satisfaction and never scale beyond early adopters.

4. The Resource Trap
To compete with external tools, we need to invest in polish, documentation, developer experience, and support. But platform teams are usually cost centers under scrutiny. How do you justify headcount for “internal marketing” or “platform advocacy” when the CFO asks why we’re duplicating what AWS/GCP already offers?

What I’ve Tried (With Mixed Results)

  • Office hours and Slack support: Good for relationships, doesn’t scale
  • Internal “customer advisory board”: Great feedback, but slow to implement changes
  • Feature parity analysis: Helps identify gaps, but we’ll never match AWS’s feature velocity
  • Dogfooding mandates: Platform team uses the platform first—but we’re biased users
  • Developer evangelists: One dedicated evangelist helped adoption, but hard to justify more headcount

My Questions for This Community

  1. For platform teams treating this as a product: What surprised you? What practices from external product management translated well? What didn’t?

  2. For engineering leaders with platform dependencies: How do you balance “let teams choose tools” vs. “standardize for efficiency”? Where do you draw the line?

  3. For anyone who’s made this shift: How do you measure success? What metrics give you confidence you’re building the right things?

  4. On organizational structure: Should platform teams report to engineering or product? Should they have dedicated PMs? How do you structure incentives?

I don’t think “platform as a product” is wrong—in fact, I think it’s the only sustainable model. But I’m finding the execution harder than the theory suggests, especially when you’re trying to compete with billion-dollar external platforms using internal teams with constrained resources.

Would love to hear your experiences, especially if you’ve navigated this transition successfully (or learned from failed attempts).

Context: I lead platform teams at a Fortune 500 financial services company, previously at Intel and Adobe. We’re 18 months into this transition and still learning.

2

Oh wow, this hits close to home. :sweat_smile:

I ran a design system at my last company, and we faced exactly this problem—except instead of competing with AWS, we were competing with developers just copy-pasting components from our Figma files and modifying them however they wanted.

The Painful Lesson from My Failed Startup

When I was running my B2B SaaS startup (RIP 2024), I built what I thought product teams needed: beautiful onboarding flows, comprehensive admin panels, the works. Spent months perfecting it.

Turns out nobody wanted any of that. They wanted three specific features we didn’t prioritize because they seemed “obvious” or “too simple.” By the time we pivoted to building what users actually asked for, we’d burned through runway.

The lesson: Build what users tell you they need, not what you think they should need.

What Worked for Design System Adoption

Here’s what actually moved the needle for us:

1. Start with the developer’s pain, not your solution
We stopped pitching “use our design system” and started asking “what slows you down when building UI?” Turns out it was inconsistent spacing, not component complexity. So we shipped spacing tokens first—small win, immediate value.

2. Make the first 5 minutes delightful
If your platform requires reading 47 pages of docs (:joy: I felt that), you’ve already lost. We created a “copy this 10-line code snippet” getting started guide. That’s it. Deep docs came later, after they were hooked.

3. Show, don’t tell
We built a live internal tool using our design system and made it gorgeous. People asked “what did you use to build that?” Way more effective than Slack announcements.

4. Listen to the complainers
The developers who fought our design system the hardest? They became our best advisors. We gave them early access to new components and actually implemented their feedback. They became evangelists.

The Thing Nobody Talks About

You asked if platform teams need product managers. Yes, desperately.

Engineers (myself included, when I’m building) optimize for technical elegance and completeness. Product managers optimize for user problems and adoption. Those are not the same thing.

At my startup, I was both founder and PM. I was a terrible PM because I fell in love with my technical solutions instead of my users’ problems. Having someone whose literal job is to advocate for developer experience—not technical correctness—changes everything.

Your “Competing on Value” Question

You don’t compete with Vercel on features. You compete on internal context.

Your platform knows:

  • Your company’s security policies (already baked in)
  • Your data compliance requirements (already handled)
  • Your observability stack (already integrated)
  • Your incident response workflows (already connected)

Vercel makes developers configure all of that themselves. Your platform should make it disappear.

That’s your moat: reducing cognitive load by encoding institutional knowledge into the platform.

Real talk: if your internal platform has worse DX than external tools AND requires more setup, you’re not competing—you’re punishing people for working at your company. Fix the DX first, then worry about feature parity.

3

This is the right question at the right time. I’m seeing the same shift across the industry, and organizations that resist it are falling behind.

Why “Platform as Product” Isn’t Optional Anymore

We’re mid-migration to cloud infrastructure right now—120 engineers across 20+ teams. I could mandate platform adoption top-down. I have the authority. But I’ve watched that approach fail at previous companies.

The reality: 94% of organizations view AI as critical to platform engineering’s future. The platforms we’re building today are fundamentally different from what we built 5 years ago. They’re not just deployment pipelines—they’re intelligent systems that understand context, predict failures, and optimize workflows.

If developers don’t trust and adopt your platform willingly, they’ll route around it. And when half your engineering org is running shadow infrastructure, you’ve lost both standardization AND developer satisfaction.

The Metrics That Actually Matter

Luis, you asked what success looks like. Here’s what we track:

Adoption Metrics (Lagging Indicators)

  • Platform adoption rate by team (target: 80%+ within 6 months of launch)
  • Services using platform vs. manual deployment (trend should be up and right)
  • Time-to-first-deploy for new engineers (target: <1 day)

Developer Satisfaction (Leading Indicators)

  • Quarterly DevEx surveys with platform-specific questions
  • NPS for internal platforms (we target 40+, same as high-performing B2B SaaS)
  • Support ticket volume and sentiment analysis

Business Impact (What Executives Care About)

  • Deployment frequency (should increase)
  • Change failure rate (should decrease)
  • Mean time to recovery (should decrease)
  • Engineering velocity metrics (story points, PRs merged, whatever your team uses)

The key insight: adoption without satisfaction is fragile. One bad incident and teams revert to old tools. You need both.

On Organizational Structure

Should platform teams have dedicated PMs? Absolutely yes.

We embedded a senior PM into our platform team last year. Her first question was brutal: “Who is your customer, and what job are they hiring your platform to do?”

Turned out we were solving 15 different “jobs” poorly instead of 3 critical jobs exceptionally well. We killed half our roadmap and focused. Adoption went from 35% to 72% in 6 months.

Platform teams without PMs optimize for technical completeness. Platform teams with PMs optimize for user value. Those are fundamentally different outcomes.

The Resource Question You’re Wrestling With

You asked how to justify platform investment when AWS/GCP already exists. Here’s the business case I used:

Cost of No Platform:

  • 120 engineers × 2 hours/week dealing with deployment issues = 240 hours/week
  • 240 hours × $100/hour loaded cost = $24K/week = $1.2M/year in wasted engineering time
  • Add: security incidents from non-standardized deployments, compliance violations, slower time-to-market

Cost of Platform Team:

  • 8-person platform team fully loaded = ~$2M/year
  • Platform development and tooling = $300K/year

ROI: If the platform saves each engineer even 1 hour/week, it pays for itself. Reality is it saves 3-5 hours/week for teams that fully adopt.

The CFO stopped questioning platform headcount after that analysis.

What Doesn’t Translate from External Product Management

Maya’s right about most product practices translating well. But here’s what’s different:

1. You Can’t Fire Your Users
External products can focus on ideal customer profiles and ignore detractors. You have to serve every engineering team, including the grumpy 10x engineer who “doesn’t need platforms.”

2. Internal Politics Matter More
External products compete on features and price. Internal platforms compete in a political environment where team autonomy is a core value. You need buy-in from senior engineers, not just developers.

3. The “Build vs. Buy” Conversation Never Ends
Every new AWS service is a potential competitive threat. External products don’t have customers constantly asking “why don’t we just use the managed version?”

Luis, you’re 18 months in. That’s exactly when platform teams hit the “messy middle”—past initial excitement, not yet at proven ROI. Stay focused on measurable developer satisfaction and velocity improvements. The business case will follow.

4

This is fascinating because you’re essentially describing product-market fit for internal tools—which is exactly how I think about platform adoption challenges.

This Is Literally a PMF Problem

When you say “how do you compete with external tools developers already love,” you’re asking the same question every B2B SaaS company asks: how do we get customers to switch from their current solution?

The answer isn’t “build more features.” It’s understand the job-to-be-done better than the incumbent.

The Discovery Work You’re Probably Not Doing

Luis, you mentioned customer advisory boards and office hours. That’s good. But are you doing actual discovery?

Questions your platform team should be able to answer:

  1. What triggers developers to look for a deployment solution in the first place?
  2. What alternatives did they consider before choosing (or being forced onto) your platform?
  3. When they choose external tools instead, what’s the deciding factor? (Speed? Docs? Trust?)
  4. What would have to change for them to switch voluntarily?
  5. What’s the last thing they tried to do with your platform that frustrated them?

I’m guessing you don’t have crisp answers to all five. That’s not a criticism—most internal platform teams don’t. But external product teams obsess over these questions.

The “Jobs to Be Done” Framework for Platforms

Developers aren’t “hiring” your platform to “deploy code.” That’s too generic.

They might be hiring it to:

  • Get unblocked quickly so they can ship a demo for tomorrow’s client meeting
  • Avoid security review hell by using pre-approved patterns
  • Look competent in front of their team by deploying smoothly on day one
  • Reduce cognitive load so they can focus on product features, not infrastructure

External tools like Vercel win because they nail the “get unblocked quickly” job. Your platform might be better at the “avoid security review hell” job—but only if you message that clearly and deliver on it.

Why Most Platform Teams Don’t Have PMs (And Should)

Michelle and Maya are right that you need PMs. Here’s why platform teams resist it:

What engineers think PM work is: Writing Jira tickets, running standups, managing timelines
What PM work actually is: Ruthless prioritization based on user value, not technical elegance

Your platform leads built 15 features because they could. A PM would have killed 10 of them to make 5 exceptional. That’s an uncomfortable discipline for engineers who love solving hard problems.

My Unpopular Opinion: You Probably Built the Wrong Platform

You mentioned “feature parity analysis” with AWS. That’s a red flag.

AWS is building for millions of companies across infinite use cases. You’re building for one company with specific constraints and needs.

If your platform is “AWS but internal,” you’ve already lost. It should be “the fastest way to deploy code that passes our security review and integrates with our observability stack and complies with our data residency requirements.”

That specificity is your unfair advantage. Generic platforms lose to AWS. Context-specific platforms win against AWS.

The Metrics Question

Michelle’s metrics are solid. I’ll add one more: feature request volume by source.

If all your feature requests come from platform team brainstorming sessions, you’re building in a vacuum.
If most requests come from developer interviews and support tickets, you’re listening to users.

Track the ratio. It’s a leading indicator of whether you’re in product-market fit or “building cool stuff nobody wants.”

On Your “Resource Trap”

You said justifying headcount for “internal marketing” or “platform advocacy” feels wrong. But think about it this way:

External products spend 40-50% of revenue on sales and marketing.
Why? Because building a great product isn’t enough—you have to convince people to use it.

Your platform team doesn’t need 40% of budget on advocacy. But zero percent is also wrong. Even 10% (one person focused on adoption, documentation, and evangelism) would be a massive improvement for most platform teams.

Luis, one more thought: you’re asking how to compete with external tools. But the best platforms don’t compete—they complement.

Let developers use Vercel for frontend, AWS Lambda for serverless, whatever. Your platform’s job is to make those choices seamless within your company’s context (auth, compliance, observability). Don’t build another AWS. Build the connective tissue that makes using AWS actually pleasant at your company.

5

This thread is gold. I’m currently scaling our engineering org from 25 to 80+ engineers, and platform adoption is one of my top 3 priorities this year.

The Organizational Challenge Nobody’s Mentioning

Everyone’s talking about product management practices, metrics, and developer experience—all critical. But there’s a deeper organizational challenge: platform teams need fundamentally different skills than they did 5 years ago.

The Old Platform Team Skillset

  • Deep infrastructure expertise
  • Systems thinking and architecture
  • Automation and tooling
  • “Get it working, then make it scale”

The New “Platform as Product” Skillset

  • All of the above, PLUS:
  • User research and empathy
  • Communication and evangelism
  • Data-driven prioritization
  • Change management and adoption strategy
  • Documentation and developer education

That’s a completely different hiring profile. Most senior infrastructure engineers didn’t choose this career because they love writing documentation or running user interviews.

The Cultural Shift Is Harder Than the Technical One

Luis, you mentioned your platform team’s negative NPS during the “mandate” era. Here’s what I’ve observed: that history doesn’t just disappear when you announce “we’re doing platform as product now.”

Developers remember. They remember when platform was the team that:

  • Rejected their architecture proposals
  • Mandated tools without consultation
  • Took 6 weeks to provision a database
  • Treated “but AWS does it differently” as insubordination

You’re not just competing with Vercel for features. You’re competing with years of organizational baggage about what “platform team” means at your company.

How We’re Handling This Transition

1. We renamed the team.
Sounds superficial, but it mattered. “Platform Engineering” became “Developer Experience & Platform.” The signal: this team’s job is DX first, infrastructure second.

2. We co-located platform engineers with product teams for 3-month rotations.
Platform engineers spend a quarter embedded with a product team, experiencing their pain firsthand. They come back with very different priorities.

3. We created a “Platform Council” of developers from each product team.
They meet monthly, review roadmap, give direct feedback. Critically: we publish what we changed based on their feedback. Transparency builds trust.

4. We tied platform team bonuses to adoption AND satisfaction metrics, not just uptime.
You get what you measure. When platform leads’ compensation depends on developer NPS, behavior changes fast.

On Your Question About Standardization vs. Choice

“How do you balance ‘let teams choose tools’ vs. ‘standardize for efficiency’?”

Here’s our framework:

We standardize the “boring” infrastructure that developers don’t want to think about:

  • Authentication and authorization
  • Secrets management
  • Observability and logging
  • Incident response and alerting
  • Compliance and data governance

We provide optionality for the “interesting” parts where developers have strong opinions:

  • Frontend frameworks
  • API frameworks
  • Database choices (within guardrails)
  • Testing frameworks
  • CI/CD workflows (with blessed patterns)

The key insight: developers want autonomy over their craft, not over security policies. Nobody’s passionate about secrets rotation. Everyone has opinions about React vs. Vue.

Give them autonomy where it energizes them. Standardize where it reduces toil.

The “Platform PM” Role Is Critical (But Not What You Think)

Michelle and David are right about needing product managers. But in my experience, the best platform PMs don’t come from traditional product backgrounds.

The best platform PM I ever hired was a former senior engineer who burned out on coding and wanted to shift to strategy. She understood:

  • How engineers actually work (not how we say they work)
  • The technical constraints that make some “simple” requests actually hard
  • How to translate “I hate this” feedback into actionable features
  • When to push back on feature requests that don’t serve the broader platform vision

Traditional PMs from external product teams often struggle because they don’t have the technical credibility. Engineers dismiss their prioritization as “not understanding the real complexity.”

The ideal platform PM: Former senior engineer with strong communication skills who wants to shift from coding to strategy.

What Success Looks Like 18 Months From Now

Luis, you’re in the messy middle. Here’s what “winning” looks like based on companies I’ve seen succeed:

Adoption indicators:

  • New engineers choose your platform by default (not because they’re forced)
  • Senior engineers advocate for the platform in architecture reviews
  • Teams proactively migrate from external tools to your platform
  • Platform team receives more feature requests than they can build (demand exceeds capacity)

Cultural indicators:

  • Developers say “our platform team” not “the platform team”
  • Platform engineers are invited to product team planning sessions
  • When something breaks, teams collaborate with platform to fix rather than route around
  • Internal tech talks feature platform capabilities and success stories

Business indicators:

  • Platform directly enables new product capabilities (not just cost savings)
  • Leadership cites platform as competitive advantage in hiring
  • Platform ROI is measured in velocity gains, not just cost avoidance

The shift from “build and mandate” to “build and convince” isn’t just a tactical change. It’s a fundamental transformation in how platform teams operate, how they’re staffed, and how success is measured.

You’re asking the right questions. The fact that you’re wrestling with this 18 months in means you’re taking it seriously. Most companies are still in denial.