Your Platform Team Needs Product Managers, Not Just Infrastructure Engineers—Here's Why

General
1

Most platform engineering failures trace back to a fundamental mistake: treating infrastructure as a project instead of a product.

After leading platform initiatives at Microsoft and now as CTO at a mid-sized SaaS company, I’ve seen a clear pattern. The teams that succeed don’t just have brilliant infrastructure engineers—they have product-minded people who understand user research, prioritization, and roadmap discipline.

The Role Gap Nobody Talks About

Infrastructure engineers are exceptional technologists. They can build rock-solid systems, optimize performance, and architect for scale. But here’s what they’re rarely trained in:

  • Conducting user research and developer interviews
  • Ruthless prioritization based on user value
  • Stakeholder management and communication
  • Product roadmap planning and iteration

This isn’t a criticism—it’s a recognition that building platforms requires different skills than building infrastructure.

The 75% vs. 56% Perception Gap

Remember that stat from the research? 75% of platform builders report success, but only 56% of users agree. That’s a massive empathy failure.

When I joined my current company, we had this exact problem. The platform team was proud of their technical achievements, but developers were frustrated and adoption was stuck at 45%.

What Changed: Adding Product Thinking

We added a product manager to the platform team. The first thing they did? Conducted 30 developer interviews.

The discoveries were humbling:

  • Developers wanted better documentation and faster support, not more features
  • The golden paths we built didn’t match actual workflows
  • Our internal tooling had a terrible information architecture
  • We were solving problems we assumed existed instead of real pain points

The Pivot and Results

We completely shifted focus:

  • Stopped building new features for 3 months
  • Rewrote documentation with user journeys in mind
  • Implemented support SLAs and office hours
  • Redesigned the developer portal based on usability testing

Adoption jumped from 45% to 78% in 9 months. Developer satisfaction scores doubled. And here’s the kicker: the platform team was happier because they were solving real problems instead of guessing.

The Hiring Challenge

Product managers for internal platforms are rare. They need:

  • Technical depth to understand infrastructure complexity
  • Product discipline to prioritize ruthlessly
  • Developer empathy from having been in the trenches
  • Stakeholder management skills to navigate internal politics

It’s a unique skill set. You can’t just hire a consumer product manager and expect them to succeed.

Alternative: Train Platform Engineers in Product Thinking

If you can’t hire a dedicated PM (budget, availability), invest in training your platform tech lead:

  • Product management workshops and certifications
  • User research fundamentals
  • Weekly pairing sessions with your product team
  • Shadowing customer-facing PMs

We’ve seen platform engineers successfully adopt product thinking when given proper support and training.

When to Hire a Dedicated Platform PM

My rule of thumb:

  • Sub-50 developers: Train your platform lead, don’t hire dedicated PM
  • 50-100 developers: Consider product coach or part-time PM
  • 100+ developers: Absolutely hire dedicated platform PM
  • Multiple sub-platforms: One PM can’t scale, need PM team

At 150+ engineers across multiple teams, we’re now hiring our second platform PM.

Discussion Questions

Should every platform team have a dedicated product manager? Or can product thinking be embedded in engineering culture?

What’s worked for you? Have you successfully integrated product discipline into platform teams?

What’s the right staffing ratio? How many platform engineers per PM makes sense?

I’d love to hear your experiences—both successes and failures. :speech_balloon:

2

Strong agreement from the product side, Michelle! :bullseye:

You’ve nailed the core issue: platform teams need product management rigor, not just engineering excellence.

The Skill Set Overlap

The best platform PMs I’ve worked with have a unique profile:

  • Technical enough to understand infrastructure complexity and speak the engineering language
  • Product-minded enough to prioritize ruthlessly based on user value, not technical elegance
  • Developer empathy that comes from having shipped code and felt the pain

These people are rare. You can’t just grab a consumer product manager who’s great at running A/B tests for conversion optimization and expect them to excel at platform work.

Applying Jobs-to-be-Done to Platform Features

One framework that’s been incredibly valuable: Jobs-to-be-Done (JTBD).

Developers don’t want a CI/CD pipeline. They want to ship code confidently and quickly without staying up at 2am debugging deployment failures.

Developers don’t want a service catalog. They want to discover which services exist and how to use them without asking five people on Slack.

This reframing shifts the conversation from features to outcomes, which changes what you prioritize.

Product Rituals That Help Platforms

