Product Management is usually a dynamic role with massive ambiguities. It’s not very easy to define a Product Management role that holds true across all contexts. While some roles might be more indexed towards revenue / business, some might require PMs to be indexed more towards system design (usually called a Technical Product Management). Further, certain products are transactional in nature (eg: e-commerce) whereas some products primarily focus on users spending more time on the platform (eg: social media), both of which require very different design ethos, hence different natures of PM. Even within the same organization, different departments require PMs with very different skill-sets (PM at Google Brain would typically be very different from an ads-product PM). One description I’ve heard a lot is – Product Manager is the CEO of a product. Personally. I refrain from using this definition simply because a CEO has real authority, whereas a PM needs to be able to influence without authority. Also, if a product doesn’t work, it’s typically the CEO who gets the brickbats (most don’t care who the actual PM is) since the CEO is the final authority.
Though it’s a difficult role to describe, having been a PM myself the past few years (and having worked with several PMs across levels), I have noticed a few common traits that make a great PM. Seen through the context of these qualities could give us a clearer picture on the demands of the job, and overall what the role entails. Let’s look at some of the most important ones.
Zooming Out vs Zooming In
There are multiple levels to building and launching a product. A Great PM should be able to see the bigger picture AND understand the specifics of execution around the product. The bigger picture includes considerations of current business and product offerings, competition and users. Some of these include:
- What is the broad business strategy encompassing this product’s utility?
- What business metrics will it improve and to what extent?
- How does it fit into our current product ecosystem?
- What does the competitive landscape look like? Are we differentiating or is it table stakes?
- What does the consumer behavior look like, and how will it shape / enable a desired behavior?
On the other hand, zooming in involves understanding the minute details of UI / UX and the development of the product itself. Some questions might include:
- What data would be collected and where would it be stored?
- How does data flow around the product?
- What does the user interface look like (down to the last pixel)
- How will users navigate the product? What are the potential edge cases around UX? What does the system design look like? Which frontend systems and templates are being used?
- Which browsers and OS are we developing for, and what are their nuances?
Though, depending on the nature of the PM role, the level of knowledge required across different aspects might be different, there needs to be an understanding and articulation at each level, followed by weaving them together coherently. The ability to operate effectively at multiple levels becomes a necessity to be able to achieve this.
Immense curiosity
Curiosity as a behavior and emotion is attributed as the driving force behind human brain development, and consequently developments across science, society, culture and economy. A central part of being PM is the ability to ask a lot of ‘Why’s’. Knowing the reason behind why something is the way it is, is extremely important to understand the said phenomenon. Curiosity helps uncover truths and insights, which act as a fountainhead of new ideas powering the engine of progress. Curiosity helps is knowing what something is, why it is like that, why something works / doesn’t work.
In general, building new products and solving novel problems requires 4 major things – information research / retrieval, information synthesis & analysis, solution articulation, and solution implementation. Being genuinely curious makes it easy to retrieve the necessary information and understand the root cause. Understanding business strategy helps build context around product strategy and its initiatives. Why the product is designed the way it is helps us think from a first principles perspective around how it can be improved. The same goes for system and logic design, where building an understanding helps in creating scalable and clean systems
Curiosity also leads to seeking knowledge around subjects which might not be of direct functional importance, but is of immense help in becoming better thinkers. There is a massive amount of knowledge around user psychology, business history and current technological trends which might not be required directly for a PM in their day to day activities, but their knowledge helps build a broader context around which PMs can take effective long-term decisions.
Sense of Ownership
A designer designs the product, an engineer builds it, QA tests it and the marketing / sales take it to market. So what does a PM exactly do? She decides the product vision. Once the vision is decided, it is her responsibility to ensure execution across the whole chain – right from design to development to testing to launch – is done in accordance with that vision. It’s also her responsibility to ensure execution is of the highest quality so that user experience is of the highest quality. Ensuring all of this requires an extreme sense of ownership over each and every detail of the product. Further, once the product is launched, PM needs to continuously monitor for bugs and collect data around user behavior to check if business / product targets are being met. Customer complaints need to be resolved in a timely manner. To further improve the product, iterations need to be charted out and included in the product roadmap. The entire product life cycle is owned by the PM, and the only way to be effective in this role is to have that high sense of ownership.
High Empathy
Being a PM requires managing stakeholders across multiple contexts. Product management is a dynamic role which generally does not follow the usual hierarchical structure that most other functions have. Since PMs are expected to influence without any formal authority, it’s important to build an understanding of major stakeholders, both inside and outside the organization. Understanding their needs and empathising with them is critical here.
There are 3 broad sets of stakeholders a PM needs to work closely with
- Users: Products are built for them. Uncovering the truth behind user motivations requires immense understanding of users, their needs and aspirations and their day to day lives. Being a PM requires regular conversation with users, either verbally or through surveys. Being able to figure out what they are actually saying (which goes beyond words and demands a deeper understanding) is critical to come up with product insights. This isn’t possible if PMs don’t understand who the user is and what fulfills them.
- Builders: This includes the engineering and design teams which help us build products. To be able to work effectively with them, it’s very important to understand their motivations and speak their language. Design teams want to build beautifully created products which help users achieve their desired functionalities. Hence, focusing on user journey and delight while pitching products is quite impactful. For engineering teams, solving interesting engineering problems with high productivity is important. Being able to talk systems language and convincing them on why building a particular product is very important goes a long way in enthusing them to build it.
- Business: This includes business stakeholders such as GMs, strategy, marketing and Analytics functions. For them, it’s important to speak to how the product roadmap aligns with their business metrics. Also, it’s important to keep them updated on roadmap progress, post product launch data and resourcing needed for future projects so as to cultivate transparency and trust.
Broadly speaking, empathising with stakeholders helps a PM speak their language and thus build influence (without authority).
Context switching
IMO, this is probably one of the toughest skill sets to have. A typical day in a PM’s life usually comprises several back to back meetings, maybe one talking about the legalities of going with a payment vendor and the next about solving a caching issue with servers. Being able to effectively switch context so as to understand and contribute to completely different aspects is difficult enough. Doing this throughout the whole day can be downright tiresome. Being effective requires high energy levels, ability to compartmentalise (and connect wherever necessary), effective listening skills during meetings, and the ability to grasp and build context quickly. This also requires a high degree of awareness since we need to be able to speak the right language and go to the right depth – a business meeting is usually very different from an engineering meeting. Asking the right questions becomes very important too, since that helps us get to the root of the matter quickly.
An important point here is that while context switching is necessary, doing this multiple times a day everyday kills attention, and thus our ability to do focused work. Hence it’s imperative that we schedule our days to allow heavy context switching during some blocks of time, and focused blocks during others. This conserves mental energy over the long run and helps PMs remain effective context switchers.
Qualitative vs Quantitative
Decision making requires a good amount of information. Information can come from multiple sources – talking to users, internal stakeholders such as sales, market research, product usage, user funnels or cross-platform Analytics. What information is important, why it’s important, and how to synthesise them effectively is critical to be able to create a coherent point of view. Information can be of two types – qualitative or quantitative.
Qualitative information can include
- Direct conversations with individual users (around why they need the product, how they use it etc)
- User surveys with subjective questions
- Second hand information from internal stakeholders (about what they know about the market, competitors, users etc)
- Competitive product and business analysis
Quantitative information may include
- Product usage metrics (page views, avg. Session duration, app installs etc)
- User funnels data (acquisition, activation, conversion)
- User interaction metrics (Email open rates, CTRs; Push Notification interactions)
- Quantitative surveys (NPS)
- Market research (quantitative data around market size, trends, adoption, penetration etc)
Understanding qualitative information requires gauging the context and assimilating them within our frameworks correctly. Qualitative data can give us a lot of information that we cannot obtain through quantitative means (eg: a day in the life of a customer). This type of information helps contextualize the quantitative data that we might obtain from various tools. A PM should also be able to retrieve the necessary quantitative data from tools such as Google Analytics, Clevertap or from querying DB directly. Once retrieved, she should be able to build the right visualisations and come up with the right insights, which can be backed up with qualitative data. Hence, effective usage and understanding of both of these data forms are critical in making the right decisions.
Though by no means exhaustive, cultivating these qualities in a systematic way can help us become great product managers / product leaders. What more qualities can you think of? DM me on Twitter here or to write to me at tilakpattnaik@gmail.com.