Develop product manager skills systematically using a competency framework and structured coaching. Creates high-impact product leaders through consistent feedback and skill-building. Trigger on: 'coaching PMs', 'developing talent', 'PM feedback', 'competency gaps', 'leadership development', 'one-on-ones'.
Most companies say they care about developing their product managers and then do almost nothing about it. Coaching gets delegated to HR, compressed into annual reviews, or treated as something that happens if you have time. Meanwhile, PMs plateau, make the same mistakes repeatedly, and teams waste weeks unraveling poor decisions that better coaching would have prevented.
This skill is built on the insight that coaching is the primary job of product leaders, not something you do in addition to your job. The best product organizations treat coaching the same way engineering treats code review: structured, frequent, and part of how work gets done.
You'll learn to define what good looks like explicitly (most coaching fails here—you ask PMs to improve without clarifying what excellence looks like), diagnose where a PM actually is against that standard, create a shared vision of growth, build a development plan that's specific not generic, and follow up relentlessly so improvement sticks.
Use this skill whenever you're responsible for developing product managers. It's especially valuable when:
This is where most coaching fails. You tell a PM "get better at stakeholder alignment" without defining what that means. Does it mean communicating more? Communicating earlier? Making better decisions with stakeholders? Including stakeholders in decision-making? The PM doesn't know, so nothing changes.
Create an explicit competency framework for product managers in your organization. This includes:
For each competency, define what excellence looks like (level 3-4) and what needs improvement (level 1-2). Be specific. "Communication" is vague. "Communication means writing strategy documents that get stakeholder buy-in with minimal clarification, running meetings where silent participants actually speak, and explaining decisions in ways the audience understands" is actionable.
This framework becomes your coaching reference. When you coach, you're helping PMs move up this competency ladder, not moving some vague "goodness needle."
Don't assume a PM's weakness is lack of skill when it might be lack of understanding. Bloom's taxonomy gives you a diagnostic framework:
When a PM struggles with stakeholder alignment, diagnose: Do they not know what good alignment looks like (remember)? Do they not understand why stakeholders matter (understand)? Can they analyze stakeholder concerns but fail to apply that analysis to decisions (apply)? Can they recognize patterns but judge trade-offs poorly (analyze)?
Your coaching changes based on diagnosis. If they don't know what good looks like, your job is teaching. If they can analyze but judge poorly, your job is helping them learn how to make better trade-offs.
In your first coaching conversation with a PM, don't jump to what they're doing wrong. Get aligned on what right looks like. "Here's what I think excellent product strategy means in our context [share framework]. Here's what I see you doing well [specific, observed evidence]. Here's where I think you're below where you need to be [specific gap]. Do you agree with where you sit on this framework?"
This conversation sets the stage. You're not imposing standards—you're inviting them to see themselves against an explicit standard. Many PMs will self-assess lower than they actually are. Some will disagree with the framework itself ("I don't think competitive analysis is important"). Address that disagreement now, not after months of trying to coach them toward a standard they don't accept.
Once you've diagnosed where a PM is and aligned on standards, create a vision together of where they're growing. Not "be better at strategy" but "you're going to write quarterly strategy briefs that help the team understand our three bets and how they compound. In six months, I want leadership reading your briefs and not needing follow-up conversations."
The vision should be:
Write this down. Revisit it regularly so you both know if you're making progress.
The development plan is where coaching becomes real work. It should include:
Coaching conversations: Weekly or bi-weekly 1:1s focused specifically on growth. Not status updates—time devoted to skill development. Structure these around current projects: "Let's look at your stakeholder alignment on the Q2 roadmap. Here's where I see gaps. Let's talk through how you'd approach this differently."
Assignments and practice: Real work that stretches the PM into the area they're developing. "For next month's vendor evaluation, I want you to lead the competitive analysis. Let me review your draft and give feedback before it goes to stakeholders."
Feedback cycles: Feedback delivered soon after the event. Not "you struggled with stakeholder communication" six months later. But "I sat in your strategy session with engineering. Here's what happened well, here's where alignment broke down, here's what I'd do differently."
Reading/reflection: Specific resources that teach the skill. Not random "here's a good product book." But "read this chapter on competitive strategy, then tell me how it changes your thinking about our positioning."
Reverse coaching: Have the PM teach you or others. "You're getting really strong at pricing strategy. Can you walk the team through your thinking on the enterprise pricing model?" This forces them to articulate frameworks clearly.
Accountability: Review progress regularly. Monthly: "Are we seeing improvement? What's blocking progress? Do we need to adjust the plan?"
This is where most coaching dies. You create a plan, have a few good conversations, then everyone gets busy and the PM falls back into old patterns. You have to follow up.
Every week, think about how this PM is doing on their growth area. Did they take the action you discussed? Did they implement the feedback? Are you seeing behavior change? Call it out: "I see you applying the competitive analysis framework to the new feature evaluation—that's exactly what we worked on. What made the difference?"
Celebrate progress publicly. "In the all-hands, mention that Sarah's stakeholder alignment has visibly improved—she got buy-in from the tough customer group." This signals that growth is valued.
When they backslide (and they will), don't shame them. "I notice the last strategy brief didn't have the competitive landscape analysis we discussed. What happened?" Maybe they forgot. Maybe something took priority. Maybe they didn't actually understand the framework. Address the actual reason.
Not all PMs develop the same way. Some need more structure, some more autonomy. Some need permission to take risks, some need guardrails. Adjust your coaching:
Your coaching method should match their readiness and the gaps.
Not every gap is a coaching problem. Coaching works for skills. It doesn't work for:
Your coaching framework and plan should include:
Competency Framework (2-3 pages):
Individual Coaching Plan (2-4 pages):
Coaching Conversation Notes (ongoing):
Feedback for Growth (after key moments):
Scenario: Davit is VP of Product at Quantum Leap, a B2B analytics company. He has four product managers reporting to him. One, Keiko, is a solid performer with strategic chops but struggles with execution and detail—she misses important edge cases, ships with incomplete spec work, and her team says she's sometimes unclear about priorities. Davit wants to develop her into a director-level PM. He's creating a coaching plan.
Step 1 - Competency Framework (excerpt):
Quantum Leap PM Competencies:
For Execution, excellence means:
Step 2 - Diagnosis (Bloom's Taxonomy):
Davit observes:
Diagnosis: This isn't a knowledge gap. It's an execution habit gap. She needs practice and feedback cycles, not teaching.
Step 3 - Aligned on Standards:
Davit: "I want to talk about execution. You're strategically sharp, but I see specs going out that are missing edge cases, and your team tells me priorities aren't always crystal clear. Here's what I think good execution looks like: [shares framework]. I see you at level 2 here—you understand what's important but aren't consistently hitting it. Does that match how you see it?"
Keiko: "Yeah, I know my specs could be more detailed. I get impatient to ship and feel like I'm over-engineering sometimes."
Davit: "That's one view. The other view is that clarity upfront saves rework later. You're fast and I don't want to slow you down. But I do want to help you be fast and clear. What would help?"
Keiko: "More structure probably. And feedback on my specs before they go to engineering."
Step 4 - Shared Vision:
Davit: "Here's what I'm imagining. In three months, your specs are clear enough that engineering ships the first time without clarifications. Your team knows priorities clearly because you've documented them and revisited them weekly. You've kept your speed. You're just adding a layer of clarity that actually makes things faster because there's less rework. Does that sound like the right direction?"
Keiko: "Yeah, that's the goal."
Step 5 - Development Plan:
Activities:
Step 6 - Follow Up:
Week 1: Keiko submits spec draft for feedback. Davit notes: "The core flow is clear. Missing: what happens if user has >100 charts to organize? What's the performance assumption?" Keiko revises.
Week 3: Keiko creates first quarterly priority document. Davit reviews. Good strategic framing, good prioritization, slightly unclear on Q3 scope. Feedback: "This is the direction. For Q3, can you say explicitly: 'We're shipping X and Y, we're not doing Z because [reason]'? Clarity on what we're NOT doing helps everyone."
Week 5: Engineering lead mentions specs have been clearer last month. Davit tells Keiko: "I heard from engineering that your recent specs have been more detailed and they're shipping faster because of it. That's the direction we wanted."
Month 2: Keiko is still rough on one feature spec. Davit: "This one's unclear on the filtering logic. I know you want to ship fast. What if we spend one more day on the edge cases here?" They work through it together. Keiko sees how depth now prevents rework later.
Month 3: Reassessment. Specs are notably clearer. Priority documents are being used by the team to say no to things. Keiko says: "I realized the upfront work saves me time overall because I don't spend weeks reworking." Davit: "Exactly. You've moved from fast to fast-and-clear. Next level: can you teach the other PMs how you're thinking about edge cases?"
Step 7 - Adjust for Growth:
As Keiko improves, Davit shifts coaching. Instead of reviewing every spec draft, he spot-checks. Focus moves to: How is she thinking about multi-quarter roadmap? Is she ready to mentor newer PMs? Can she take on larger scope?
A PM doesn't want to be coached: This is a real problem. Coaching requires trust and openness. If a PM resists, first try to understand why. "I sense you're not interested in this development conversation. What's going on?" Maybe they feel criticized instead of supported. Maybe they don't agree with the framework. Maybe they're burned out. Address the real issue, not the surface resistance.
You lack credibility as a coach: You can't have been a PM 15 years ago and coach modern PMs on digital products effectively. Either develop credibility (work in the role yourself, stay deeply involved) or bring in external coaching. Don't pretend to know things you don't.
The PM's weakness is something you're also weak at: Great. Coach them anyway. "I also struggle with writing clear specifications. Here's what I'm learning..." This builds vulnerability and shows that growth is continuous. You're coaches together, not you perfect and them flawed.
The PM plateaus and stops improving: This could be a mindset issue. "Do you still want to grow here? Because I'm not seeing the improvement we discussed." Could be they hit their ceiling. That's okay—help them excel at their level rather than pushing for promotion. Could be external stress. "How are you doing? Is something blocking your focus right now?"
Multiple PMs have similar gaps: This suggests a framework or hiring issue, not individual coaching issues. Maybe your onboarding is weak, maybe you're hiring for the wrong traits, maybe your culture doesn't value execution. Address the system, not just the individuals.
A PM improves in coaching but reverts when you're not watching: They haven't internalized the behavior. They're performing for feedback, not actually changed. Coaching needs to continue until they own the change. "I see you've been slipping back on spec detail. What happened?" Help them understand what triggers the backslide and plan to handle it.