Platform Teams Are Building Products for Developers—So Why Don't They Do User Research?

General
1

Platform Teams Are Building Products for Developers—So Why Don’t They Do User Research?

I need to tell you about a platform team that built something technically brilliant that absolutely nobody wanted to use.

Last year, I was consulting with a mid-size tech company on design systems. While I was there, their platform team spent 9 months building what they described as “the most elegant deployment system ever created.”

I sat in on their demo. The tech was genuinely impressive:

  • Beautiful microservices architecture
  • Elegant abstractions over Kubernetes complexity
  • Flexible configuration system supporting every edge case imaginable
  • Comprehensive API with OpenAPI specs

The platform engineers were so proud. They’d solved incredibly hard technical problems. The architecture was clean. The code was pristine.

Then they launched it to the engineering org.

Developers hated it.

What Went Wrong? They Never Talked to Users.

The platform team never once:

  • Interviewed developers about their actual deployment pain points
  • Observed developers going through existing deployment workflows
  • User-tested the CLI before shipping (the syntax was completely unintuitive)
  • Designed documentation for human consumption (it read like API reference material)
  • Created onboarding flows that matched how developers actually think

They built what they thought was elegant, not what developers needed.

Six months after launch, platform adoption was stuck at 35%. Developers were creating workarounds to avoid using it. The platform team couldn’t understand why their “technically superior” solution wasn’t being adopted.

Because they built for technical correctness, not user experience.

Compare This to a Platform Team That Got It Right

Now contrast that with another platform team I worked with:

Before writing a single line of code, they:

  • Ran 20 developer interviews asking: “Walk me through your last deployment. What was painful?”
  • Shadowed 5 developers during actual deploy workflows, taking notes on friction points
  • Created user journey maps showing where developers got stuck
  • Prototyped CLI commands and tested them with developers before implementation
  • Designed documentation structure based on how developers search for answers (not how engineers organize information)

After shipping their first golden path:

  • Weekly office hours where developers could give feedback
  • Quarterly usability testing sessions (“Try this new feature, we’ll watch and take notes”)
  • Developer NPS surveys with open-ended questions
  • Anonymous feedback channel for platform complaints

Results:

  • 85% platform adoption within 6 months
  • Developer NPS went from +12 (before platform) to +68
  • Support ticket volume down 55%
  • Developers actively requested new features instead of being forced to use the platform

The difference? Product discipline. User research. Developer experience as first-class concern.

Platform Engineering IS Product Management for Internal Tools

Here’s my thesis: If we’re serious about “platform as product,” then platform teams need actual product discipline—not just the metaphor.

What product teams would NEVER do:

  • :cross_mark: Build features without talking to users
  • :cross_mark: Ship UIs without usability testing
  • :cross_mark: Write documentation without considering findability and readability
  • :cross_mark: Ignore user feedback because “technically it works fine”
  • :cross_mark: Measure success by features shipped rather than user satisfaction

Yet I see platform teams do all of this routinely.

What “Platform as Product” Actually Looks Like

If you’re treating developers as customers, here’s what should be happening:

1. Discovery Before Development

Product teams: Research user needs, validate problems before building
Platform teams should: Interview developers, identify pain points, validate that golden paths solve real problems

2. Usability Testing

Product teams: Test prototypes with users, iterate based on feedback
Platform teams should: User-test CLIs, dashboards, and workflows before shipping. Watch developers try to use your tools without explaining anything.

3. Documentation as Product

Product teams: Treat docs as part of product experience
Platform teams should: Design documentation for humans. Information architecture. Visual hierarchy. Searchability. Not just “here’s the API reference.”

4. Feedback Loops

Product teams: User research, NPS surveys, feature requests, customer support data
Platform teams should: Developer interviews, NPS, office hours, feedback channels, observing how developers actually use (or avoid) your platform

5. Iterative Improvement

Product teams: Ship, measure, iterate based on data and feedback
Platform teams should: Golden paths aren’t “done”—they’re continuously improved based on developer usage patterns and feedback

The Question Nobody’s Asking

