The Product Coaching Playbook I Use With Every Team

I did not set out to become a product coach. I set out to be a product manager who could not stop helping other product managers get better.

At Pivotal Labs, coaching was the job. You shipped software and you transferred capability to the client team. The product was the team, not just the software. That framing rewired how I thought about product leadership. The question stopped being "how do I make this product better?" and became "how do I make this team better at making products?"

Since then, I have coached over 150 PMs across enterprise healthcare, defense, startups, and nonprofits. The contexts vary enormously. The playbook does not.

The five moves

I do not arrive with a curriculum. I arrive with a sequence of moves that I adjust based on what I find. The moves are always the same. The emphasis changes.

1. Assess

Before I coach anything, I need to understand what the team already knows and what they think they know. Those are different things.

At Kaiser Permanente, I assessed 9 experience groups across 5 dimensions -- product roles, organization, planning, discovery, and delivery -- using a maturity rubric. Most groups scored low. But the gap between their self-perception and reality was more useful than the score itself. Teams that thought they were doing discovery were actually doing requirements gathering with a different name. Teams that thought they had empowered PMs actually had PMs who took orders from the loudest stakeholder.

The assessment is not a judgment. It is a mirror. It shows the team where they actually are so they can decide where to go.

2. Listen

This is where most coaches fail. They arrive, assess, and immediately start prescribing. They skip the step where you learn why things are the way they are.

At the defense portfolio, the teams had been cycling for six months with no clear output. An outside observer might have diagnosed a capability problem. After listening, I realized it was a confidence problem. The teams were technically capable. They were afraid of deploying to production because the operational acceptance process was unpredictable and punitive. The practice gap was real, but the fear was the actual blocker.

If I had started with process improvements, I would have been optimizing the wrong thing. The first coaching intervention was navigating the operational acceptance path so the team could see that deploying was possible. Everything accelerated after that.

Listen long enough to understand the real constraint. It is almost never the one the team names first.

3. Mirror

Once I understand the landscape, I mirror it back to the team. I name what I see in plain language.

I wrote a candid memo to a coaching lead at Kaiser. It named the cultural barriers: a HiPPO culture where the loudest executive determined what got built. 144 fragmented OKRs with no cascade. Annual planning that locked teams into stale commitments. Missing user analytics. Shared services bottlenecks.

The memo was uncomfortable. Several of the findings were things people had been thinking but not saying. Saying them out loud, in a document, with specific evidence, changed the dynamic. The problems were no longer opinions. They were facts.

Mirroring is not criticism. It is clarity. Teams cannot fix what they cannot see. The coach's job is to make the invisible visible.

4. Scaffold

This is the building phase. I put structure in place that helps the team practice new behaviors without me having to be in the room every time.

At Kaiser, the scaffolding was extensive: four Quick Start Guides that taught the basics in one-page formats. A 40-resource learning hub. An OKR cascade framework. PM Community of Practice with office hours. Templates for roadmaps, user personas, service blueprints, and story writing.

None of this was proprietary. It was practical. The user story guide taught vertical slices and Given/When/Then acceptance criteria. The retro guide had a facilitation flow with action items. The OKR guide showed how to connect enterprise metrics to squad-level key results with worked examples.

Scaffolding works when it meets the team at their level and raises the floor. The guide for writing user stories is useless for a team that does not know what a story is. It is essential for a team that writes stories poorly and knows it. The scaffold has to match the gap.

5. Release

The hardest move. The coaching has to end. The team has to carry the practices forward without me.

This is why scaffolding matters more than direct coaching. If the team depends on the coach being in the room, the coach has failed. If the team depends on the tools and habits the coach built, the coach has succeeded.

At the defense portfolio, I knew the coaching had landed when the team ran their own Discovery & Framing for the next project without asking me how. They used the same process I had taught them, adapted it to their context, and produced a better result than the first time. They did not need me. They needed the practice.

At Kaiser, the learning hub outlasted my engagement. Teams continued to use the Quick Start Guides and the OKR framework after I left. The PM Community of Practice kept meeting. The content was the scaffold. The habit was the change.

What coaching is not

Coaching is not mentoring. A mentor shares their experience and lets you learn from it. A coach changes your behavior.

Coaching is not consulting. A consultant tells you what to do. A coach helps you learn how to decide what to do.

Coaching is not training. Training transfers knowledge. Coaching transfers capability. The difference is whether the person can do the thing when you leave.

The best coaching I have done looks like nothing happened. The team is just better. They make sharper decisions, write clearer stories, run tighter retros, and ship with more confidence. They do not attribute it to coaching. They attribute it to themselves. That is the point.

One more thing

I built a PM skill matrix based on spheres of influence -- self, team, org -- because the best coaching I have done has focused on expanding a PM's influence, not checking boxes. If you are trying to figure out where to invest in your team's growth, it might help.

---

I coach product teams that want to get better at the actual work, not the ceremony around it. If that sounds like what your team needs, reach out.