At first read you may think a “product manager” is a “people manager” - that they manage people working on a product. That’s not strictly true. Unlikely an Engineering Manager, who is responsible for career development and performance of their direct reports, a Product Manager doesn’t typically have direct reports (until they become a Group Product Manager, Director, VP, etc). Rather, a Product Manager is the Manager of the Product itself.
The Product Manager is usually responsible for a mix of product strategy (what our product should try to achieve, for whom, and why), execution coordination (aligning stakeholders across different functions, making sure a high quality product ships on time), and filling in gaps on the team as needed (running data analysis, helping make mockups, etc). As such, there’s a tremendous variety of day-to-day experiences PMs have on different products, all under the same job title. Back when I was at Google, one of my PM friends worked on self driving cars and spent 90% of their time explaining and advocating technology to lawyers and policymakers, another PM friend was building mobile prototypes with designers and engineers to dream up Google’s next mobile products, while I was acting as Experiment Czar for a Google Search team testing improvements to our search experience. Wow: that’s a wide range of different jobs!
One of the common threads across teams is that PMs are excellent communicators to diverse audiences. They’re able to talk in high level abstractions or nitty gritty details, whether those are in diverse domains like engineering, design, marketing, policy, analytics, etc. PMs are excellent synthesizers, pulling together all the goals, data, tasks, constraints, and people on a team to point in the right direction and make measurable progress.
PMs are sometimes called “the mini-CEO” of a product. (Having been both a PM and a startup CEO, that description doesn’t feel the most accurate to me, but I’ll save that discussion for a separate post.) The “mini-CEO” analogy is often used to try to show that a PM should act like an owner for the whole product experience, and should collaborate across functions and layers of abstraction to achieve success.
