Platform teams organizing around 'what developers need' vs 'infrastructure we manage'—when did we become customer-obsessed?

General
1

I’ve been working closely with our platform team for the past 18 months at our Series B fintech startup, and I’ve witnessed something fascinating: a fundamental identity shift that’s changing how we think about infrastructure teams entirely.

The Old Model: “We Manage Infrastructure”

Two years ago, our platform team’s roadmap looked like this:

  • Kubernetes cluster upgrade
  • Implement service mesh
  • Database migration to PostgreSQL 15
  • Security scanning pipeline

Notice anything? Every item is technology-focused. The team organized around what they managed—infrastructure, deployment pipelines, monitoring systems.

When developers needed something, they’d file a ticket. The platform team would evaluate the request against their technical roadmap. Sometimes requests sat for months because “we’re focused on the K8s upgrade right now.”

The New Model: “We Enable Developer Velocity”

Fast forward to today. Our platform team’s roadmap now reads:

  • Reduce deployment friction for new services (target: <30 min for new service)
  • Improve local dev environment setup (target: zero Docker knowledge required)
  • Self-service database provisioning (target: developer can provision test DB in 5 clicks)
  • Onboarding acceleration (target: new engineer ships code day 1)

Same team. Same technologies underneath. But the framing is completely different. They’re organized around what developers need, not what infrastructure they manage.

The Skills Gap Nobody Talks About

This shift requires different competencies:

Before (Operators):

  • Deep infrastructure expertise
  • Technical problem-solving
  • System reliability focus

After (Product Builders):

  • All the above, PLUS:
  • User research with developers
  • Prioritization frameworks (RICE, WSJF)
  • Metrics-driven iteration
  • Stakeholder communication
  • Internal “product-market fit” discovery

We actually hired a Platform Product Manager last quarter—something I never imagined we’d need for an infrastructure team. But it’s made a massive difference.

The Measurement Shift

What we measure has changed too:

Old metrics:

  • System uptime
  • Infrastructure costs
  • Number of incidents

New metrics:

  • Time to first deploy (new engineer)
  • Developer satisfaction scores
  • Adoption rate of platform capabilities
  • Blocked developer hours (tickets older than 48h)
  • Business value enabled (revenue features unblocked)

Research backs this up: teams that lack this product mindset see an 8% decrease in throughput and 14% decrease in stability. It’s not just philosophy—it’s measurable impact.

When Did This Happen?

Gartner predicted 80% of engineering orgs would have platform teams by 2026. We hit that milestone. But nobody told us that “having a platform team” meant fundamentally reimagining their identity.

According to recent research, only 36.6% of platform teams have dedicated product managers, yet those that do report faster time to value. We’re still in early days of this transformation.

Questions for the Community

From a product perspective, I’m fascinated by this shift. But I’m curious about your experiences:

  1. For platform team members: How do you feel about being called “product builders” instead of “infrastructure operators”? Does it resonate or feel like corporate speak?

  2. For engineering leaders: Have you hired product managers for your platform teams? How did that change the dynamic?

  3. For individual contributors: As a “customer” of your platform team, do you notice a difference in how they operate? Better? Worse? Just different?

  4. For everyone: Where does this stop? If platform teams are product teams, and design systems teams are product teams, and HR tech teams are product teams… are we diluting what “product” means?

I’m particularly interested in hearing from folks who’ve resisted this framing. What am I missing?

Sources:

2

David, this resonates deeply with my experience scaling our platform team from 3 to 12 people over the past two years.

The Hiring Challenge Is Real

Your question about hiring product managers hits home. We brought in our first Platform PM nine months ago, and honestly, it was controversial internally. Some engineers saw it as “management bloat” or questioned whether we needed “another non-technical person telling us what to build.”

But here’s what changed: Before the PM, our platform team’s roadmap was driven by what excited the engineers (“Let’s implement Istio!”) or what was loudest in Slack. We were reactive, not strategic. After the PM, we started running actual user research with developers, tracking adoption metrics, and most importantly—saying no to things that didn’t align with developer needs.

The Cultural Shift Is Harder Than the Org Chart

The identity shift you’re describing isn’t just about job descriptions—it’s about fundamentally changing how people see their impact. Platform engineers who came from SRE backgrounds were proud of their technical depth. Now we’re asking them to care about developer satisfaction scores and time-to-first-commit metrics.

Some embraced it immediately. Others felt like we were “dumbing down” their work or turning them into support agents. One senior engineer told me: “I didn’t get into infrastructure to run user interviews.”

My approach was to reframe it: You’re not doing less technical work—you’re ensuring your technical work creates value. The Kubernetes cluster upgrade only matters if it enables developers to ship better, faster. That mindset shift took 6+ months and is still ongoing.

