The Platform PM Anti-Pattern: We Converted Our Project Manager Without Training Her. 6 Months Later, Our Platform Has 8% Adoption

General
1

I need to confess something that’s been eating at me for six months: We promoted our best project manager to lead our internal developer platform, and we completely set her up to fail.

Eight percent. That’s our platform adoption rate right now. Engineers are building workarounds instead of using what we built. Our PM spends her days triaging Jira tickets instead of talking to developers about what they actually need.

Here’s what happened.

The Decision

Last year, our CTO made the call to build an internal developer platform. Smart move—our 80-person engineering org was drowning in inconsistent deployment processes, bespoke monitoring setups, and everyone reinventing authentication. We needed golden paths.

We had a fantastic project manager who’d been shipping customer-facing features for three years. She knew our systems, had great relationships across engineering, and always delivered on time. “Perfect,” we thought. “Let’s have her lead the platform team.”

We didn’t train her. We didn’t pair her with anyone who’d done platform PM work before. We just changed her title and expected her to figure it out.

The Symptoms

Six months in, here’s what we’re seeing:

Engineers building their own solutions anyway. Our platform offers CI/CD pipelines, but three teams have custom GitHub Actions workflows because “the platform doesn’t fit our use case.” Our observability stack exists, but teams are still spinning up their own Datadog instances.

Roadmap driven by whoever shouts loudest. Instead of ruthlessly prioritizing the 80% use case, we’re saying yes to every edge case request. The backlog is 200+ tickets deep.

No product strategy, just project management. Every standup is “what shipped this week” and “what’s the ETA on X.” There’s no discussion of adoption metrics, no user research with engineers, no iteration based on what’s working vs. what’s not.

The PM is miserable. She feels like she’s failing, and honestly, she’s right—but it’s our failure as leadership, not hers.

What I Learned Too Late

Platform product management is not project management with a different customer. It’s not even the same as customer-facing product management. It’s its own discipline.

Project managers track deliverables. Did we ship the feature on time? Did we hit the sprint goal? That’s the job.

Customer-facing PMs optimize conversion funnels. They run A/B tests, measure MAU and retention, talk to external users who pay money.

Platform PMs are different. They have to:

  • Treat internal engineers as customers (who don’t think of themselves as customers)
  • Measure indirect metrics like “time saved across all teams” and “reliability improvements”
  • Drive adoption when there’s no monetary incentive to use the platform
  • Navigate political dynamics where teams want autonomy, not standardization
  • Balance “let teams move fast” vs “enforce consistency for long-term scalability”

I just read research from Platform Engineering that says 45% of platform teams cite developer adoption as their top challenge. Not technical complexity—cultural resistance.

And you know what they identified as a root cause? Organizations that “convert project managers to platform product managers without proper enablement and training.” We’re literally a case study in the anti-pattern.

The Real Cost

Here’s what this mistake cost us:

  • Six months of low adoption while engineers built workarounds (now we have tech debt in two directions)
  • Morale hit for the PM, who feels set up to fail
  • Engineering team frustration with a platform that doesn’t meet their needs
  • Lost opportunity cost of what we could have built with better product thinking

If we’d invested $50K in proper training, coaching, and maybe an external consultant up front, we’d have saved ourselves months of spinning wheels.

What We’re Doing Now

We’re not giving up on our PM—she’s incredibly talented, just needed enablement we didn’t provide. Here’s the recovery plan:

  1. Brought in a platform PM consultant (8-week engagement) to coach and model the discipline
  2. Started weekly product coaching 1:1s focused on discovery, research, and prioritization frameworks
  3. Established new success metrics: adoption rate by team, time-to-first-integration, developer satisfaction scores
  4. Shifted from “build everything” to “nail the 80% use case”—we’re actually saying no now
  5. User research with engineers: treating them like customers, understanding their workflows, iterating

The Question

I can’t be the only one who’s made this mistake. Has anyone else promoted a project manager or customer-facing PM into a platform role without proper support?

How did you fix it? What training or frameworks actually worked? What would you do differently?

And for folks who’ve been successful platform PMs—what’s the one thing you wish leadership understood about your role that they don’t?

2

Oh wow, David—I lived this exact pattern from the design systems side, and I’m cringing reading your post because it’s like looking in a mirror.

