Image courtesy of Bob Jagendorf, on Flickr
One of the most misunderstood roles in the valley is that of a Product Manager. Depending upon which company you go to, and which methodologies or processes that company is using, there is a different definition of a product manager. With everyone flocking to Agile/Scrum, there is yet more confusion with teams confusing Product Owner with Product Manager.
Over the past couple of years, I have been leading product management workshops and courses. Irrespective of the company or audience, I have found it useful to introduce ‘The 5 Hats of Product Management’.
Every PM has strengths and weaknesses, and by no mean do you need to be an expert in each of these. However, a PM does have to be able to understand these areas well enough, to gain the trust and support of those who actually are experts in those areas.
- The ‘Strategy hat‘. Arguably this is the absolute must. If you are unable to wear this hat, then you are not a product manager. A product manager is the sheppard of the product. In order to get the product to where it needs to be for customers, she/he needs to understand the market, understand the needs, and set the vision and roadmap for the entire team. Confusion often occcurs, when a person in a product manager role thinks they need to be given formal product ownership, or be told outright that they are setting the strategy. The reality is that never happens. The skill to be able to influence, manage, and direct in all directions (upwards management, peer stakeholders, superstar engineers) is at the crux of what a product manager does. They need to take the inputs and signals from all sources, and then figure out how to distill that into a strategy, roadmap, and ultimately a prioritized set of executable features for all invovled to buy into. No one is ever able to set a strategy or vision independently. Even CEOs of companies are beholden to shareholders, partners, and even the interests of employees. When wearing this hat, the product manager’s role is to influence the overall strategy towards the intended direction, and to provide a clear roadmap for the team to execute on.
- The ‘Designer hat’. Many think of this as graphic design or UI/UX design. Those are encompassed when wearing this hat, but it is much more holistic and about having empathy for the user: to really understand what a user problem is as well as to understand what the ‘job to be done’ is at each stage. Wearing this hat requires conveying the user pain points and working with UI/UX/designers to craft a solution that provides a solution. Design is increasingly becoming more and more important and those PMs that embrace design thinking are getting an advantage. Apple and Airbnb are examples of companies that get this — they think of the ‘whole product’. For example, Airbnb does not just figure out how to rent you an apartment, they also think about the steps before and after. How do you pick up the keys? How do you return them? In the case of Apple, they design the minutae of the UI/UX of their devices, but they also design the purchasing experience and the package unbundling experience. In order to excel, a PM does not need to be an expert at creating a great UI for example, but to be able to step back and look at the overall experience, as well as deep dive into knowing what details such as colors, fonts, etc also need to be refined. They need to foster the team to have empathy for the user through out the user experience.
- The ‘Analytics hat’. In today’s world of Big Data and instrumentation of everything, there is a propensity to think that analytics is easy. The reality is that the flood of data is making it even more difficult. Measuring everything yet understanding nothing. A PM needs to understand their product in such detail so as to know what are the important metrics to cut through all the data to make sense of it all. Analytics feed into both the Strategy and Design perspectives — using data collected, a PM can better understand user pain points, and can refine the strategy to get a better product/market fit. Often the product manager is not analytical enough, and thus data-driven ends up being the tail wagging the dog — where a change in some misinterpreted data point, drives a change in roadmaps. For example, a not understanding that a drop in user clicks is due to an improved layout allowing users to navigate to their desired location faster, rather than a user abandoning the site or app. Analytic data is fairly useless without context. A PM needs to understand what needs to be measured and be able to corelate that information with data often obtained externally, and use it to prove or disprove a hypothesis or product features.
- The ‘Technical hat’. This is especially necessary in the valley and for any company that utilizes technology even. A product manager needs to understand the implications of technical choices. Understand how a new technology can potentially be leveraged, what the longer term maintenance and tech debt costs will be, to understand what is really feasible (with the team skills available) and understand the real impacts to particular tradeoffs. Often you will see companies separate out product features into one roadmap, and then technical needs into a separate roadmap and the product manager remains at arms length away when making decisions. Thus the choice of weather to use one technology over another is not analyzed enough to understand the implications on a user experience in the short or long term. If a technical choice inhibits the ability of PM to make changes expected in the future, that needs to be understood and needs to be planned within a single roadmap. The need to decommission a particular software stack in favor of a new one for example, needs to be understood and prioritized by the PM. It is the lead engineer’s role to ensure that the PM understands the implications of making (or not making) particular technical choices, and the PM is responsible for making the trade off decision.
- The ‘Execution hat’. The last, but definitely not least, is being able to get things done. A PM needs to establish a track record of launching. Without this, she/he becomes less and less effective at wearing the other hats. This does not mean having a record of launching big fancy products. It is more about showing a series of successes. The team roadmap should include not just end product features, but also tech debt, devOp improvements, etc. All of these things lead to a higher performing team. This leads to the eventual big game changing launches, but all the work running up to that is just as important. Often, PMs think of everything here as a project manager’s role. In reality, the PM needs strong project/program managers, but they are there to help the PM to execute – they still require the PM to set the priorities. When wearing this hat, the PM needs to understand DevOps, process, program management, project management, and overall operations. Can you actually get things done when it counts and will it hold up to scale.
These ‘hats’ are not disparate roles. They are different facets of a PM — sometimes worn all at once, and sometime individually within a particular exercise. When you are looking at your product and are struggling to make progress, try to think of it in terms of which hat you are wearing, and tackle it from that perspective.
If you are PM waiting for formal ‘ownership’ in order to really start executing, then you may be in the wrong role. I’m not sure if I buy into the ‘a PM is a mini-CEO’ statement, but a PM definitely needs to be a Leader.
From your experience, what ‘hats’ have you seen PMs wearing or not wearing? Do you excel at wearing one of them?