What Actually Works

Three things that helped us make this transition:

  1. Shadow developers for a day - Had platform engineers literally sit with app developers and watch them struggle with deployment, local setup, debugging. Nothing builds empathy faster than watching someone curse at your tools.

  2. Shared success metrics - Instead of platform OKRs vs. product OKRs, we created joint metrics: “Time from commit to production” involves both teams. This forced collaboration.

  3. Product thinking training - We ran workshops on user personas, jobs-to-be-done framework, and prioritization. Engineers were skeptical at first but eventually found the frameworks useful.

The Question That Keeps Me Up

Your fourth question—about diluting “product”—is something I wrestle with. If every internal team is a “product team,” does the term lose meaning? Or is this the natural evolution as software eats every function?

I lean toward: It’s not about the label, it’s about the mindset. Product thinking means understanding your users, measuring impact, and iterating based on feedback. Whether you’re building a SaaS app or an internal CI/CD pipeline, those principles apply.

But I do worry about creating too many “product” fiefdoms where every team optimizes their local metrics without considering the system. That’s where strong engineering leadership (hi, it me) has to maintain the bigger picture.

Curious what others think—especially from those in platform roles who might have a different take.

3

Coming from financial services, I’ll share a perspective that might be different from the startup world.

The “Customer” Framing Was Hard to Swallow

When our VP of Engineering first introduced this concept two years ago, my team pushed back hard. In banking, we think about customers as account holders, not internal developers. The language felt too Silicon Valley, too startup-culture for our environment.

One of my lead engineers said: “We’re not selling anything. We’re maintaining critical infrastructure. Calling developers ‘customers’ makes it sound like they can choose not to use our services.”

And he had a point! Unlike external products, developers can’t just switch to a competitor’s platform. They’re stuck with what we build.

What Changed Our Minds

Two things helped us get past the semantics:

1. Measuring developer pain quantitatively

We started tracking “blocked time”—hours when developers couldn’t make progress because of platform issues. It was shocking: 240 developer-hours per week across our org of 40 engineers. At an average fully-loaded cost of $100/hour, that’s $24K/week or ~$1.2M/year in lost productivity.

When we presented that to leadership, suddenly platform improvements weren’t “nice to haves”—they were ROI conversations. The CFO got interested. Budget conversations changed.

2. Creating a feedback loop

We implemented a simple Slack workflow: after every platform interaction (deployment, database provisioning, environment setup), developers got a quick survey: “How was that experience? 1-5 stars.”

Initially, we averaged 2.8 stars. Brutal but honest. We started treating every 1- or 2-star rating like a P1 incident—same urgency, same visibility. Within 6 months, we hit 4.2 stars. More importantly, our platform engineers cared about that number. It became a proxy for “are we doing good work?”

The Surprising Benefit Nobody Expected

Here’s what I didn’t anticipate: recruiting got easier.

Platform engineering roles in financial services used to be hard sells. “Come manage our Kubernetes cluster” doesn’t excite many people. But “Come build products that enable 40 engineers to ship faster and focus on business value”? That’s compelling.

We hired two exceptional engineers in the past 6 months who specifically mentioned being attracted to the product-focused approach. One came from a consumer tech company and said: “I wanted to keep building products, but I love infrastructure. This lets me do both.”

Still Wrestling With Scale

Where I struggle: this works great at 40 developers. But we’re growing to 80+ next year. How do you maintain the “customer intimacy” when you have 80 internal customers with diverse needs?

In external product companies, you segment users and focus on your ICP (ideal customer profile). Do we do that internally? Say “sorry, we optimize for backend engineers, not ML engineers”? That feels wrong but also… necessary?

David, Keisha—how do your teams think about this at scale?

4

Oh wow, this hits close to home for me as someone who leads a design system team! We went through almost the exact same identity crisis a year ago.

Design Systems = Internal Product (We Learned the Hard Way)

When I first took over our design system, I thought my job was to build a comprehensive component library with perfect accessibility, beautiful animations, and rock-solid documentation. I was so proud of our Button component—it supported 12 variants, 4 sizes, and had 95% test coverage.

Nobody used it. :sob:

Turns out, designers didn’t need 12 button variants. They needed one really good default button that worked for 80% of cases, and maybe 2-3 specialized ones. But I was so focused on “building the best button possible” that I never asked them what they actually needed.

Sound familiar? That’s operator mindset, not product mindset.

The Parallel Is Almost Eerie

Reading David’s post, I kept nodding along because design systems teams are basically mini-platform teams:

  • Platform team: Builds infrastructure that developers consume
  • Design system team: Builds components that designers/frontend engineers consume

Both are internal products. Both suffer when they optimize for technical elegance over user needs.