My Version of Your Story

Two years ago, I built a design system that nobody used. And I mean nobody. We had this beautiful component library, exhaustive documentation, Storybook with every variant documented. Adoption? Maybe 15% if I’m being generous.

The mistake was the same as yours: we treated the design system like a deliverable instead of a product.

I was so focused on the craft—perfect tokens, bulletproof accessibility, every edge case covered—that I never once asked designers, “What would actually make your job easier?” I just assumed they’d be thrilled we solved the problem for them.

They weren’t thrilled. They built their own one-off components because our system “didn’t fit their use case” (sound familiar?).

What Changed

I had to completely reframe the work. Here’s what actually moved the needle:

Started treating designers as customers. That meant user research—shadowing designers, watching where they got stuck, asking what pain points the system could solve. Turns out they didn’t want 47 button variants; they wanted better handoff between design and dev.

Measured adoption as a product metric. Before: “Did we ship the date picker component?” After: “How many teams actually use it? What’s their satisfaction score? What’s blocking the teams who don’t use it?”

Iterated based on feedback. Instead of building everything upfront, we focused on the highest-pain components first, shipped scrappy versions, then improved based on usage.

Accepted that platform work requires product thinking, not just craft. I’m a designer who had to learn PM skills. Your PM is a project manager who needs to learn platform PM skills. Same pattern.

The Question I’m Curious About

You mentioned you’re now measuring adoption rate, time-to-first-integration, and developer satisfaction. That’s great! But here’s what I learned the hard way:

How are you balancing “serve the 80%” vs “avoid alienating the 20%”?

Because the teams building workarounds are often your most vocal critics. If you ignore them to focus on the majority, they get louder and more entrenched in their custom solutions. But if you try to serve them, you end up with 200 tickets like you mentioned.

We eventually landed on a model where we explicitly tiered our support:

  • Tier 1: Core use cases we fully support and maintain
  • Tier 2: Extended use cases with community support
  • Tier 3: “You’re on your own, but we won’t block you”

The transparency helped. Teams knew where they stood instead of feeling like every request was theoretically supported but nothing actually worked for them.

Curious if you’ve thought about something similar for your platform? :thinking:

3

David, I appreciate your honesty here. This is a very common pattern in financial services, and I’ve seen it fail twice in my own career—once with a platform team, once with a DevOps transformation. Both times, the root cause was the same: leadership didn’t understand that platform PM is a specialized discipline that requires specific enablement.

Why This Keeps Happening

The mistake is understandable. On paper, it makes sense:

  • “Our best project manager understands our systems” ✓
  • “She has great relationships with engineering” ✓
  • “She ships on time” ✓

What’s missing is recognizing that platform product management requires a completely different skill set. It’s like promoting a talented backend engineer to lead security—there’s some overlap, but if you don’t invest in training, you’re setting them up to fail.

What Actually Worked for Us

The second time we built a platform team, we did it differently:

Hired an external platform PM with experience. Someone who’d done this before at a company with successful platform adoption. Cost: $180K/year, which felt expensive until we calculated the cost of our previous failed attempt (probably $1M+ in wasted engineering time).

Paired the external hire with an internal “platform PM apprentice.” We took a senior engineer who wanted to transition into product management and had her shadow the external PM for six months. This created knowledge transfer and a succession plan.

Invested in structured training. We sent both of them to workshops on product discovery, stakeholder management with technical audiences, and measuring indirect metrics. Not cheap, but way less expensive than six months of 8% adoption.

Created a 90-day onboarding plan specific to platform PM work:

  • Week 1-2: Shadow engineers, understand their workflows and pain points
  • Week 3-4: Map out stakeholders and conduct listening tours
  • Week 5-8: Define success metrics and establish feedback loops
  • Week 9-12: Ship first iteration of one thing and measure adoption

The Skills Gap

You asked what training actually worked. Here’s what our platform PM needed to learn that wasn’t part of her engineering background:

  1. Product discovery with internal customers (engineers don’t think of themselves as customers)
  2. Stakeholder management where your “users” can also ignore you and build their own solution
  3. Measuring indirect metrics (time saved, reliability improvements, cognitive load reduction)
  4. Adoption strategy when there’s no monetary incentive to use your platform
  5. Saying no ruthlessly to serve the 80% use case (engineers will push back hard on this)

