How I See the Role of a Product Manager
What stood out to me most from the first chapter of Product Management in Practice is how much of a PM’s work happens in the shadows. The PM doesn’t own code, designs, or revenue directly, yet they are expected to orchestrate all three. The role requires convincing people to prioritize your project without pay, promotions, or direct authority as leverage. To me, that feels less like corporate management and more like persuasion under ambiguity.
I’ve seen glimpses of this dynamic outside the classroom. In my fraternity, our financial chair is responsible for collecting dues, reimbursing expenses, and balancing the books. No one joins a fraternity for the thrill of paying bills, but everyone depends on him to keep the chapter functioning. He spends hours chasing people down, negotiating with vendors, and explaining why we can’t fund every idea. Most of the work is invisible, but if he slips, everyone notices. Watching him burn out taught me that the hardest jobs are often those where the wins are collective, but the failures fall squarely on one person’s shoulders. That mirrors how the book describes product management: vital, yet often thankless.
I’ve also seen shades of this in internships. At Battery Capital Partners, I worked with a small plumbing and HVAC business that lacked financial infrastructure. I wasn’t there to run operations, but I was suddenly responsible for pulling scattered data into a system managers could use. The technical experts kept the trucks moving; my job was to quietly make sure the foundation didn’t crack. It was unglamorous, but necessary, exactly how PM work is described.
What Seems Most Challenging
The chapter’s discussion of negotiating timelines with executives made me pause. Executives want aggressive dates to satisfy markets or investors, while PMs must relay the slower, messier truth from engineering. That tension seems to require storytelling skills, and framing trade-offs in terms leaders understand without alienating the teams actually building the product.
My Questions for the Author
- Given how ambiguous the role is, what should someone new to product management focus on learning first to be effective across different environments, and how do you earn the trust of engineers with little technical know-how?
- What strategies have you seen actually work in negotiating timelines with executives who want things faster than is feasible?
- How do PMs avoid the burnout that comes from carrying so much responsibility without much recognition?
