Platform-as-a-Product Requires Treating Developers as Customers—But Engineering Orgs Don't Have Product Managers. Who Owns Developer Experience?

General
1

Platform-as-a-Product Requires Treating Developers as Customers—But Engineering Orgs Don’t Have Product Managers. Who Owns Developer Experience?

I’ve been wrestling with this organizational gap for the past six months, and I’m curious how others are solving it.

The Product Discipline Gap

My company just launched our internal developer platform, and we’re running into a classic problem: we built it like infrastructure, not like a product. The platform team spent 9 months building what they thought was technically complete—containerization, CI/CD pipelines, observability stack, the works. Beautiful architecture. 40% adoption rate.

Why? Because nobody asked developers what they actually needed. Nobody prioritized features based on developer pain points. Nobody measured satisfaction or tracked adoption as a north star metric. We treated it like “if you build it, they will come” infrastructure—and they didn’t come.

The data backs this up: Gartner predicts that by 2026, 80% of software engineering organizations will have platform teams, but the top challenge remains developer adoption. Teams with Platform Product Managers report 40% higher developer satisfaction, yet we keep staffing platform teams with just engineers.

The Organizational Question

Here’s what I’m seeing in my org (and curious if this is universal):

  • Platform teams own the infrastructure, tooling, and technical implementation
  • DevOps/SRE owns incident management and operational concerns
  • Engineering leadership sets strategy and priorities
  • Nobody owns the developer experience as a product

Product managers own customer experience. Design leads own user experience. But who owns developer experience when developers are internal users?

The research is clear: platform teams lean toward tooling and infrastructure, while DevEx teams focus on enablement and training. But in most engineering orgs, there’s no clear owner for treating the platform as a product with developers as customers.

Three Organizational Models I’ve Seen

Model 1: Platform Team Owns DevEx
Platform engineers take on product thinking. This works when you have engineers who care deeply about user experience and have the time/skill to do customer research, prioritization, and adoption tracking. But it’s asking engineers to context-switch between building infrastructure and being product managers.

Model 2: Dedicated Platform Product Manager
21.6% of orgs have Platform Product Managers despite 38% saying they need one. This solves the product discipline gap, but creates a new question: where does this PM sit organizationally? Under engineering? Product? DevOps?

Model 3: Engineering Leadership Owns It
The CTO or VP of Engineering treats DevEx as a strategic priority and holds themselves accountable. This works at executive level but doesn’t solve the day-to-day: who runs the developer surveys? Who prioritizes the backlog? Who measures adoption?

My Take (Probably Controversial)

I think engineering orgs need product managers just like product teams do. Not optional at scale—required.

A platform with 50 capabilities that 20% of developers use is less valuable than a platform with 10 capabilities that 80% of developers use daily. But measuring that, prioritizing that, and optimizing for that? That’s product thinking, not infrastructure thinking.

The platform-as-a-product movement says developers are the customers and adoption is earned, not mandated. That requires someone whose job is to understand developer needs, translate them into roadmap priorities, and measure whether the platform is actually making developers more productive.

Questions for the Community

  1. How is DevEx ownership structured in your org? Who runs point on developer satisfaction and platform adoption?

  2. Do you have a Platform Product Manager? If yes, where do they sit organizationally? If no, who fills that gap?

  3. Can engineers be their own product managers? Or does the “maker” mindset conflict with the “customer advocate” mindset?

  4. What metrics do you use? How do you measure whether your platform is actually working as a product?

I’m biased from the design world where we’ve learned that designers can’t be their own product managers—we’re too close to our craft. I suspect platform engineers have the same challenge, but curious what others are experiencing.

Would love to hear how you’re solving this, especially if you’ve found an organizational model that actually works at scale. :rocket:

2

This hits close to home. We’re wrestling with the exact same question at my company.

Model 3 (Leadership Owns It) Is What We’re Trying

I took on DevEx as a personal accountability about 18 months ago. The theory was simple: if the CTO cares about it, platform adoption becomes a strategic priority, not a nice-to-have.

What actually works:

  • Quarterly all-hands where I share platform adoption metrics alongside product metrics
  • Direct line to me for platform team leads (no middle management filtering)
  • Budget authority to prioritize DevEx work over feature delivery when needed

What doesn’t scale:

  • I’m the bottleneck for all major platform decisions
  • Nobody runs day-to-day developer surveys or prioritizes the backlog without my explicit direction
  • The platform team still defaults to “technically complete” over “developers actually use this”

The reality is that executive sponsorship solves the political problem but not the execution problem. I can say “DevEx matters” all day, but if nobody’s job is to measure satisfaction, prioritize features based on developer feedback, and hold the platform team accountable to adoption metrics—it doesn’t happen.

The Platform PM Question

We tried to hire a Platform Product Manager last year. Three challenges:

  1. Salary band confusion: Do they get paid like a PM (product market rates) or an engineer (engineering market rates)? We lost 2 candidates because our eng-focused comp couldn’t compete with product salaries.

  2. Career path uncertainty: Where does a Platform PM go from here? Back to product? Into engineering leadership? Most PMs want clear paths to VP/CPO—Platform PM feels like a dead end.

  3. Skillset mismatch: Product PMs come from customer-facing backgrounds. They know how to run user research on external customers. But interviewing engineers? Prioritizing CI/CD features? Most struggled with the technical depth required.

We ended up hiring a senior platform engineer with product instincts instead. Not ideal, but at least they understand the technical domain.

My Controversial Take

I don’t think the answer is “hire a Platform PM” for most orgs. I think platform engineers need to learn product thinking, and we need to give them time/space to do that work.

That means:

  • 20-30% of platform engineer time dedicated to developer research, not just feature delivery
  • Explicit OKRs around adoption, satisfaction, and productivity impact—not just “shipped X features”
  • Training platform engineers on product frameworks: customer interviews, prioritization, metrics definition

The challenge is that most platform engineers want to build infrastructure, not run developer surveys. It’s a culture shift, not just a role definition.

But I’m increasingly convinced that the “platform as infrastructure” mindset is what’s holding us back. Curious what others think—am I asking too much of platform engineers, or is this the necessary evolution?

3

Really timely thread. We just went through a painful platform reboot that taught us exactly why Product thinking matters for DevEx.

What We Built (Wrong)

18 months ago: Platform team of 6 engineers spent a year building what they called “the future of deployment at our company.” Kubernetes-based, full GitOps, automated rollbacks, the works. Technically brilliant.

Developer adoption after 6 months: 12%

Why? Because the platform team built for their ideal developer, not the actual developers at our company. Turns out:

  • 60% of our engineers had never used Kubernetes
  • Our apps were mostly monoliths, not microservices
  • The “simple” onboarding required 47 steps and 3 days of training
  • No migration path from our existing deployment process

We built a Ferrari for people who needed a Honda Civic.

What Changed: Jobs-To-Be-Done Framework

We brought in someone from product (me, actually—I moved from product to “Head of Platform Experience” 9 months ago). First thing I did was apply Jobs-To-Be-Done thinking to platform adoption.

The job developers were hiring our platform for:

  • “Deploy my code to production without asking DevOps for help”
  • “Know if my deployment broke something”
  • “Roll back when I mess up”

NOT:

  • “Learn Kubernetes”
  • “Become a DevOps expert”
  • “Adopt GitOps best practices”

This shift changed everything. We deprecated 60% of the platform features and focused on 3 workflows that solved the actual job. Adoption went from 12% to 73% in 4 months.

Organizational Placement: Product, Not Engineering

Here’s what’s working for us: I report to the CPO, not the CTO. Controversial, but it solves two problems:

  1. Product discipline by default: My OKRs are adoption, satisfaction, time-to-value—same as product PMs. Not technical completeness.

  2. Cross-functional advocacy: I can push back on engineering when they want to build the “technically correct” thing that developers won’t use. I speak product language at exec level.

The platform team still reports to engineering (they need technical leadership), but the platform strategy and prioritization comes through product discipline.

On Engineers Learning Product Thinking

@cto_michelle I respectfully disagree with your take. Most engineers shouldn’t have to learn product thinking—that’s why PMs exist.

Product thinking is a skill that takes years to develop: customer research, market sizing, prioritization frameworks, adoption funnels, behavioral psychology. Would you ask PMs to learn distributed systems architecture in their spare time?