The last one is especially tough in engineering culture, where autonomy is sacred and “let me build it my way” is the default.

A Question for You

Does your PM have any engineering background? Even a technical degree or some coding experience?

I ask because in my experience, platform PMs with engineering empathy (even if they’re not actively coding) have a much easier time earning trust with developers. They can speak the language, understand the tradeoffs, and push back when engineers propose solutions that are technically impressive but operationally unsustainable.

If your PM doesn’t have that background, I’d recommend pairing her with a technical architect or senior engineer who can translate between “product thinking” and “engineering constraints.” That partnership can bridge the gap while she builds technical fluency.

The Investment Math

You mentioned $50K in training would have saved six months. I’d actually argue the real cost is higher:

  • 6 months × 5 platform engineers × $200K average salary = $500K in platform team cost
  • 6 months × 75 engineers waiting for a working platform × 10% productivity loss = $750K+ in opportunity cost

Suddenly that $180K external hire + $50K training investment doesn’t look so expensive, right?

The hard truth: platform teams are too important to staff with converted roles and hope for the best. You need specialized skills from day one, whether that’s hiring externally or investing heavily in enablement.

Good luck with the recovery. Your plan sounds solid—especially bringing in a consultant to model the work. That’s exactly what we should have done the first time around.

4

David, I want to reframe something important here: This is an organizational design failure, not an individual failure.

You’re taking accountability, which is admirable. But the real problem isn’t that you promoted the wrong person—it’s that your organization (like most) systematically underinvests in platform roles because leadership doesn’t see internal customers as “real” customers.

Let me explain what I mean.

The Systemic Issue

When we build customer-facing products, we staff appropriately:

  • Product manager with relevant experience? Check.
  • User research budget? Check.
  • Clear success metrics tied to business outcomes? Check.
  • Executive sponsorship and quarterly business reviews? Check.

When we build internal platforms:

  • Product manager with platform experience? “Can’t we just promote someone?”
  • User research with engineers? “Just ask them in Slack.”
  • Success metrics? “Uh… did we ship the thing?”
  • Executive sponsorship? “The CTO mentioned it once.”

This double standard sets platform teams up to fail before they even start. And then we wonder why adoption is low.

What I’ve Learned Leading Platform Teams

I’ve scaled engineering orgs from 25 to 80+ people twice now, and here’s what I know: Platform teams need dedicated, experienced product management from Day 1, not after six months of struggling.

Here’s my approach:

1. Treat Platform PM as a Specialized Discipline

I hire platform PMs the way I’d hire a security engineer or a data scientist—looking for demonstrated experience in that specific domain. The skills are transferable from other PM roles, but not without intentional enablement.

If I’m converting someone internally, I build a 6-month enablement plan with clear milestones:

  • Month 1-2: Shadow an experienced platform PM (external consultant if needed)
  • Month 3-4: Lead discovery for one small platform feature, with coaching
  • Month 5-6: Own roadmap for a bounded platform area, measured on adoption

No one just gets the title and figures it out. That’s not fair to them or the organization.

2. The Skills Matrix

Platform PMs need a blend of three capabilities:

Technical Empathy (not the same as being technical): Understanding engineering workflows, constraints, and what “easy to use” means for developers

Product Thinking: Discovery, ruthless prioritization, measuring what matters, iterating based on data

Change Management: Driving adoption when your “customers” have the power to ignore you and build their own solution

Most customer-facing PMs have #2. Most project managers are weak on #1 and #3. That’s why the conversion fails without training.

3. The Adoption Playbook

Here’s what actually drives platform adoption in my experience:

Treat your first 10 teams as beta customers. Don’t try to serve everyone at once. Pick 10 teams with diverse use cases, partner deeply with them, iterate based on their feedback. Nail that before expanding.

Measure time-to-value, not just adoption. A team that integrates with your platform but still maintains their old solution isn’t really adopted. Measure “time from onboarding to fully migrated and old solution decommissioned.”

Tie platform success to team-level metrics. If your platform is supposed to improve deployment frequency or reduce incidents, measure those outcomes for the teams using the platform vs teams not using it. That’s your business case.

Build forcing functions carefully. At some point, you need to deprecate old solutions to drive adoption. But do this after you’ve proven value with early adopters, not before.