Here’s what I’m genuinely curious about:

Should platform teams literally hire designers, or are we expecting DevOps-turned-platform engineers to develop design thinking on their own?

Because here’s the thing: asking ops folks to suddenly care about:

  • Information architecture
  • Visual hierarchy in dashboards
  • Intuitive CLI syntax
  • Documentation findability
  • User journey mapping
  • Typography and readability

…feels like asking product managers to suddenly become SREs. Different skill sets. Different training. Different ways of thinking about problems.

When you build external products for customers, you wouldn’t dream of shipping without:

  • Product managers (prioritization, user research, roadmap)
  • Designers (UX, information architecture, visual design)
  • Engineers (implementation)

Why do we think internal platforms are different?

My Controversial Take

Platform teams should be cross-functional from the start: engineers + product managers + designers.

Not “eventually when we scale.”
Not “when budget allows.”
From day one.

Even if it’s:

  • 3 platform engineers
  • 1 product manager (50% time)
  • 1 designer (25% time)

That cross-functional mix ensures you’re building useful, usable platforms—not technically elegant solutions nobody wants.

The Design Expertise Platforms Actually Need

If you’re going to push back on “hire a designer,” let me be specific about what design brings:

CLI/Tool Usability

  • Command syntax that matches mental models
  • Error messages that actually help (not just stack traces)
  • Help text that’s discoverable and useful

Documentation Design

  • Information architecture (how docs are organized)
  • Navigation and findability
  • Visual hierarchy (headings, lists, code examples)
  • Onboarding flows and tutorials

Dashboard/Portal UX

  • Layout and navigation
  • Data visualization that actually communicates insights
  • Responsive design for different screen sizes

Developer Onboarding

  • First-run experiences that guide without overwhelming
  • Progressive disclosure (show complexity only when needed)
  • Visual walkthroughs for common workflows

You could train platform engineers to do this. But why reinvent expertise that already exists?

The Real-World Example: Spotify’s Backstage

Look at Backstage, Spotify’s open-source internal developer portal. It’s successful because:

  • Design system thinking: Consistent UI patterns, reusable components
  • Plugin architecture: Designed for extensibility with good DX
  • Documentation: Actually well-designed, not just comprehensive
  • Onboarding: Thoughtful first-run experience

Backstage didn’t happen by accident. It had design input from the start.

My Questions for This Community

  1. Has anyone embedded a designer on their platform team? What changed? Was it worth the investment?

  2. For platform engineers: What’s the hardest part of “thinking like a product person”? Is it research? Prioritization? UX? Something else?

  3. For product managers: If you joined a platform team, what would you change first?

  4. For everyone: Should developer experience be a specialized discipline, or can any engineer learn it?

I genuinely believe platform engineering’s success depends on embracing product discipline—not just talking about “platform as product” while building like traditional infrastructure teams.

What’s your experience?

2

Maya, you’re absolutely right and this hits home. Coming from product, I’ve been frustrated watching platform teams make the exact mistakes we figured out a decade ago in consumer product development.

Platform-as-Product Isn’t a Metaphor—It’s Literal

Your story about the “elegant but unused” platform is painfully common. I’ve seen it multiple times, and the pattern is always the same: engineers optimize for technical sophistication, not user value.

Here’s the framework I use when I consult with platform teams:

The Product Discovery Playbook for Platform Teams

Phase 1: Problem Discovery (Weeks 1-2)

  • Interview 15-20 developers across teams
  • Ask: “Walk me through your last 3 deployments. What slowed you down?”
  • Shadow developers during actual workflows
  • Map pain points by frequency and severity

Phase 2: Solution Validation (Weeks 3-4)

  • Create lightweight prototypes (CLI mockups, workflow diagrams)
  • Test with 5-7 developers: “Here’s how we’re thinking about solving X. Does this match your mental model?”
  • Iterate based on feedback BEFORE writing production code

Phase 3: MVP Shipping (Weeks 5-8)

  • Build minimal golden path for ONE high-frequency workflow
  • Ship to 10% of developers (early adopters)
  • Collect feedback, iterate

