What is Product Management?
Product management is a weird, confusing, misunderstood, yet core function of every tech company. The role of the Product Manager is sometimes even misunderstood by their fellow employees. It’s confused with project management, which is but one part of a Product Manager’s role. It also doesn’t help that the role can go by different titles in different companies. At Microsoft a PM is a Program Manager and in more traditional agile practicing companies, the title might be Product Owner.
Product management sits on an engineering team (often called a scrum team) at the intersections of solving design, engineering and business problems. The PM doesn’t have to be a master in any of those three disciplines, but has to be fairly proficient in all. Understanding how all three disciplines fit together and how much of each should be used to solve a particular problem is key. At the end of the day, a good PM must be able to thrive in ambiguity.
The exact role of the PM varies a bit company to company and team to team. While most of the time the Product Manager sits at the intersection of those three disciplines, there are plenty of examples where the particular product the company is building or the team changes the focus. For example a PM sitting on a team building out the API is probably going to be heavily skewed towards the business/engineering part of the venn diagram and doing very little design. On the other hand a PM sitting on a front-end architecture team doesn’t need to know nearly as much about business.
There are a handful of different PM archetypes among the tech giants that are reflected in smaller companies. Google and Facebook steer towards far more traditional technical engineering background. Amazon prefers MBA graduates and don’t consider a technical background nearly as important. At Microsoft, where the practice was originally developed, the PM is the creative driving force for most software projects and most closely aligns to sitting in the center of the above venn diagram. Again it really comes down to the product and team.
Want to know how a smaller company runs the product management structure? Find out at which big companies the founders or key executives previously worked. One of the better resources for understanding the different archetypes and how different companies treat product management is a book called Cracking the PM Interview. The first third of the book is all about finding the right fit as a PM.
The specific skills a PM uses are wide ranging. The best overview of skills I’ve seen comes from Stack Overflow’s skills assessment page.
The final piece to begin to understand product management is that while the PM usually sits with an engineering team, they do not directly manage that team. Within the HR reporting structure, engineers report to an engineering manager who is not on the team. The thinking is that if the PM has the authority to fire members of the team, the PM can exert undue influence. Thus there is a bit of a checks and balances system put in place which allows engineers to push back on overly aggressive timelines or requirements without fear of direct reprisal. Ultimately Product Managers must manage through influence because they have the responsibility, but not the authority to force things to happen.
