Before reading this chapter, I thought a product manager was essentially a mix of team leader and communication bridge. Those elements are definitely part of it, but this reading changed my assumption that the job is straightforward as it seems. The author’s quote that “none of them are about product, per se” when describing what new PMs should understand struck me – such a simple contradictory thought that makes a lot of sense as I kept reading.
I came into my internship at a local tech startup a few summers back with a computer science background from my coursework and research lab experience, thinking I’d spend my days developing creative solutions and strategy. Instead, I found myself doing what the author describes as “communicating, supporting, and facilitating.” During my ten weeks there, I spent more time setting up Zoom meetings, reconciling conflicting feedback between our designer intern and lead engineer, and also updating Notion pages than I did making actual product decisions.
The tension between “lots of responsibility but little authority” confused me throughout my internship. The author explains that “you are ultimately responsible for the success or failure of your product—regardless of how well the rest of the organization supports that product.” As a mere college student, I was supposed to be the driving force of our feature roadmap, but in actuality, I had zero ability to actually make anyone do anything. When one of the engineers decided a feature was “technically interesting” versus what users actually needed, I couldn’t really overrule him, I had to try to persuade why this wasn’t the best course of action.
In the case of the reading, what I appreciate most is the author’s honesty about the “bad product manager” archetypes, though I’m nervous I’ve already fallen into some of them. The Product Martyr resonated uncomfortably where during finals week last semester while still wrapping up my internship remotely, I stayed up late working on product specs (partly because they needed to get done but partly because I wanted my team to see me as “serious” despite being just an intern). The author nails why this happens – insecurity; when the engineer ships actual code and the designer creates beautiful interfaces, what do I have to show? A Figma file full of user flows and a Google Doc with “strategic recommendations”? It almost feels that the work is invisible and intangible.
Reading this chapter gave me something I didn’t expect, where it reframed my anxiety about “doing it all” into a question of doing the right things—and helping others do the same. I still don’t know exactly what kind of PM I’ll be, or even if I’ll choose that path. But now, instead of imagining the role as a mini-CEO or a hero who singlehandedly ships features, I’m starting to see it as someone whose success is measured by how well they bring out the best in others. If anything, that feels harder and more rewarding than the initial conception I started with.
WC: 500
Questions for the Author
- How do you protect a PM from being used as a “dumping ground” for anything others don’t want to do?
- What are some examples of PMs pushing back appropriately and effectively without harming trust/team culture?
- Has the rise of “specialized” PM titles (like Growth PM, Technical PM) helped or hurt the profession?
