The first chapter and foreword of Product Management in Practice was incredibly informative and validating. Firstly, I really resonated with the section towards the end that discussed a product manager’s search for “quantifying the value” they brought to the table, when an engineer has tangible lines of code or a designer has stunning visuals to show. Pinpointing that common pitfalls PMs find themselves in stem from insecurity was an interesting and on the nose insight – I can definitely relate, from past work experiences or even parallel academic experiences as someone who has always liked to sit between business and technical.
On a separate note, I really appreciated the chapter’s emphasis on the ambiguity of the product role. I think many students including myself who attempt to prep for product roles get caught up in jargon, in frameworks, in mock interviews and play by play strategies, when real world product management is mostly about being a flexible connective tissue between stakeholders that strongly aligns, keeps morale high, and has poignant influence without any real authority. A few of the big takeaways the chapter discusses towards the start made me feel excited; I often experience doubt in the product field, and I felt like these takeaways on what makes a good product manager fall within my strengths. One of these was “you can’t wait around for someone to tell you what to do.” I feel like this takeaway is what distinguishes a product manager from other careers one could carve out at a tech company – a software engineer, a designer, a data scientist, etc. all take instructions from someone and have workflows that are far more task-based than a PM. Scrappiness is required to be a successful, proactive, and creative problem-solving product manager. A question I have for the authors on this point, however, is how do you reconcile being scrappy in the face of the unknown while also maintaining consistent alignment and agreement with your overall team, when you don’t have any formal authority? What decisions do you have authority over as a product manager, especially if your organizational structure is flat, and how does one balance having to solve problems quickly with not being able to act quickly, as your workflow depends on others?
Overall, I really appreciated how this chapter gave a generalized overview on the practical role of a product manager in an organization, abstracting it from what you would normally read about in a book about APM programs or articles on one’s first years as a PM. It’s useful to ground the role in reality to really understand what it would be like to pursue it realistically.