Phase 4: Scale and Iterate (Ongoing)

  • Measure adoption, satisfaction, usage patterns
  • Weekly feedback loops with users
  • Continuous improvement based on data

This is standard product playbook. But platform teams skip straight to Phase 3 without doing Phases 1-2.

Responding to Your Designer Question

Maya, you asked: Should platform teams hire designers or expect engineers to develop design thinking?

My answer: Yes to both, but phased.

Here’s how I’d structure it:

Team < 5 engineers:

  • Platform engineers develop basic product thinking (user interviews, feedback collection)
  • Borrow designer 20% time for critical UX decisions (CLI syntax, doc structure)
  • Have PM available for consultation even if not dedicated

Team 5-10 engineers:

  • Add dedicated product manager (full-time)
  • Designer embedded 50% time (focused on DevEx)
  • Product rituals: sprint reviews, user research sessions, roadmap planning

Team 10+ engineers:

  • Full cross-functional team: engineers + PM + designer
  • Treat platform team exactly like external product team

Why phased? Budget reality. You can’t justify dedicated PM + designer for a 3-person platform team. But you CAN justify scrappy product practices (user interviews, usability testing, feedback loops).

The Question You Should Ask Your Platform Team

Maya, here’s the diagnostic I use to assess if a platform team has product discipline:

Ask them: “How do you decide what to build next?”

Bad answers (engineer-driven):

  • “We saw a cool tool at a conference”
  • “This would be technically interesting to build”
  • “Our infrastructure needs this for scale”

Good answers (user-driven):

  • “We interviewed 15 developers and 12 mentioned deployment friction as their #1 pain point”
  • “Our developer NPS data shows documentation is the lowest-rated area”
  • “Support tickets show 40% are about environment setup—we’re building a golden path to reduce that”

Product teams wouldn’t build features without user research. Platform teams shouldn’t either.

The Uncomfortable Truth

Here’s what I’ve learned: Most platform engineers WANT to build valuable tools, but they’ve never been taught how to discover what’s valuable.

They default to technical intuition: “I would want this tool, so developers must want it too.”

That’s not malice. That’s lack of training.

Solution: send 2-3 platform engineers to a product management workshop. Have them shadow your product team for a month. Pair them with PMs. Teach them user research basics.

Many engineers can learn product thinking. But they need to be taught—it doesn’t emerge naturally from infrastructure expertise.

Your Backstage Example Is Perfect

Spotify’s Backstage succeeded because it had cross-functional DNA from day one. Not just engineers—product thinkers and designers shaped it.

Most internal platforms fail because they’re built by engineers, for engineers, judged by engineering standards (clean code, scalability) rather than user standards (does this make my job easier?).

Challenge to platform teams: Would you ship an external SaaS product without user research, usability testing, and design input? Then why ship internal platforms that way?

Developers are users. Treat them like customers.

3

Maya, this is exactly what I’ve been preaching internally! Six months ago, I embedded a product manager on our platform team, and it was a complete game changer.

The Results Speak for Themselves

Platform adoption jumped from 40% to 75% in four months. Not because the technology got better—we were already building solid infrastructure—but because we finally started building what developers actually wanted, not what we thought they needed.

The PM changed our entire approach. We started with user research: interviews with developers across all teams to understand their pain points. Turns out, our beautiful Kubernetes abstractions were solving problems developers didn’t have, while ignoring the friction in their daily workflows.

Process Changes That Mattered

We now run weekly office hours where any developer can give direct feedback to the platform team. We track feature requests in the same product management tool our product teams use. We do quarterly developer satisfaction surveys with actual NPS scores.

The cultural shift was the hardest part. Platform engineers had to stop thinking “we built it, they should use it” and start asking “what problems are developers actually facing?” Some engineers struggled with this—they wanted to work on interesting technical challenges, not listen to complaints about documentation.

Answering Your Question: Yes, We Added a Designer

