This reading gave me a new perspective on what it really means to be a product manager. I used to think of PMs as “mini-CEOs” as the author termed, the ones who call all of the shots and delegate tasks, but this chapter reframed that image completely. The author explains that PMs have lots of responsibility but little authority, which made me realize how much of their job depends on influence rather than control.
This past summer, I worked as a software engineer intern for a product team at Amazon Web Services and worked closely with a PM. I remember thinking how lucky he was to “run” the product rather than be an engineer who has to make it. But looking back, I can see how much of his work involved mediating between designers, engineers, and executives, he was simply “working in the middle.” He spent more time translating ideas and resolving miscommunication than actually “deciding” things and was just as much on a timeline as the rest of us. I also now understand why our PM was so strict with deadlines. As an intern surrounded by engineers I was focused on our own perspective. I had thought the engineers who can’t deliver are the ones who are blamed for missing a product launch, but in reality it’s the PM who has to take responsibility.
I also found it particularly interesting that to be a good PM you have to let go of the “fine, I’ll do it myself” mindset. I like taking ownership, getting things done, and moving quickly. I imagine if I were a PM right now I would be called a micro-manager. But product management demands a different kind of leadership. Hiding that instinct and instead learning to inspire others to act sounds like one of the hardest but most important shifts for someone like me.
Some questions I have:
- How do you personally develop influence and trust as a PM without formal authority?
- When working across teams that have competing priorities, how do you decide whose goals to prioritize?
- How do you know when you have enough clarity to make a decision versus when to keep gathering input?