Don’t Be Too Hard on Yourself

You mentioned this has been “eating at you.” I get it. But I’ve seen VPs at companies 10× your size make this same mistake. We optimize for speed (“just promote someone and get started”) over enablement (“invest in proper setup”).

The fact that you’re course-correcting now—bringing in a consultant, establishing real metrics, coaching your PM—means you’re ahead of most organizations that just let the platform quietly die and pretend it never happened.

My Question for You

You said you’re building a recovery plan. What does success look like in 90 days?

I ask because one trap I’ve seen teams fall into is trying to fix everything at once. They pivot from “build everything for everyone” to “complete overhaul of strategy, metrics, roadmap, and adoption approach.”

My advice: Pick one team. Nail their use case. Measure their satisfaction and ROI. Use that as proof of concept for the next team.

Small wins compound. Trying to boil the ocean when morale is already low just makes things worse.

What’s your “one team, one use case” target? That’s where I’d focus.

5

Wow. Thank you all for these perspectives—I’m simultaneously validated (it’s not just us!) and humbled (we really should have known better).

The Reframe That Hit Hard

Keisha, your reframe as “organizational design failure” really landed. You’re right that we have a double standard: customer-facing products get experienced PMs with research budgets, but internal platforms get “figure it out with someone we promote.” That’s on leadership, not on our PM.

Luis, your investment math is brutal but accurate. We definitely lost more than $50K—probably closer to your $750K estimate when you factor in opportunity cost and the teams that built workarounds we now have to support.

Maya, your design systems parallel is so spot-on it hurts. We’re absolutely struggling with the “serve the 80% vs alienate the 20%” balance. I love your tiered support model—we’re going to steal that framework.

What We’re Actually Doing (90-Day Focus)

Keisha, you asked what success looks like in 90 days. Great question. Here’s our “one team, one use case” plan:

Target team: Our payments squad (6 engineers). They’ve been the most vocal about platform pain points, which makes them perfect beta customers—they’ll give honest feedback.

One use case: CI/CD pipeline for service deployment. Right now they’re using custom GitHub Actions that break every other week. If we can migrate them fully and prove it saves them time (measuring before/after), that’s our proof of concept.

Success metrics:

  • Payments team migrated to platform CI/CD: 100% of their services
  • Time-to-deploy improved by 30%+ (measuring their actual cycle time)
  • Developer satisfaction score: 7+ out of 10 from the payments team
  • Old GitHub Actions decommissioned (not just “new solution exists alongside old one”)

Then we use payments as a case study to convince the next two teams.

What We’re Changing for Our PM

Based on everyone’s advice:

Pairing with technical architect (Luis, great call). Our PM doesn’t have an engineering background, so we’re pairing her with our senior platform engineer for all discovery conversations. He translates “engineering constraints” and she brings product thinking. That partnership is already helping.

Structured coaching on platform PM competencies:

  • Week 1-4: Product discovery with internal customers (our consultant is modeling this with payments team)
  • Week 5-8: Adoption strategy and change management
  • Week 9-12: Measuring indirect metrics and communicating ROI

Tiering our roadmap (stealing Maya’s framework):

  • Tier 1: CI/CD, observability, secrets management (we own these)
  • Tier 2: Database migrations, feature flags (community support)
  • Tier 3: Custom deployment workflows (you’re on your own, but we won’t block you)

This transparency should help us say no without engineers feeling like we don’t care about their use cases.

The Training Question

I asked about training programs for platform PMs, and I’m realizing there aren’t many established ones (unlike, say, Pragmatic Institute for customer-facing PM).

Has anyone found good resources? We’re cobbling together:

  • “Team Topologies” for platform team patterns
  • Cortex’s guide on platform-as-product thinking
  • Internal coaching from our consultant

But would love recommendations for workshops, communities, or certifications specific to platform PM work.

The Bigger Lesson

The meta-lesson for me: Specialized roles need specialized enablement. Seems obvious in retrospect, but when you’re moving fast and trying to staff a new team, it’s easy to think “just promote our best person and they’ll figure it out.”

They won’t. Not without support. And that’s on leadership to provide.

Thanks again for the honest feedback and the specific tactical advice. I’ll report back in 90 days on whether we actually hit our metrics with the payments team. :crossed_fingers: