I can strongly relate to the author’s thoughts on defining what a product manager is. I’ve personally gone through the process of trying to figure out the difference between all these titles that can be abbreviated as “PM” (or have something to do with products, projects, or managing something). I’m guilty of asking the common question—what does a PM do?—and feeling unsettled and unsatisfied with the answer, “it varies.” Although the ambiguity can be frustrating, I think there is also something satisfying in allowing the title to encompass so many different roles and responsibilities. My initial understanding of what a product manager does has definitely evolved as I’ve gathered more information—even in the past week alone. I’ve learned that filling in the gaps, facilitating communication across teams, and not forcing yourself into another label are all crucial aspects of the role. In the past, I saw myself defining my professional goals as being a designer with software skills. However, this chapter encourages not to tie yourself to a title like that. A PM doesn’t have to be defined by other careers; it should stand on its own.
While I appreciated the author’s emphasis on not focusing too much on what is standard or typical, I still have a couple of questions. Knowing the expectations and understanding what makes a successful product manager is better informed by studying successful examples and identifying what you might be able to do similarly, even if not exactly the same. So, I would still ask if there are any common practices or experiences of a product manager that can serve as examples. Additionally, I wonder what the best approach is for facilitating cross-communication with people you don’t directly manage or with other teams in general. How assertive should you be in this process? And how can you best form strong relationships for collaboration?
