Overall, I appreciate that, in defining product management, the author focused on key discrepancies between commonly understood definitions of a product manager and the practical skills and day-to-day situations a product manager may encounter. I now see a product manager’s role as a connective and cross functional role that has ownership over all aspects of a product.
Stuck In the Middle
A product manager oversees all aspects of product development and deployment, making this role connective by nature. Product managers deal with everyone from software engineers, to CEOs, to the GTM team, and therefore need strong relationships throughout the firm. In my experience, this also means that a product manager must speak the same language as the people in these roles, so that when the GTM team says something about losing customers in the funnel, the product manager can tell the engineers which website features to improve and why.
I would like to ask the author if there are specific people within firms that it is important to know. For instance, should they build relationships with decision makers, or lower level employees who may touch the work more directly?
Responsible for Everything
The author made an important point about the gap between theoretical preparation and the realities of the job. Despite reading all PM-related books and feeling completely prepared on paper, it was difficult to understand what to do during on the job and real world guidance was hard to come by. Since product managers are responsible for everything, there is huge variability in day-to-day tasks, and it is difficult to ever be prepared. I would like to hear more from the author about the steps they took to clarify their responsibilities, and what they would do differently if given the chance.
Here, I appreciated the author’s note that being responsible for everything does not mean 60-hour work weeks. There is a difference between hours worked and value added. Working long hours early on was due to their inexperience, insecurity, and inability to prioritize time. This example is relevant not only for product managers but for virtually all roles. I would be interested in asking the author how they eventually overcame these challenges, particularly in a role that comes with total responsibility.
No Authority
Despite having responsibility, being a PM does not come with organizational authority, as other team members are more expert than the PM in their respective domains. To me, this highlights the fact that not everyone would thrive in a PM role, as you have to be comfortable not being the expert on something and instead receiving information from other people. To me, this sounds exciting, but I would like to ask the author if the lack of authority was frustrating or empowering.
Conclusion: Stuck in the middle with all the responsibility and no authority?
These three seemingly unfortunate characteristics of a product manager changed the way I think about the role. On paper, being stuck in the middle with all the responsibility but little authority sounds like a recipe for disaster. Yet, the author also notes that success comes from being proactive, measuring success by value to the business, and getting ahead of miscommunication. A product manager also sits between UX, business, and tech, uniquely positioning PMs to have a large breadth of knowledge at any given firm. As someone who studied Symbolic Systems in undergrad, developing technical and non technical skills while working with many different kinds of people sounds like a good fit!
