Leadership Lessons: Coaching Practices

The best product leader I ever worked with rarely gave direct answers. Instead, they asked questions that made you think differently about the problem.

“What would you do if you had unlimited engineering resources?” “What if this feature failed completely — what would you learn?” “Who else has solved similar problems, and how?”

Oh, how frustrating it was at first. Then, eventually, transformative. They were coaching (teaching, really), not managing. Building capability, not just delivering results.

Most product managers (but also leaders) never learn this distinction. They spend careers telling people what to do rather than developing people who can figure it out themselves. Short-term efficient, I agree. Long-term, though? Disaster.

Here’s what separates leaders who build strong teams from those who build dependent ones.

What Effective Coaching Actually Looks Like

Coaching isn’t mentoring. It’s not advising. It’s definitely not telling people what to do whilst calling it “coaching.”

Coaching is helping someone develop their own thinking through structured questions and reflection.

The coach’s job isn’t to have answers. It’s to help the person find their own answers and develop better thinking patterns.

Building Judgment, Not Just Execution

Most leaders optimise for execution. Get this thing done. Hit this deadline. Deliver this result.

That creates doers, not thinkers. People who execute well but can’t make good decisions independently.

Coaching builds judgment. It develops decision-making capability. Creates people who can handle novel situations without needing you.

Marty Cagan at SVPG talks about empowered teams vs. feature teams. The difference is judgment. Empowered teams can figure out what to build. Feature teams need to be told.

Coaching is how you build empowered teams.

The Socratic Method for Product Leaders

Ask questions, don’t give answers.

Instead of: “Here’s what you should do…”

Try: “What options have you considered? What are the trade-offs of each? What would you need to believe for option A to be the right choice?”

This is harder. Takes longer. Requires patience.

But it builds capability. The person learns to think through problems themselves, not just execute your thinking.

Building Early Foundations

What should you coach on when you’re building a product team?

Decision-Making Under Uncertainty

Product management is constant decision-making with incomplete information.

Coach your team through the decision-making process:

• How do you frame the decision?
• What information would help?
• What assumptions are you making?
• How would you test those assumptions?
• What’s the cost of being wrong?

This develops decision-making muscle. Over time, they get better at making good calls with limited information.

Stakeholder Management

Most PMs struggle with stakeholders. Engineering wants certainty. Sales wants everything. Executives want strategy.

Don’t solve stakeholder problems for your team. Coach them through it.

“What does this stakeholder actually care about? What’s the concern behind their request? How could you address the concern without the specific solution they asked for?”

This builds political intelligence. They learn to navigate organizational dynamics.

Prioritization Judgment

Frameworks help with prioritization. RICE, ICE, weighted scoring. But the real skill is judgment—knowing when the framework is wrong.

Coach by exploring edge cases: “The framework says do X, but your gut says Y. What is your gut seeing that the framework misses?”

This develops nuanced thinking. They learn frameworks are tools, not rules.

Scaling for Growth

Coaching approaches that work at 5 people don’t scale to 50. Your approach needs to evolve.

From Individual Coaching to Team Coaching

Early stage, you can coach individuals directly. At scale, you need to create coaching capacity in others.

Teach senior team members to coach. Create structures that facilitate peer coaching. Build a culture where coaching is normal.

Building Systematic Development

Ad hoc coaching doesn’t scale. You need systems.

Competency frameworks that show what good looks like at each level. Career ladders that create development paths. Regular capability reviews separate from performance reviews.

These systems create structure for development. Coaching happens within that structure.

Measuring Coaching Effectiveness

How do you know coaching is working?

Look at team capability, not individual satisfaction.

• Are people making more decisions independently?
• Are those decisions good?
• Do team members ask better questions?
• Is the team developing bench strength?

If coaching works, your team becomes more capable over time without needing you as much.

The Startup Reality

Startups face unique coaching challenges.

Limited Time for Development

Everything’s urgent. Every decision matters. Taking time to coach feels like luxury.

But it’s investment. Time spent coaching compounds. Decisions you don’t need to make. Capability that scales.

Make coaching intentional, not accidental. Schedule it. Protect it. Even 15 minutes weekly adds up.

Balancing Coaching with Directive Leadership

Sometimes you need to just decide. Crisis situations. Novel contexts where the team genuinely lacks experience.

The skill is knowing when to coach and when to direct.

Rule of thumb: If there’s time to think it through, coach. If the building’s burning, direct.

Resource Constraints on Formal Development

You don’t have budget for executive coaches or elaborate training programs.

Coach internally. Create peer coaching. Use everyday work as development opportunity.

After product reviews, debrief. After stakeholder meetings, discuss what worked. Turn normal work into learning moments.

Practical Coaching Techniques

Specific approaches that work.

The “What Would You Do?” Question

When someone brings you a problem, ask: “What would you do if you had to decide right now?”

This forces them to form an opinion. Then you can coach on their thinking rather than solving the problem for them.

The Five Levels of Why

Don’t stop at surface problems. Dig deeper.

“The feature is delayed.” “Why?” “Engineering underestimated complexity.” “Why wasn’t complexity understood earlier?” “We didn’t involve engineering in scoping.” “Why not?”

Now you’re at a pattern that can be coached: not involving technical stakeholders early enough.

Scenario-Based Coaching

Present hypothetical scenarios. Work through the thinking together.

“Engineering says this will take 3 months instead of 1. What do you do?”

This builds judgment without real-world consequences. Like flight simulators for pilots.

Reflection After Key Events

After launches, stakeholder presentations, customer escalations—debrief.

What happened? What went well? What would you do differently?

Key Takeaways

• Coaching builds judgment and capability, not just execution. Ask questions that develop thinking, don’t give answers that create dependency.
• The Socratic method works for product leadership. “What options exist? What are trade-offs? What needs to be true?”
• Make coaching systematic as you scale. Train senior people to coach. Create structures. Measure capability development.
• Know when to coach vs. when to direct. If there’s time to think, coach. If it’s urgent, direct.
• Use everyday work as coaching opportunities. After reviews, meetings, launches—debrief and extract learning.

Final Thoughts

Coaching isn’t soft skills nonsense. It’s the most practical thing a leader can do. It multiplies capability. It reduces bottlenecks. It builds teams that can handle complexity independently.

The best leaders I know aren’t the smartest people in the room. They’re the ones who made everyone else smarter.

Start small. Next time someone brings you a decision, ask “what do you think?” instead of telling them the answer. See what happens.

Have questions or thoughts? Get in touch - I’d love to hear from you!