The chapter gave me a better idea of the role of “Product Manager” as a whole across the board. Points echoing what was mentioned in class like:
– high responsibility but little authority
– “If it needs to get done, it’s part of your job” — you need to do whatever needs to get done– you are in the middle. I’ve known at early-stage startups have found themselves working as ad hoc community managers, HR leads, UX designers, and office managers. If it needs to be done, and it isn’t anyone else’s job, then—surprise!—it’s your job.”
As a PM at an early stage start up, the job certainly fit the later description.
The opening of the chapter has 3 things Pradeep GanapathyRaj thinks new PMs should understand about their responsibilities:
• Bring out the best in the people on your team.
• Work with people outside of your immediate team, who are not directly incentivized to work with you.
• Deal with ambiguity.
The points hit home with me as they represent the challenges I faced as a whole during my work experience as a PM. I feel like my peers and I ideally want to be “building products that people love”, but knowing that the real day to day involves mostly communicating, supporting, and facilitating. “…success can only be realized through the shared efforts of the people around them.” might be tough to swallow. Additionally that “If you like to be the person actually building things with your hands, you might find yourself deeply frustrated by the connective and facilitative nature of product management.”
The section of “What is Not Product Management was also very interesting to me. Especially the part where the writer says that “most of the product manages I’ve seen act like a “mini-CEO” of a product but that the PM needs to know that they are not the boss. I;ve definitely seen this a lot before.
The further points about the role made me feel more confident that product management is a good fit with my personality and skills.
“Generally speaking, the “classic” profile for a product manager is either a technical person with some business savvy, or a business-savvy person who will not annoy the hell out of developers.” And then that the best PMs are people who like to solve interesting problems, learn new things, and work with smart people” along with, “Great product managers are the sum of their experiences, the challenges they’ve faced, and the people they’ve worked with. They are constantly evolving and adapting their own practice to meet the specific needs of their current team and organization. They are humble enough to recognize that there will always be new things to learn and curious enough to constantly learn new things from the people around them.” echo my own thoughts but organized in a succinct way.
The chapter also clarified the difference between product managers and product owners. This excerpt was satisfying to read:
“I’ve started thinking about the ever-expanding list of “pro**** ******er” titles as Ambiguously Descriptive Product Roles (ADPRs), in the interest of having a banner concept to encompass the myriad job titles that likely won’t tell you all that much about your day-to-day activities and responsibilities. For ADPRs whose teams include other ADPRs, I find myself offering the following, similarly disappointing advice: “Sit down with your fellow ADPRs, figure out what needs to be done, and figure out how you’re going to do it together…Long story short: every single product job on every single team at every single company is a little different. The sooner you truly embrace this, the sooner you can get to the hard work of doing your specific product job as best you, specifically, can.”
This honestly clarified a lot of confusion I had. Overall it was a very enlightening chapter!
