In This Article
The transition from individual contributor to product leader is arguably the hardest career shift in product management. No one warns you how much it changes -- not just your day-to-day work, but your identity, your definition of success, and the skills you need to rely on. Here's what I learned the hard way.
The Moment Everything Changed
I didn't plan to become a product leader when I did. Like many product managers, I fell in love with the work itself -- building things, seeing results, making a direct impact.
Then organizational reality hit. Through a combination of attrition and restructuring, I suddenly found myself responsible for seven different product teams across five time zones.
After a months-long process of fighting for resources, I finally got approval to hire product managers. I didn't get a promotion, but I did get the direct reports. I was going to earn the promotion by doing the job first. So be it.
I started hiring. I'd seen other PM leaders do this for years and thought I had it figured out. But I wasn't learning, I was mimicking. And that hurt me.
I convinced myself I could turn these PMs into extensions of myself. I was simultaneously overconfident and underprepared. First I micromanaged too much, then over-corrected and managed too little. I eventually found a sweet spot, but not after a lot of confusion and false starts that seem pretty stupid today.
The breakthrough came when I received the best advice of my leadership journey: "Treat your team like your product. You're not managing products anymore. You're managing THE TEAMS that build those products."
The Four Stages of Leadership Evolution
As I reflected on this new role, I realized these stages were really different jobs. Individual Mastery -- success from personal output. Guided Transition -- the uncomfortable stage where you're still doing IC work while adding leadership duties. Full Leadership -- the mindset shift where success comes from your team's growth and decisions. Scaled Leadership -- developing other leaders across multiple teams.
The Psychological Challenges
The Identity Crisis: Many PMs derive their identity from building and shipping products. In leadership, you're building teams that build products. That shift hits harder than you'd expect.
The Control Paradox: You're accountable for more outcomes with less direct control. The two failure modes: The Super PM (involved in every decision) and The Hands-Off Manager (delegating without support). The answer is providing context while allowing others to make decisions and learn.
Real-World Lessons from My First Team
After I finally got approval to hire, I made several costly mistakes:
Mistake #1: Prioritizing Potential Over Capability. I hired smart people with limited experience, thinking I could develop them quickly. I didn't have bandwidth for intensive mentoring, and they struggled with engineering partners. Lesson: in your first leadership role, hire people who can hit the ground running while you're still developing management skills.
Mistake #2: Unclear Role Definition. I assumed new team members would figure out responsibilities organically. Confusion and territorial disputes followed. Define roles and decision-making frameworks before bringing new people on.
Mistake #3: Inconsistent Standards. I applied different standards to different team members, creating perceptions of unfairness. Set consistent standards while providing differentiated support based on individual needs.
Each of these mistakes forced me to build a more deliberate approach to handing off work. The pain of getting it wrong enough times eventually crystallized into a framework I still use today.
The Delegation Framework
One of the hardest skills is deciding what to delegate. Hold tight to strategic decisions affecting multiple teams, executive relationships, and performance management. Share actively on product strategy, resource allocation, and hiring. Give away completely the day-to-day feature decisions, customer research activities, and implementation details.
The key: everything you delegate needs clear context, success criteria, and support systems.
That advice I received early on -- treat your team like your product -- remains the most useful lens I've found for this transition. Just like any good product, your team needs continuous investment, honest feedback loops, and the space to grow beyond your original design. The sooner you internalize that your team's success is your success, the sooner leadership stops feeling like a loss and starts feeling like the most impactful work you've ever done.