 Hi all. Welcome to this session on six underrated responsibilities of product managers. I'm Bhushan Mughal. I'm a product manager at Google. Let's get right into it. So a little bit about me. I started my career as a software engineer, switched to PM product management at a startup, and for the past almost about three years, I've been a PM at Google. My background for the most part is in the data and analytics domain. Specifically, cloud data analytics and a large portion of my experience has been in the P2B business. About my journey as a PM, it's been a fun ride, but it has come with a steep sort of ongoing learning curve. Mentors have helped me navigate this learning curve as well. And based on that experience, I am also passionate about helping other PMs and prospective PMs as well. And a fun fact about me is I love memes. Pictures work a thousand words. So you'll see some of that during this presentation as well. So about the session today, we'll run through a little bit about why product management sometimes seems like an enigma, often misunderstood as well. Then we'll jump straight into the main topic of today, which is the underrated responsibilities, or they could also be core competencies or skills that a great PM brings to the table. And then we'll get deep dive into each one of them and then a few links for a follow through. So product management, we all know that it's an extremely critical role in the industry today, especially in the tech industry. But it's also very often a misunderstood role. There is an overall sort of general understanding of what a PM brings to the table, what are their roles and responsibilities. But there is often a lack of clarity. There is a tendency to oversimplify. A PM defines what to build, when to build it, and that's what they do. There's a lot of misconceptions and myths about this as well. A whole lot of industry experts have written various articles on myths about product management and tried to debunk them and provide actual evidence as well. And then along with that, there is a topic of today as well, which is there's a lot of responsibilities or core competencies that a PM should have that are often very underrated. People don't talk about them as much. And that's the topic of today's discussion. So what are these core competencies or responsibilities that I'm talking about? Their nature is very subtle. They're hard to notice. You sometimes take them for granted. But a PM is actually putting in a lot of effort in order to do those parts of his job as well or their job as well. These responsibilities are also understated. Not a lot of people talk about them. They're also complicated. They involve making hard decisions. Think they may also come across as harsh. Very difficult to navigate as well. We'll talk about some of them as well. And then in general, there is a sense in the industry that a PM is a very glamorous role. But some of these responsibilities that we'll talk about today are also very non-shiny, very non-glamorous. And then because of all of this, it might seem a little bit daunting, but there are ways to navigate all of that as well. But having said all of this, these responsibilities are extremely critical and go a long way in making a great PM. The other thing that I'd like to talk about a little bit before we jump into the responsibilities is that these may vary. A PM is in general, problem management is in general a very fluid function. It can vary from industry to industry. It can also vary based on company size. It can vary based on the business that you are in, B2C, B2P, etc. So some of these responsibilities may appeal and be more important in one of those areas and not the other. So take them, not every role is the same. So let's jump into the first one. So there is this conception in the industry widely that a PM's job is to keep building new things, keep proposing new things, keep defining new things, figure out what to build next always and just steer the whole ship across functionality towards those goals. They are also expected to be very, very visionary. They're supposed to think about the future, where the industry is going, etc. But what was unnoticed is in between all of this, a PM is continually making incremental progress. There are certain laid out vision strategies, certain features that the team has embarked upon. And towards those things, an essential part of the PM's job is also to ensure that incremental progress is happening. That the needle for the user in those known scenarios is moving in the right direction. The user's life is, customer's life is improving in those existing features and capabilities that you've already defined it. Let's talk a little bit more about incremental progress. There is, like I mentioned in the beginning, there is a tendency in the industry to focus solely on the next big thing always. That's also how you would find back in the day, even PMs have judged their performance is just based on how many launches they make, what big splashes they make, etc. And as a result, there is a tendency amongst PMs to keep proposing new features and building new features. There's also a massive feature for more, as I talk about it, what if I don't build and what if my competitor builds this, right? I may lose out on a market segment and a portion, etc., right? But having said all of this, one thing is also true, which is customers and users expect some sort of consistency as well, right? Once you've given them a set of capabilities, they want to have an assurance that you're with them on that journey. When they use that capability that if they run into problems, that you will be there to support them as well as that specific capability that they are using keeps making progress over time as well. It cannot be stagnant. So what happens a bunch of times is also, there is this, what I like to call as throwing across the wall sort of mentality, which is I think as a team, as a product manager, even or as a company, you're building features and throwing them across the wall, the customer, right? Without, and then, immediately moving on to the next big feature, right? This can have, due to the reasons I've mentioned before, an adverse impact on customers, but more importantly, it can also impact your own product teams more, your own engineering teams more all as well, because they're constantly doing the switch between different features and capabilities without actually realizing how the work that they do makes a difference to the life of a customer, right? It also creates hodgepodge and Frankenstein type products where it just seems like a whole bunch of features have been thrown together without clarity on what the product needs to be. Triggers positioning problems can have a very negative impact, right? Instead of one of the characteristics of a PM is that they know that ticket items can come, you know, few and far in between, but in between those, they will iterate constantly on customer feedback, right? They make incremental progress. And then by doing so, they will ensure that the things that they propose and define and ultimately end up building create sustained value for users and not just, you know, in the immediate future, but over a sustained amount of time, right? So how do you go about doing this, right? We'll talk about this in some of the future slides as well, but the key job of a PM is to establish the rationale for every single feature. Product discovery, as they also spoke to speak about, is extremely key. And it doesn't have to always play a major role only when you're launching a net new product. It could happen for every feature as well. So before you embark on a feature, a PM must have sufficient clarity on why it is being built, what problem it is solving, why is it necessary to build it right now and why should we as a product team be building it and why not someone else, right? They should also be concerned about whether we as a team have the capability whether it is feasible for us to build it, whether we have the skills, whether it is in our product's vision to build it, right? And once that is established, whether we can put a stake in the ground and say that we will have a continued investment in this capability over a sustained period of time, right? So the reason why this is important is also it also enforces that frequent changes, if you continue to make these frequent changes, they can also indicate a lack of focus and direction and again have that adverse impact on both your customers and your productivity. And so it is a PM's job to keep not only customers but also their management team as well as the product team that they work on focused on a set of objectives for a sustained amount of time and keep plowing through iterating in that direction for a sustained amount of time, right? Cool. So let's move on to the next one, slightly related to the first one as well but a little bit more focus on that rationale, that justification, right? So there is a misconception also in the industry which is it is a PM who comes up with all the ideas, right? Which is couldn't be further from the truth, right? But what is definitely true is a PM does bring the rationale for every single idea that is their core competency that is what they bring to the table that is their foremost responsibility. They need to know why a particular thing on their roadmap why a desired outcome is important for the product to achieve, right? They may not be the source of all the ideas but they certainly are responsible for the rationale. So the way I look at it is there are three components to every feature capability product, right? Why we are doing it? What is it? Which is the solution itself? The why is the problem? The what is the solution? And how is essentially, you know, how you're going to solve that problem, right? The actual implementation. So while the ideas can come from customers, they could come from stakeholders, partner teams, product teams, et cetera. It is a responsibility of the PM as to no matter where the idea came from. They must establish why that idea is important. Why is it important at a particular point in time? And why is it important for this particular product to work, right? And it's not just about having this concrete picture in their minds. It's about also communicating that and having consensus, building consensus about it as a whole, right? Across this entire spectrum from customers to stakeholders to the product team and having them focused on this, you know, giving them the clarity that is needed for them to be focused on this detection. So the way that typically product managers do is actually this is have, you know, a great story about the rationale of every single functionality or capability. And then, you know, move on to sort of communicating that in using, you know, exemplary communication and negotiation skills to the product team, to all the stakeholders. And you do that based on, you know, the why that you've already established and the data to back that as well, right? And the idea is unless you have this, unless you have the why established, do not move on to the actual solution itself. Do not move on to how that comes after the why, right? So there's also a way to look at the rationale and the justification and the why as an essential part of what we call as the product discovery phase. And then it is absolutely paramount that the PM does a thorough job, leaves the team, you know, engineering can participate, UX can participate, documentation can participate. But as a team, you establish the product discovery process and only after you've made sufficient progress in that you have absolute guarantees that yes, this makes sense. That is when you move to designing the solution, right? There's a great book in fact on this by Simon Sinek called Start with Why. I highly, highly recommend that I have given to you. So the next underrated responsibility is there's this notion again that PMs decided what to build next always, that's their focus. But one thing that goes unnoticed is a PM needs to pay an equal, if not even greater attention to what exists in the product that maybe doesn't make sense today, right? And there's far reaching implications of that. There has been a radio focus on this off late at large companies because, you know, ultimately this is what drags entire teams down. So let's talk a little bit more about that. So we've all discussed before it. Customer needs and market conditions are very fluid, right? What is true today? The sense of the world as it stands today may not be true one year from now, two years from now, et cetera. So it is extremely important to have a tab on the capabilities in your product, who is using them, how much are they using them? Are they important even today? Because again, a lot of product management is about decision making, right? What do I build? How do I build it, right? And you make those decisions oftentimes based on point in time information. What do you know today? That point in time information may change in the future. So you need to be able to capture all of your decisions and then be able to go back, correct things as well, right? So like I said, things that provided value, substantial value today may not provide value a few years down the line, a few months down the line. And it is crucial for a PM to maintain a tab on that. There's also a very hard thing to do, right? It's a hard decision to make to stop a feature. Not only hard about how to communicate this to your team, but even harder about, hey, how do I go about figuring if your users are still using it, right? Even if a small number of users are using it, how do I focus on steering them away from this into something that is much better for them perhaps, right? So those conversations are very critical. This is why communication is such an important aspect of product management, right? And if you get this aspect of shedding dead weight, if you have a good tab on this, there are a lot of benefits and hopefully you will see that product managers really get a lot of recognition if they do a good job of this, right? Because at larger companies, for example, this has the benefit of consolidation. Sometimes when you decide that when there are a lot of parallel efforts, you sunset some efforts, let someone else take that, right? And in general, lead to consolidation, resources, et cetera. There's also an even bigger thing here, which is an even bigger benefit of this, which is you keep a tab on the tech and product tech in your product, right? And you'll get appreciation across the board from this, right? You will have that sense from the engineering team, especially, it's very important here, is where they will have a sense that you are a trusted partner. You think about their objectives as well, right? So that's why this is critical as well. And then in general, it keeps your product surface area under check, right? It ensures that you don't blow up into Frankenstein types of products where you would just throw in features together, right? And how do you go about doing this is there are essentially two things, right? One is you need to have sufficient metrics in order to understand the usage of your product and it has to be sort of as granular as humanly possible, right? Which is collect as much data and then spend a lot of time sort of reading through that data and gathering insights from it around the product usage, et cetera, right? And then once you establish that you need to think about certain features and discontinuing them, then you need an immense sense of empathy. You know, customers may have invested a lot of time in those features, even if it is important to a single user, a single customer, you need to tread that path very, very carefully, ensure that you have the best interests of the customer in mind before and you guide them through sort of a process by which they transition into, you know, something else, for example, right? So as long as you handle those two, I think this is something that that a PM can do a good job at. Let's talk about the next thing here, right? Which is, yes, a product manager represents the voice of the customer, but more importantly, you know, what great PMs do is they develop this relationship with their key customers where customers think of them as their trusted advisors. They rely upon your world, you know, they put great value to your world, your opinions, and this is done even at the highest levels at the customer itself, right? And this is very, very useful because this then, even when you have to sort of walk away from a certain requirement from a customer, for example, the customer has that confidence in you that you're actually doing the right thing and guiding them, right? So let's talk a little bit more about this. So one of the things that is essential for every PM to understand is that the success of their product, which is what every PM shoots for, right? That needs to be a byproduct of the success of the customer. It cannot be the other way around, right? When you have conversations with customers, those conversations have to be focused more about the customer and their problems than, you know, just about your product, right? You have to have that, and it is actually important for you not to just do this, but for the customer to know that this is your thinking as well, that you have a keen interest in solving their problems and not just in sort of selling a product to you, right? Or releasing a new feature to you, right? So how PMs usually do this is, you know, a lot of the conversations are focused on customers and their problems, right? In these, you know, sometimes this may be difficult, but some PMs also go to the extent of observing the customer, you know, go about their work, their date of life in their environment, right? This may not always be possible, like I said, but it's important to notice, you know, sort of empathize with the customer, understand where they're coming from before, you know, sort of only telling them about your product and your solutions, right? And then cherry picking those problems which make sense within the context of your product and translating them into, you know, solutions that make sense within that, within that product's context, right? It is very, very important here to not, again, a hidden aspect here is sometimes you will have conversations with customers about, you know, this is especially when customers have already been using your product for a while, right? That they'll say, hey, you know, what if you implement a particular feature exactly this way? They are actually proposing a solution, right? And a PM has to have the conviction in those kinds of scenarios where let's focus on your problem, right? I can come back to you later with, you know, a proposed solution and then we can discuss that, of course. But let's focus on the problem, let's get that out of the way first and then have a subsequent conversation about the solutions, right? And you may also end up in situations where you have to say no to a solution that is proposed by a customer because it may not make sense in the product context. But which is why it is very, very difficult essentially to have a keen handle on the problem first, right? And then as a result of all of this, if you show this empathy, one of the aims of this is that customers see you as a trusted partner, a voice of reason, put a lot of weight behind your thoughts, etc. And then there are a lot of benefits that product managers can derive out of such mutually beneficial relationships, right? Especially in the B2B world, for example, you can get reference customers who can be your voice in the field looked at by two other customers, right? They can, you know, do the evangelism of your product for you. You can also trust customers for early feedback if you're looking for feedback on a new feature that you're trying out. Poor man's A-B testing, for example, but with real users, right? Perhaps even more important. And then you can also withstand headwinds where, you know, if a product is not doing as well as it, functionality is not working, it's causing issues at a customer. The customer knows that as a PM, you're with them and they can trust you. And therefore, you know, avoid any headwinds that may otherwise occur. And then we already discussed how part of this relationship is also that a PM has the ability to say no, and that's one of their key responsibilities as well, especially when, you know, you get into a solution in conversations for a variety of reasons, right? Lack of critical mass, not fitting into the overall vision of the product, et cetera. But even when you have these difficult conversations with customers, because you're a trusted partner, customers will be willing to have those conversations. Let's move on to the next one, right? There's another one where I have a lot of personal experience to share as well. So a PM's job is to influence and negotiate with stakeholders, influence your product team and steer them towards a common goal, motivate them towards a common goal. But sometimes what happens is, and for good reason in some scenarios as well, right? Which is there are a lot of functions that PMs work with, documentation, engineering, user experience. But PM might feel the urge to actually fill in one of those functions as well, because they want to be a team player, right? And my take on this is to proceed with caution. And here are some of the reasons why, right? So like we discussed, the PM is sort of a leader of a cross-functional team, right? They have a lot of responsibility. They don't have direct authority over that team, right? Their job is to influence this cross-functional team and influence their roadmap, right? Influence their priorities and negotiate with them towards a particular goal. You do that using data, you do that using justification and evidence, all of that good stuff, right? Because they interact with all of these teams, they have sort of a high-level knowledge of all of these functions, right? They have engineering documentation, user experience, support, marketing, legal. And what happens is because a PM is a highly motivated individual, sometimes when one of these functions may not be coming on board because they have other priorities or because there is a lack of resourcing, a PM may think that it is their job to fill in that function. They want to be a team player. They want to make progress. And I've done this in the past, right? Like I said, my background is a software engineer. I have a tendency where, for example, a customer issue comes from a high-priority customer. I want to not disturb my engineering team. And this used to be me a couple of years ago, right? Which is, let's not sidetrack the engineering team. Let's keep them focused. Why can't I step in and build out the future, right? Or build out that bug fix or whatever that is, right? For what goes sort of, again, underrated is the term, is it's not about fixing something and giving it to a customer, right? Or it's not about building a future and giving it to a customer. It's about what happens later. Can you support it for a sustained amount of time? Can you, is there a repeatable solution? If the customer has a problem with something that you've developed, do you have resources to handle those problems, right? Is the problem that you're working on even important at the point in time, right? And there are a lot of perils to the substitution, right? So like I said, from my example, I clearly remember this one situation that happened to me, which is, you know, I went in, implemented something, sent it to the customer, worked fine, right? A few days later, a few weeks later, discovered that there was an unintended side effect from that. And the fix for the side effect, unfortunately, was like we call as a blocker issue that required a lot more investment than the original bug fix itself, or the original fix itself, right? And so now I have to actually, you know, reprioritize a larger chunk of my learning resources in order to get this high priority fix out of the way, right? So essentially, I think what happens in these scenarios is, one, it is taking time away from your data, the job, right? This is not your core responsibility, right? It could lead to substandard results because that's not, you know, your primary skill set as a PN, right? It can also lead to solutions that work like classic case, the example that I mentioned, right? It can also work, you know, at a point in time, it can also work a problem. But unless you have some sort of support plan, the repeatability, right? As to who is going to handle any request that comes from customers about the thing that you, you know, substituted for, it's going to be a problem, not just for you, but for your larger product team for customers as well, right? One of the other, perhaps even bigger sort of side effects of this is as a PN, you might give the feeling to your cross-functional team that there isn't so much autonomy, that you're actually going and doing their job, right? And that can have in some scenarios an extremely drastic impact on team morale, right? So you have to be very careful, right? But having said that, it is a reality of times, especially in smaller companies, especially in new initiatives at larger companies where you may have to substitute as a PN. My advice when you do that is proceed with caution. Make sure that you have a long-term plan. Once that is in place, a temporary effort here and it might be good. But also take your team into confidence and make sure that they know that you're doing this and we're adding this to the product and then the whole cross-functional team is to support it. And the last one for today is, so we've spoken a lot about a PN's job towards their product, towards making their product a success, making their customers successful, etc. The last one is more about you as PN's, right? Or all of us as PN's, right? A PN is not a 9-to-5 job. And I want to be very careful when I say this. The beyond 9-to-5 aspect of the job is not necessarily for your product. It's not what earns bread and butter for you, but it's what sets you up for bigger and brighter success for growth in the future, right? So let's talk a little bit more about this, right? So we've discussed so far that product management can be a complex and high-pressure job, right? There's also a depth of education. There's not a lot of courses on product management, right? That's slowly changing, but you don't get out with a degree in product management typically. There are certifications that have started now. Product school has started something, but that's all very recent, right? So, and then in the role itself, there is a lot of fluidity. Each industry has its own way of product management. Each business type has its own way. A startup has its way versus a large company has its way, right? And so it all, you know, the role itself can be a kitchen sink of responsibility. Say if something cannot be done by a different team, by a different function, or maybe it's a responsibility of the PM, right? That's also the tendency. How great PMs navigate this, you know, these responsibilities is with an insatiable urge to learn, right? And what they do is, you know, beyond their day job, right? They invest in their career, right? They invest in learning. They invest in keeping up-to-date with the market, the domain that they want to excel at, et cetera. They invest in personal growth. You cannot only rely upon organic growth from your day job to grow as a PM, right? You may have, you have to invest in yourself, treat your career as a product itself. You have the skills of product development and product management, right? Apply them to your career, right? Focus on personal growth, spend time on market watching your trends, new business opportunities, right? This is outside, you know, what you do day to day, right? Domain knowledge, again, very, very important, depending on what domain you are in. You may want to spend time as to what, to get a better understanding of that domain outside of your product, right? These days, this has become a little easier. There is no depth of information on the internet. There are lots of certifications, lots of product management journals, publications, lots of key personalities on the internet that you can follow and, you know, get a lot of knowledge from. There's a lot of blogs. Twitter is great. Slack is great. But above all, what my recommendation would be, get a mentor for yourself. That is, it is... I cannot say this enough. It is extremely critical. And the other side also, once you feel like you are in a good place, think about getting to the other side of the table as well, be a mentor, share your knowledge. You know, that also helps you grow, right? So essentially invest in yourself. So that was it for today. Here are some links that I really, really found interesting, not just in relation to the stock, but also wider, you know, implications to product management. And some of these have made me, I feel, a much better product manager than I was a few years ago as well. So yeah, thanks for listening in today. It was great sharing some of these tidbits with you. Hope you found it useful. Have a great rest of your day.