Analysis on PM:
Before reading Product Management in Practice, I always thought of a product manager as the glue and catalyst holding together large complex processes or projects. Whether that role is seen as a pseudo-CEO or a glorified micromanager, this chapter helps to construct a solid view on what a PM is. In fact, I found that my preexisting thoughts were pretty much in line with with book statements. That said, the chapter made it clear that being a PM is less about directly building the product and more about connecting people whose goals, timelines, and incentives don’t naturally align.
The author emphasizes that PM’s carry a lot of responsibility while actually holding little authority. That stood out to me because it mirrors what I’ve always imagined the role to be: someone who needs to understand engineers’ challenges and timelines, while also communicating business needs from leadership. You’re not the boss, and you’re not the one writing the code or designing the interface, but you are the one who makes sure all those moving parts fit together into a coherent plan.
What also struck me was the idea that product managers must constantly deal with ambiguity. The book says the skill of figuring out what needs to be done is just as important as what you do afterward. I resonate a lot with this. In short, I see PMs as connectors and translators. They bring together business strategy and technical execution, making sure all the conversations that need to happen actually happen.
Questions:
- You talk about PMs having lots of responsibility but little authority. What advice do you give to new PMs who are just starting to build influence in that gap?
- Many people are drawn to PM because they want to “build things,” but how can PMs stay motivated when most of their work is connective and not directly creating?
- What personal strategies or frameworks should a PM use when in a high-ambiguity situation with unclear priorities? Is there some framework that’s most effective?