To your specific question about embedding a designer—yes, we did this three months ago, and it transformed our documentation and CLI usability. The designer conducted usability testing on our CLI tools (actual developers trying to complete tasks while thinking aloud) and uncovered friction we never noticed.

Example: Our deployment CLI had seventeen flags. The designer helped us redesign it with sensible defaults and progressive disclosure—common tasks needed zero flags, advanced usage still available. Developer feedback went from “this is confusing” to “this just works.”

Documentation redesign was even bigger. Our docs were written for us (the builders), not for the users. The designer introduced documentation patterns from consumer products: quick-start guides, common recipes, troubleshooting decision trees. Onboarding time for new engineers dropped by 60%.

The ROI Was Clear

Adding a PM and designer to the platform team isn’t cheap. We went from a 6-person team to 8 (6 engineers + PM + designer). But the ROI showed up fast:

  • Platform adoption: 40% → 75%
  • Developer support tickets: down 45%
  • New engineer onboarding: 2 weeks → 3 days for first production deploy
  • Developer satisfaction (NPS): 12 → 58

When we showed these numbers to finance, they stopped questioning the headcount.

My Recommendation: Platform Teams Should Be Cross-Functional

Just like external product teams have engineers, PMs, and designers, platform teams should too. We’re building products for internal users—we should use product development best practices.

The challenge is recruiting. Finding platform engineers who understand product thinking is hard. Finding PMs who want to work on internal platforms is hard. But it’s worth it.

If your platform team is small and can’t afford dedicated PM/designer (Luis, I know you’re in this boat), borrow them part-time from product teams or train platform engineers in lightweight product practices. But as you scale, invest in dedicated product discipline.

Platform engineering is product engineering for developers. We need to walk the walk.

4

Maya, this isn’t just good practice—it’s how we justify platform engineering investment to the board.

Platform-as-Product Is How We Sell It Upstairs

When I present our platform engineering roadmap to the board, I don’t talk about Kubernetes or infrastructure. I talk about developer productivity, time-to-market, and engineering efficiency. The platform team is building a product that enables revenue-generating teams to move faster—that’s the business case.

If the platform doesn’t create measurable value for developers, it’s just expensive infrastructure overhead. Product thinking ensures we’re aligned with actual business outcomes, not just technical elegance.

My Mandate: Demonstrate Developer Satisfaction Quarterly

Our platform team has the same accountability as external product teams:

  • Quarterly developer NPS surveys (treated like customer satisfaction)
  • Monthly active usage metrics (% of engineers using platform features)
  • Support ticket volume trends (proxy for usability)
  • Time-to-productivity for new engineers (onboarding efficiency)

I review these metrics with the platform team every month, same as I review product metrics with product teams. If developer satisfaction is dropping or adoption is flat, we investigate like we would for any product issue.

The Best Platform Teams Have “Customer Obsession”

I’ve worked with platform teams at three companies. The successful ones had relentless focus on developer experience—they treated developers like customers. They ran user interviews, prioritized based on developer pain points, and measured satisfaction.

The unsuccessful ones built technically impressive systems that nobody used. They optimized for infrastructure elegance, not developer productivity. When I asked why adoption was low, the answer was always “developers don’t understand it” or “we need better documentation.” Wrong. The platform team didn’t understand their users.

Hiring Implication: Product Thinking Is Non-Negotiable

This discussion is shaping how I hire for platform teams. I’m looking for DevOps/SRE engineers who can think like product managers, not just infrastructure specialists.

Interview questions I now ask platform engineering candidates:

  • “How would you prioritize competing feature requests from different engineering teams?”
  • “How do you know if a platform feature is successful?”
  • “Describe a time you built something nobody used. What would you do differently?”

Traditional DevOps interviews focus on technical depth (Kubernetes, Terraform, observability). Platform engineering interviews need to assess product thinking, stakeholder management, and measurement literacy.

The Cost-Benefit of Adding PM + Designer

Keisha’s numbers are consistent with what I’ve seen: adding dedicated PM + designer to a platform team is expensive (20-30% headcount increase for small teams), but ROI is clear if you measure it properly.

