What I've Learned Mentoring Hundreds of Product Managers

A PM at Amazon was technically sharp, well-prepared for every meeting, and slowly losing the trust of their engineering team. Smart person, working hard, getting worse results. The problem: every conversation was a pitch. “Here’s what we should build and why.” The engineers felt talked at, not worked with.

I didn’t tell this PM to be less prepared. I told them to spend their next sprint doing nothing but asking questions. No proposals. No roadmap updates. Just: “Help me understand how this system works.” “What’s the hardest part of your job right now?” “What would you build if you had a free sprint?”

Two weeks later, the same engineer who had been quietly disengaging in meetings walked over to the PM’s desk to propose a feature idea. Not because the PM had changed their roadmap — because the PM had changed their posture. The engineer felt heard for the first time.

That shift — from performing expertise to practicing curiosity — is the most common thing I teach. I’ve mentored hundreds of PMs across every company I’ve worked at. Starting at Ford, where I rolled out product management practices for teams that had never worked with a PM before, through Amazon and Venmo where I coached senior PMs and first-timers alike. It’s never been a side activity — it’s how I work. Every team I join, I’m teaching while I’m building.

The “Know It All” Trap

New PMs walk into their first role terrified of looking incompetent. They’ve read the books. They’ve memorized the frameworks. They have opinions about prioritization methodologies and strong feelings about OKRs. And in their first stakeholder meeting, they try to demonstrate all of it.

The result: engineers stop trusting them because they’re proposing solutions without understanding the system. Designers stop respecting them because they’re prescribing UX without understanding the user. Stakeholders stop listening because every conversation feels like a presentation, not a collaboration.

The fix is counterintuitive: stop trying to know things and start trying to learn things.

The Paradox of PM Influence

The PMs who earn the most influence are the ones who spend the longest being curious before being decisive. This feels wrong in fast-moving organizations that reward speed and conviction. But the conviction that comes after genuine understanding is fundamentally different from the conviction that comes from preparation alone.

I teach this by modeling it. When I join a new team, I’m openly the dumbest person in the room for the first few weeks. I ask basic questions. I sit with people and watch them work. The PMs I’m mentoring watch this and think I’m wasting time — until they see that the trust it builds is what makes everything after it possible.

What I Actually Teach Product Managers

It’s not frameworks. Frameworks are easy to find. What I teach:

How to earn trust fast. Not through credentials or confidence — through curiosity and follow-through. Ask a good question on Monday, bring back what you learned on Wednesday. Repeat.

How to say “I don’t know” without losing credibility. The words “I’ll find out” are more powerful than a guess. People remember the PM who got the right answer after checking, not the one who guessed confidently and was wrong. Honesty builds trust faster than polish.

How to own the problem, not just the solution. Junior PMs fixate on features. Senior PMs fixate on outcomes. The shift is learning to define the problem so clearly that the right solution becomes obvious — to the whole team, not just to you.

When to stop listening and start building. Because curiosity without action is just as useless as action without curiosity.

Why Developing the Team Matters More Than Solving the Problem

Every engagement I take, I’m not just solving the product problem. I’m developing the team’s capability to solve the next one without me. That’s the difference between a consultant who delivers and one who creates dependency.

The Amazon PM I opened this entry with — the one whose engineer walked over and pitched a feature — didn’t become more strategic that sprint. They didn’t have better frameworks or sharper opinions. They just got quiet enough for their team to get loud. Watching that shift was the moment I understood what mentoring actually is. Not giving people better answers. Giving them permission to stop performing the role and start doing the work. That’s the habit I try to pass on. Everything else is technique.