We’ve borrowed heavily from consumer product management:

  1. User story mapping for platform features—visualize the developer journey
  2. Sprint reviews with actual developer users (not just the platform team demoing to each other)
  3. Roadmap prioritization based on impact scoring, not “cool technology”
  4. Retrospectives that include developer feedback, not just team reflection

The “Embed Product Thinking” Alternative

You mentioned training platform engineers in product thinking, which I love. Our approach:

Every platform engineer spends 1 day per quarter shadowing product team developers. They sit next to them, watch them work, see where they struggle.

The insights from this are phenomenal. One engineer watched a developer spend 30 minutes figuring out how to deploy a simple change. Came back and completely redesigned our deployment documentation.

The Customer Advisory Board Model

Instead of or in addition to a PM, consider a platform customer advisory board:

  • 8-10 developers from different teams
  • Monthly meetings to review roadmap and provide feedback
  • Early access to new features for testing
  • Direct input on prioritization

This creates continuous customer development, not just annual surveys.

Staffing Ratio

My rule of thumb: 1 PM for every 5-7 platform engineers, but it depends on platform maturity:

  • Early stage (building initial platform): Need more PM time for research and definition
  • Growth stage (scaling adoption): Need PM to manage stakeholder communication
  • Mature stage (optimization): Engineers can be more autonomous with established product discipline

What’s your experience with advisory boards or similar feedback mechanisms? :thought_balloon:

3

Adding the design perspective here: platform teams need designers too! :artist_palette:

Michelle, you’re spot-on about the product manager gap, but there’s another missing role that nobody talks about—user experience designers.

The UX Gap in Platform Engineering

Most internal platforms have:

  • Terrible information architecture
  • Confusing navigation
  • Dense technical documentation that’s impossible to scan
  • Inconsistent UI patterns
  • Zero consideration for accessibility

I’ve consulted with several platform teams, and it’s the same pattern everywhere. Brilliant engineers build powerful tools, then wonder why developers won’t use them.

A Real Example

One platform team I worked with had built comprehensive “golden path” documentation. They were proud of it—47 pages covering every possible scenario.

The problem? It was completely unusable.

  • No clear entry points for common tasks
  • Technical jargon without explanation
  • No visual hierarchy or scannable structure
  • Hidden behind three levels of navigation

We did a simple documentation redesign:

  • Created clear use-case-based navigation (“I want to deploy a service”, “I want to add a database”)
  • Added visual diagrams for complex workflows
  • Broke dense paragraphs into scannable lists and tables
  • Implemented progressive disclosure (simple path first, advanced options revealed later)

Result: Time to first deployment dropped from 4 days to 6 hours.

No code changes. Just better UX.

What Designers Bring to Platform Teams

  1. Information architecture - organizing content so developers can actually find things
  2. UI/UX design for developer portals and internal tools
  3. Documentation design - making technical content scannable and actionable
  4. Onboarding flow design - reducing friction for new platform users
  5. Accessibility - ensuring tools work for everyone, including developers with disabilities

The Cross-Functional Trio

The ideal platform team structure:

  • Product Manager - decides what to build based on user needs
  • Designer - determines how to build it usably and accessibly
  • Engineers - implement it technically

This mirrors successful product teams, and platforms ARE products.

The Differentiation Point

Even with managed platforms like Backstage, the UX layer is where you differentiate:

  • Custom golden paths need clear, beautiful documentation
  • Onboarding experiences should be delightful, not painful
  • Internal tools should meet the same UX standards as external products

Developers are users. They deserve good design.

The Question Nobody Asks

How many platform teams have designers?

From what I’ve seen: almost none. Should we normalize this? Should platform teams have the same cross-functional structure as product teams?

I’d argue yes. What do others think? :thinking:

4

Love this conversation! The organizational design angle is critical. :building_construction:

When we scaled our EdTech startup from 25 to 80 engineers, platform team structure became a make-or-break decision.

Our Evolution

Initial state (25 engineers):

  • 5 infrastructure engineers doing everything
  • No dedicated platform focus
  • Developers constantly interrupted asking “how do I…?”

Growth phase (50 engineers):

  • Created 3-person platform team
  • Still all infrastructure engineers
  • Built cool tools that nobody used

Current state (80 engineers):

  • 6-person platform team: 4 engineers + 1 PM + 1 technical writer
  • Product manager runs user research and prioritization
  • Technical writer owns documentation and onboarding materials

The Impact Was Immediate

Adding the PM and technical writer doubled our adoption in 3 months:

  • PM discovered through research that developers needed better docs, not more features
  • Technical writer transformed our 30-page wall-of-text into clear, task-based guides
  • Engineers focused on building quality infrastructure instead of guessing what to build next