The alternative is building features developers don’t want, maintaining unused systems, and dealing with constant friction—all hidden costs that don’t show up in headcount but destroy productivity.

I’d rather have an 8-person platform team with strong adoption than a 10-person team building infrastructure nobody uses.

My Question: How Do You Build Product Culture in Ops-Oriented Engineers?

Here’s my challenge: most experienced DevOps/SRE engineers built their careers on “keep systems running,” not “make users happy.” The psychological shift to product thinking is hard.

Some engineers resist it. They want to work on technical problems, not listen to developer complaints or write documentation. They see user research as “not engineering work.”

How do you create product culture in a team that’s never worked that way? Do you hire product-minded people and teach them infrastructure? Or hire infrastructure experts and teach them product thinking?

Keisha, Luis—curious how you’ve approached this cultural shift with your teams. What’s worked? What hasn’t?

5

Michelle, your question about building product culture hits home—this is exactly what I’m wrestling with on my team.

The Pragmatic Reality: Small Teams Can’t Afford Full Product Headcount

My platform team is five people. We don’t have budget for a dedicated PM or designer right now, but Keisha and Maya’s points about product thinking are spot-on. So we’re taking a scrappy, pragmatic approach.

Lightweight Product Thinking Without Full Headcount

Here’s what we’re doing:

  1. Platform engineers doing “lightweight” product work: User interviews with developers (monthly), feedback surveys (quarterly), feature request tracking in Linear
  2. Training investment: Sent two platform engineers to product management workshops—not to become PMs, but to learn how to think about users, prioritization, and measurement
  3. Part-time designer partnership: Borrowed one of our product designers 20% time to help with platform UX. She redesigned our documentation and helped us think through CLI usability.

Results from Documentation Redesign

Maya, to your point about documentation—this was our biggest win. Our docs were written by engineers, for engineers who already understood the system. Useless for actual users.

The designer helped us restructure docs around use cases, not technical architecture:

  • Instead of “Here’s how Terraform modules work” → “Deploy your first service in 10 minutes”
  • Instead of API reference dumps → Common recipes with copy-paste examples
  • Instead of long explanations → Visual diagrams and decision trees

Platform usage increased 30% within six weeks of the doc redesign. Turns out, people will use tools if they can figure out how they work.

The Product Culture Challenge

Michelle, to answer your question about building product culture in ops-oriented engineers—it’s a journey, and I’m not claiming victory yet.

What’s working:

  • Exposure: Having engineers attend user interviews. Hearing developers say “this is confusing” or “I didn’t know this existed” is more powerful than any training.
  • Shared pain: One of our platform engineers spent a week embedded with an app team, using our platform as an end-user. He came back with fifteen usability issues we’d never noticed.
  • Celebrate adoption, not features: Changed how we measure success. Used to celebrate “shipped new Terraform module.” Now we celebrate “30% of teams adopted golden path for database setup.”

What’s hard:

  • Some engineers genuinely prefer deep technical work over user interaction. That’s okay—not everyone needs to be user-facing. But someone on the team needs to own the “developer customer” relationship.
  • Product thinking takes time away from building. Interviews, surveys, documentation—these aren’t “shipping features.” You need to protect this time or it gets deprioritized when deadlines hit.

When Do You Hire a Dedicated PM?

Keisha, I’d love your perspective: at what team size or maturity did you justify hiring a dedicated PM for the platform team?

Right now, I’m doing PM-like work (roadmap, prioritization, stakeholder management) on top of my engineering director responsibilities. It’s not sustainable, but I can’t justify dedicated headcount yet.

Is there a signal I should watch for—platform team size, number of internal customers, breadth of platform surface area—that indicates it’s time to hire a PM?

Maya’s Original Point Stands

Coming back to Maya’s original post: platform teams are building products. The more we embrace product discipline—user research, usability testing, documentation design, measurement—the more successful we’ll be.

You don’t need a full product team from day one, but you need product mindset. And yes, that’s a shift for traditional DevOps/SRE folks. It’s a shift I’m still learning to make.