What “Product-Market Fit” Means Internally

Luis, your question about customer segmentation is so interesting because we faced the same thing. We had:

  • Senior designers who wanted full control and customization
  • Junior designers who wanted opinionated defaults
  • Frontend engineers who wanted low-level primitives
  • Product managers who wanted prototyping speed

Can’t serve everyone equally! We had to make a choice.

We decided: our ICP is mid-level frontend engineers building production features. Seniors could build custom solutions. Juniors got documentation that guided them to the happy path. PMs could use Figma for prototyping.

It felt exclusionary at first, but adoption went from 40% to 85% in 6 months. Turns out clarity beats trying to please everyone.

The Question That Haunts Me

David’s fourth question—“are we diluting what ‘product’ means?”—keeps me up at night too.

When my startup failed, one reason was lack of focus. We tried to be everything to everyone. Now I’m building an internal product with the same risks. What if platform teams, design system teams, HR tech teams all adopt “product thinking” but lose sight of the actual product customers are paying for?

Like… at some point, someone has to ship the thing that generates revenue, right? If everyone’s optimizing internal experiences, who’s obsessing over external customer value?

Maybe that’s what product managers like David are for—keeping us honest about the ultimate goal while we optimize the machinery?

I don’t have answers, just solidarity in the confusion. :handshake:

5

This conversation captures something I’ve been grappling with from the C-suite perspective: platform engineering is becoming a strategic capability, not just an operational necessity.

The Business Case Has Changed Completely

Five years ago, when I presented our infrastructure roadmap to the board, it was a cost center discussion. “Here’s what we need to spend to keep the lights on.” Platform work was defensive—preventing outages, maintaining security, managing tech debt.

Today, when I talk about our platform strategy, it’s an enablement conversation. “Here’s how platform investments accelerate time-to-market and unlock new revenue streams.” Platform work is offensive—enabling business capabilities we couldn’t otherwise build.

That shift—defensive to offensive—is why the operator-to-product-builder identity change matters strategically.

Maya’s Question Goes Deep

Maya, you asked: “If everyone’s optimizing internal experiences, who’s obsessing over external customer value?”

This is the tension every CTO should be thinking about. Here’s my framework:

Platform teams enable leverage. One platform engineer who reduces deployment friction from 4 hours to 30 minutes multiplies the effectiveness of 50 product engineers. That’s 175 engineer-hours saved per week, redirected toward customer-facing value.

But you’re right—it only works if product teams are actually building the right things. Platform velocity without product judgment is just expensive chaos.

The answer isn’t “platform OR product obsession.” It’s recognizing they’re coupled. Your platform team should be asking: What business outcomes are we enabling? Not just: What developer friction are we reducing?

Luis’s Scale Question Is the Real Challenge

Luis asked about maintaining “customer intimacy” at scale. This is where most organizations fail.

At 40 developers, you can have platform engineers shadow developers. At 400 developers, that breaks down. You need different mechanisms:

  1. Instrumentation at scale - You can’t talk to everyone, but you can measure everything. Usage analytics, error rates, time-to-completion metrics become your scaled “listening” mechanism.

  2. Community advocates - Identify 10-15 highly engaged developers across teams to be your “platform advisory board.” They represent segments (backend, frontend, ML, mobile) and give you qualitative signal alongside quantitative data.

  3. Platform PM becomes critical - Keisha mentioned this. At scale, you can’t run a platform team without someone whose full-time job is understanding user needs, prioritizing competing demands, and saying no strategically.

The Long-Term Implications

Here’s what I think is happening at the industry level:

Software has eaten the world. Now platform engineering is eating software engineering.

As infrastructure becomes more complex (multi-cloud, Kubernetes, service mesh, observability, security), the “undifferentiated heavy lifting” that every company does grows. Platform teams exist to abstract that complexity so product engineers can focus on differentiated business logic.

But if platform teams still think like operators (“we manage infrastructure”), they build for themselves, not their users. The product mindset shift is necessary for platform engineering to deliver on its promise.

The Uncomfortable Truth

David’s question about “diluting what product means” is valid. But I think the real issue is different:

We’re realizing that most of what we call “engineering work” is actually product work.

Whether you’re building a customer-facing app, an internal platform, a design system, or a data pipeline—you have users, requirements, constraints, and tradeoffs. That’s product work.

The distinction isn’t “product team vs. engineering team.” It’s “teams that understand their users vs. teams that don’t.”

Platform teams that resist the product mindset are choosing not to understand their users. That’s not a philosophical stance—it’s an organizational liability.

David, thanks for starting this conversation. It’s surfaced something that every engineering org is navigating but few are naming explicitly. Would love to hear from folks on actual platform teams—how does this land for you?