The Reporting Structure Question

Where should the platform PM report? We debated this heavily:

Option A: PM reports to VP Engineering

  • Pro: Deep understanding of infrastructure constraints
  • Con: Can become too technically focused

Option B: PM reports to VP Product

  • Pro: Brings product discipline and user focus
  • Con: May not understand technical complexity

Our choice: PM reports to VP Product but is embedded full-time with platform team.

This gives us the best of both worlds—product discipline with engineering context.

Staffing Ratio That Works

From our experience: For every 5-7 platform engineers, you need 1 PM.

But it also depends on platform scope:

  • Narrow focus (just CI/CD): One PM can handle 8-10 engineers
  • Broad scope (full developer experience platform): Need 1 PM per 5 engineers

Budget Reality

The pushback we got: “Why do we need a PM? That’s overhead!”

The ROI case we made:

  • Without PM: 5 engineers building features with 20% adoption = 1 engineer’s worth of value delivered
  • With PM: 5 engineers building right things with 80% adoption = 4 engineers’ worth of value delivered
  • PM cost: ~$150K. Value unlocked: 3 additional engineers worth of impact = $600K+

The math was clear.

Cultural Change

The hardest part? Platform engineers initially resisted the PM.

“We know what developers need, we ARE developers!”

What changed their minds: The PM’s first user research project.

After 20 developer interviews, the PM showed the team that:

  • What developers said they wanted ≠ what they actually needed
  • The “must-have” feature we were building ranked 7th in real priorities
  • Documentation and support were the #1 and #2 pain points

Now those same engineers are the PM’s biggest advocates.

Advice for Budget-Constrained Teams

If you can’t hire a full-time PM:

  1. Product coach/consultant (20% time) to train platform lead
  2. Technical writer (often easier to justify than PM)
  3. Dedicated training for platform tech lead in product thinking

We did option #2 first (hired technical writer), saw immediate impact, which justified PM hire.

Question for Michelle: When you scale to 150+ engineers and multiple sub-platforms, how do you coordinate multiple platform PMs? Do they have a lead PM role? :thinking:

5

Great discussion! Coming from the financial services trenches with a different perspective. :briefcase:

Our Pragmatic Approach

At our company (140 engineers), we didn’t hire a dedicated PM for the platform team—at least not initially. Instead, we trained our platform tech lead in product thinking.

Here’s what we invested in:

  1. Product management certification (Pragmatic Institute)
  2. User research workshops (in-house training from our product team)
  3. Weekly pairing sessions with consumer product managers
  4. Quarterly shadowing of customer-facing teams

The Results

Our tech lead now:

  • Runs monthly developer interviews (15-20 per quarter)
  • Prioritizes features based on user impact, not technical interest
  • Tracks adoption metrics and developer satisfaction (NPS)
  • Manages stakeholder communication with exec team

It’s working well. Our platform adoption went from 38% to 71% over 12 months.

The Trade-Off

Advantage: Less expensive than dedicated PM, keeps engineering-first culture

Limitation: Doesn’t scale as well as dedicated PM—our tech lead is stretched thin

When We’ll Hire a Dedicated PM

We’ve set clear criteria:

  • When we reach 150+ engineers (we’re at 140 now)
  • When we have multiple sub-platforms that need independent roadmaps
  • When our platform tech lead can’t maintain both tech and product responsibilities

We’re at that inflection point now—actively hiring our first dedicated platform PM.

Why This Transition Path Worked

The “train first, hire later” approach gave us:

  1. Product thinking embedded in engineering culture before PM arrived
  2. Clear understanding of what skills the PM needs (we know the gaps our tech lead can’t fill)
  3. Buy-in from the team—they see the value of product discipline from their own experience

For Smaller Platform Teams

If you’re a platform team of <10 people serving <100 developers, I’d recommend:

Don’t hire dedicated PM yet. Instead:

  • Train your platform tech lead in product thinking
  • Establish regular developer feedback loops (monthly surveys, quarterly interviews)
  • Partner with existing product team for methodology guidance

Do hire dedicated PM when:

  • You have 100+ developers depending on your platform
  • Platform roadmap becomes complex enough to need full-time prioritization
  • Tech lead is drowning in both technical and product responsibilities

The Lesson

Product thinking is a learnable skill, not magic talent. Engineers can absolutely develop it with proper training and support.

But there’s a limit to how much one person can do. As you scale, dedicated product expertise becomes necessary.

Anyone else taken this “train first, hire later” path? How did it work out? :thinking: