Moving from individual contributor to leading product managers is one of the least prepared-for transitions in tech. Your output is no longer your specs; it's the quality of decisions made across a portfolio you can't personally touch. Here is what has worked for me.
Hire for judgement
Domain knowledge can be learned in months. Judgement — knowing which problem matters, when to push back, when good is good enough — takes years. In interviews I spend less time on frameworks and more on real trade-offs: "Tell me about a time you killed something you wanted to build."
Give context, not instructions
The fastest way to slow a team down is to make every decision yourself. I try to give each PM the business context, the constraints and the outcome we're after, then let them own the how. My job is to make sure they have the information I have.
Coach for clarity
Most PM problems are clarity problems: a fuzzy problem statement, an unclear decision owner, a success metric nobody agreed on. In one-on-ones I ask the same questions repeatedly: What problem are we solving? How will we know? Who decides? Over time, PMs start asking themselves first.
Protect focus
Product managers are interrupt magnets. A leader's quiet job is absorbing escalations, saying no to side quests and keeping the roadmap stable enough that teams can finish things.
Celebrate learning, not just launches
If we only celebrate shipping, people ship things that shouldn't exist. I make a point of recognising the PM who ran the experiment that saved us six months of building the wrong thing.
Great product leaders don't make the best decisions. They build teams that do.
Leadership in product is mostly invisible when it works: clear priorities, confident PMs and engineers who understand why. That invisibility is the goal.