What works better: hire someone who knows product and teach them just enough about platform engineering to understand the domain. That’s easier than teaching engineers to be PMs while also expecting them to ship infrastructure.

The platform team needs someone whose literal job is to say “I know this is technically elegant, but developers won’t use it—build this instead.” That takes product discipline, not infrastructure expertise.

Metrics We Track

Since you asked:

  • Adoption rate: % of engineers actively using the platform
  • Time-to-first-deployment: How fast can a new engineer ship code?
  • Developer satisfaction: Quarterly survey (NPS-style)
  • Support ticket volume: Are developers self-sufficient or constantly blocked?
  • Feature usage: Which 20% of features get 80% of usage?

We treat it exactly like a SaaS product with an internal customer base. If adoption drops, we investigate like we would for external churn.

This works because my incentives are aligned with developer success, not technical complexity. Platform engineers build infrastructure. Product managers optimize for customer outcomes. DevEx needs both.

4

Coming from the front lines with a different perspective: we don’t have a Platform PM, and honestly, I’m not sure we need one for our size.

Context Matters: 40 Engineers vs 400

My org has ~40 engineers. We have a 2-person “platform team” (really just infra engineers who also own DevEx). No budget for a dedicated Platform PM, and frankly, the overhead wouldn’t be worth it.

What works for us:

1. Rotating “Developer Advocate” Role
Every quarter, one engineer from a product team spends 20% of their time embedded with the platform team. Their job: represent developer needs, test new tooling, give feedback before it ships.

This solves the “platform engineers are too close to the metal” problem without hiring a PM. Plus, it builds empathy—product engineers understand platform constraints, platform engineers hear real pain points.

2. Lightweight Product Rituals
We borrowed from product playbooks without the full PM overhead:

  • Monthly developer surveys (5 questions, takes 2 minutes)
  • Bi-weekly platform office hours where any engineer can give feedback
  • Public backlog with upvoting (GitHub issues, not fancy tooling)
  • Quarterly retrospectives: “What did we ship? What got adopted? What flopped?”

3. Engineering Leadership Sets North Star
Our VP of Engineering defines the strategy: “reduce time-to-deploy by 50%” or “enable any engineer to debug production issues without SRE help.” The platform team figures out how.

This isn’t perfect, but it scales to our size. I worry that adding a Platform PM for 40 engineers would create more coordination overhead than value.

When You Need a Platform PM

Based on watching peers at bigger companies, here’s my hypothesis on when Platform PM becomes necessary:

  • 100+ engineers: Developer feedback is too fragmented to gather informally. You need structured research and data.
  • Multiple platform teams: When you have separate teams for CI/CD, observability, cloud infra, etc., someone needs to own the holistic DevEx strategy.
  • Low adoption crisis: If developers are actively avoiding your platform, you need dedicated product expertise to diagnose why.

Below that threshold? I think platform engineers can learn enough product thinking to get by—as long as you:

  1. Give them time (not 100% feature delivery)
  2. Give them training (send them to product conferences, pair them with PMs)
  3. Give them accountability (OKRs on adoption, not just shipping)

The Skills Question

@product_david makes a fair point about product thinking being a distinct skillset. But I’d push back slightly: basic product instincts aren’t that hard for engineers to learn.

Things like:

  • Talking to users (developers) before building
  • Measuring whether people actually use what you shipped
  • Prioritizing based on impact, not technical interest

These aren’t PhD-level product management. They’re just… not being in a vacuum. Most engineers can do this if their manager creates space for it.

What engineers can’t easily learn: market positioning, competitive analysis, monetization strategy. But for internal platforms? You don’t need those skills. You need empathy, measurement, and prioritization—which are teachable.

Different Models for Different Scales

I think the answer to “who owns DevEx” depends on org size:

  • <50 engineers: Platform team + product rituals + rotating advocate
  • 50-200 engineers: Dedicated Platform PM embedded in engineering
  • 200+ engineers: DevEx org with Platform PM + DevRel + enablement team

Trying to do the 200+ model when you have 40 engineers wastes resources. Trying to do the <50 model when you have 300 engineers means platform adoption stays stuck at 40%.

The real question isn’t “should we have a Platform PM?” It’s “what product discipline do we need at our current scale?” And that answer changes as you grow.

5

Great discussion. Adding the VP of Engineering perspective since I’ve seen this play out across both mature platform orgs and startups building from scratch.

The Uncomfortable Truth: Platform Teams Fail Without Product Discipline

I’ve watched 3 platform initiatives fail at previous companies. Same pattern every time:

  1. Engineering leadership greenlights platform team
  2. Engineers build technically excellent infrastructure
  3. Developers don’t adopt it
  4. Platform team gets frustrated, blames “developer laziness” or “lack of education”
  5. Executive team loses confidence, platform gets deprioritized or dissolved

The common denominator? No one was accountable for adoption as the success metric.

Platform engineers measured success by “what we shipped.” Engineering leadership measured success by “are we meeting velocity goals?” Developers measured success by “can I ship my feature without learning a new thing?”

Nobody’s incentives aligned around “are developers actually more productive because of this platform?”

Two Organizational Models That Work

In my experience, only two structures consistently succeed:

Model A: Platform PM Reporting to CPO/Product
What @product_david described. Platform strategy comes from product discipline. Engineering builds, product drives adoption.

Works when: You have product leadership that understands technical platforms. Doesn’t work if your CPO sees “internal tooling” as second-class compared to customer-facing features.

Model B: DevEx as Dedicated Org Under CTO
Not just “platform team” but a full org: Platform PM + DevRel engineers + enablement/training + platform engineers. The Platform PM owns adoption, DevRel owns education, platform engineers own building.

Works when: You’re big enough (200+ engineers) to justify the org overhead. CTO explicitly prioritizes DevEx as strategic, not operational.

What Doesn’t Work: Asking Platform Engineers to Also Be PMs

@cto_michelle I see what you’re going for, but in practice, this creates burnout and bad outcomes.

Platform engineers are hired to build distributed systems, not run developer surveys. Asking them to also do product research, prioritization, and adoption tracking is a recipe for:

  • Resentment: “I became an engineer to build things, not run focus groups”
  • Skill mismatch: Most engineers don’t want to learn customer research methods
  • Context switching: Constantly switching between coding and product thinking kills productivity

The better investment: hire the right role for the job. Platform PM isn’t an engineering role with product responsibilities—it’s a product role that happens to work on platforms.

On Engineers Learning “Basic Product Instincts”

@eng_director_luis I love your optimism, but I’ve seen this fail more often than it succeeds.

“Basic product instincts” sounds simple, but in practice:

  • Talking to users: Engineers hear technical requirements (“I want faster deploys”), not jobs-to-be-done (“I want to ship code without asking for permission”)
  • Measuring usage: Engineers measure technical metrics (deployment frequency), not outcome metrics (developer productivity, satisfaction, time-to-value)
  • Prioritizing by impact: Engineers prioritize what’s technically interesting or architecturally elegant, not what solves the biggest developer pain

These aren’t character flaws—they’re the natural result of hiring people who love building systems. Asking them to also love customer research is like asking PMs to also love debugging distributed systems.

My Recommendation: Hire the Right People

For orgs at Maya’s scale (<50 engineers), I agree you don’t need a full-time Platform PM. But you need someone with product DNA—even if it’s a PM who dedicates 20% to platform, or an engineer who actually wants to do product work (rare, but they exist).

For orgs at 100+ engineers, hire a Platform PM. Yes, it’s expensive. Yes, career pathing is tricky. But the alternative is watching millions of dollars in platform investment get 40% adoption.

Metrics Alignment is the Real Issue

Here’s what I think is the core problem: engineering leadership rewards platform teams for technical excellence, not adoption.

Platform engineers get promoted for:

  • Migrating to Kubernetes
  • Building elegant abstractions
  • Reducing infrastructure costs

Not for:

  • 90% developer adoption
  • Cutting onboarding time in half
  • Improving developer satisfaction scores

If we changed promotion criteria to reward adoption and impact, platform engineers would suddenly care a lot more about product thinking. The problem isn’t that engineers can’t learn—it’s that we don’t incentivize them to.

So maybe the answer isn’t “hire a PM” or “train engineers.” Maybe it’s: change what engineering leadership measures and rewards.