 Hey everyone, welcome to today's session. My name is Akashit Mehra and I'm a Product Leader at Amazon. In today's session, I'll be giving you an overview of product management and I'll also be walking you through a lot of different types of product management roles. However, before we get into the details of the session, just wanted to give you a very quick introduction about myself. As you can see, my name is Akashit Mehra. I'm originally from Mumbai, currently living in London. My wife and I moved from Seattle to London last year. I lead payment products for Amazon Small Business Customers in Europe. Outside of work, I'm a huge Arsenal fan, so this season luckily I got a season ticket, so I've been visiting a lot of games. My wife and I are both huge travel buffs, and that was one of the reasons we decided to make the move from Seattle to London, so that we could explore around Europe. I'm also very active, I would say, on Reddit. I have about 50k karma, which obviously tells you how busy or active I am on Reddit. Lastly, I enjoy trading and investing in the stock market. One good way I figured out for people to introduce themselves is getting into two truths and a lie. The way this works is I'll make three statements about myself, two of which are true, one of these is a lie, and it's for the audience to guess which one of these is a lie. The first one is I've moved houses 12 times in the last nine years. The second one is that I've visited all the seven continents including Antarctica, and then the last one is I'm a huge one-and-buffer fan, and I once queued up at 3 a.m. to attend the Berkshire-Atmanual Conference. I will tell you the answer to this one, or I will reveal which one is a lie at the end of this session. With that, let's go into our first slide for the day, and before we actually get into our product management and the types of roles, I just wanted to give you an overview of what we will and what we will not cover in today's session. What we will cover is, I'll give you an overview of product management, what it is, and what are the different types of product management roles out there in the market, what are the similarities and differences between these different PM roles. What we will not cover in today's session is, there are a lot of product management roles, or sorry, there are a lot of other job families that often get bundled up with product management, things like program manager, project manager, technical program manager. I will not go into details of any of these roles today. I will also not compare these roles to product management. When I refer to PM in today's session, it will all be about product management and not about program or project management. What I will also not cover is the different types of PM roles that exist at different companies, meaning if a company X has types, ABC, if a company Y has types, MNO, I will not be getting into any of those details. Lastly, what I will also not cover is if there are any, like what are the different levels of product management roles like a senior product manager, a group product manager, a product director, et cetera, and how are these different to each other? I want to keep the scope of today's conversation narrow, so that allows me to go much deeper into the topics that I'm trying to cover. So who is a product manager? A product manager in my mind is someone who sits at the intersection of customers, technology, and business. What does this really mean? If you look at the chart on the right, what you see is the product manager always starts with a customer problem that needs to be solved. Once the product manager in in and understands the customer problem, the next step is then to identify a solution to the problem, typically one that leverages technology because product manager roles are usually a term that's used for software or for technology companies. And once a technology or a solution has been identified to solve the problem, a product manager will work with a bunch of folks to actually get that solution built out and in the process help the business grow. Now, let's look at a more real world example that I can use to actually describe what a product manager or help you relate to what a product manager does. Let's say you're getting, let's say you own a home and you have a kitchen that hasn't been renovated for about 20 years and you want to get your kitchen remodeled. The first thing you'll do is you'll call up a contractor. The contractor will come over, we'll have a chat with you, you'll explain your use case to the contractor. Hey, this is my kitchen, this is what I'm going to do. Here are some images of what my neighbors or friends have done. This is what I'm trying to get to and what the contractor will obviously take a note of all of those things, try to understand what exactly is he solving for, take that away, come up with a plan to actually address and solve your problem and then work with a bunch of engineers, builders, electricians, plumbers, et cetera, on the ground to actually have your kitchen remodeled and in the process, grow his or her business. Now, the role that the contractor played here is typically the role that a product manager plays as a software company. Understanding the problem, figuring out a solution, getting the solution built and implemented, growing the business. I think where product managers in software companies go a level deeper or have the opportunity to go a level deeper is to set up a lot of experimentation, lot of opportunities to set up success or set up metrics that they can use to evaluate the success and failure of a particular product or a particular feature. Learn from customer feedback and go back and rinse and repeat the process. I think with a contractor, it's a very difficult exercise to do that because it's not as agile, but because the software world is a lot more agile, the product manager has the opportunity to go, quickly learn and get feedback and go and make changes to the product. With that said, we will now shift our focus to me giving you an overview of the different types of product management roles that exist. So what are the different types of product management roles that exist? These roles can be split by customer type, meaning are they for B2C or B2B customers? Are they for internal or external customers? They can be split by the kind of phase the product is in, meaning is it a zero to one product or is it a product that's out there in the market and the aim is to grow the product? And lastly, by the level of kind of skill set required for a given product management role, meaning is it a less or a more technical product management role? Is it something where you typically employ a generalist PM or a domain specific PM? Now, don't worry if you do not understand a lot of these terminologies or if you're not able to relate to it, we have a slide on each of these that I will walk you through where I'll go into the details of how these roles are similar to each other and what way are these roles different from each other? And I'll also give you in the process a few examples of these different types of roles that exist in the market right now. Lastly, we will have a quiz where I'll give you a few examples of different product management roles and you will have the opportunity to actually guess which of these criteria or which of these types of roles that particular role fits into. With that said, let's get into our first set of product management roles for today. So these are B2C versus B2B PMs. Now, as the name suggests, B2C products are where you're building it for an end customer or a consumer like you and I, whereas a B2B product is one where you're building the product to be used by another business or employees of another business. What's the key difference between the two? When you're building products for end consumers or for people like you and I, I think what's super important to understand is that you're building something that satisfies the individual customer's need. When customers like you and I make buying decisions or any sort of decisions to use a particular product, there is always an emotional component that's involved and it's very important for the product manager to understand these nuances when building out the product. When it comes to B2B PMs, typically when you're building a product to be used by another company or employees of another company, I think what's important to understand is that the product is being built to address the company's pain points or the pain points of the company's employees. And in this particular setup, what you'd want to understand more than the emotional aspect is how does the company function? How do companies operate? What are the processes that you can help optimize in a company? And build in more practical solutions. So that's where a key difference between the B2C and B2B PM lies. Another key aspect or another key differentiating factor is the user versus the consumer. So a user, before I go into the details, a user of a product is somebody who actually uses the product, whereas the customer is somebody who pays for it. In cases typically for B2C PMs or for B2C products, the user and the customer would be the same. Let's say, as an example, I'm buying a product from Amazon. In this case, I'm the one who paying for the product, so I'm the customer. I'm also the one who will be using the product. Whereas if you look at another Amazon product, like let's say AWS, now Amazon provides AWS to other businesses as a service and typically the employees of the other companies would be using AWS services. In this case, the customer of the product will be the company or the executives of the company that will be paying for the AWS services, whereas the end user will be the employees of that particular company who will be using it. So there is a key difference between the user versus the customer, usually for B2B versus B2C PMs and that is something that a product manager needs to understand fully when making decisions about what sort of solutions is the customer looking for. Lastly, I think usually for B2C PMs, as the products grow, you will need a marketing sub team to help you grow the business. Whereas for B2B products, you will need a sales team that has a relationship with the other companies that helps grow the product and the business with the other client. Now, these were aspects that are different across B2C and B2B PMs. Some of the aspects that are core to product management remain the same across different product management roles and these are, as a product manager, you always have to understand and focus on customer needs and solving them. You always have to work with a bunch of cross-functional teams and collaborate with them and get the solution built through a lot of collaboration with different teams. And lastly, communication is a super critical aspect of a product manager role. You need to be able to convey benefits and value proposition of your product, whether it's a B2C product or a B2B product. You also need to be able to communicate very effectively and clearly with a team who you will be working and collaborating very closely with as part of building out this particular product. Let's move on to our next set of product management roles which are internal versus external product PMs. So as the name suggests, an internal product PM or an internal product is something which is being built for the employees of the company that you work for. Whereas an external product is being built for someone who sits outside of your current organization. Now where lies the difference between these particular roles is how much you focus on sort of the functional aspect of the product when you're ready to release the product in an internal product scenario is very different to an external product scenario. When you're building a product for your internal customers, let's say you're building a tool to be used by your analytics team internally. In this case, the focus will be a lot on, getting that particular product out into the hands of the other employees. And you may not necessarily focus on a lot of the bells and whistles and getting the marketing of the product right before you launch and release it. The aim and the objective would be, is there a process efficiency or an internal process that I'm trying to make more efficient with the launch of this product? If yes, let me go ahead, build the product, get it into the hands of the customer and get feedback as quickly as possible. Also getting the feedback for an internal product is much, much faster and easier as compared to an external product because typically these would be employees of the same organization. You can sometimes just walk over to their desk and get feedback or in other cases, you may even be able to set up very quick meetings with your customers and be able to get feedback on whether they're enjoying the product or not. And if not what sort of changes you would want to make to that particular product. Whereas when it comes to an external product, it's super important that, I mean usually obviously it's the company's brand name at stake as well. So you'd only release the product into the market once it's a fully finished version, something that can be marketed to the external audience, something that people may be willing to pay for, which means the cycle might be a little longer than an internal product. Also once the product is out there live into the market, it may take more time and effort for you to get customer feedback because obviously these are not internal employees or your colleagues who you're working with. So you will need to figure out channels and mechanisms and put those in place to be able to get customer feedback and then incorporate that into your decision-making process going forward. Having said that, as I mentioned previously, some of the core aspects of product management still stay the same starting from the customer, understanding their needs, collaborating with a bunch of cross-functional teams, incorporating user feedback into your decision-making process. The next set of product management roles are zero to one versus growth PMs. And this is probably my favorite slide from today's session because I've done these two different roles on the same set of products. So the zero to one PM as the name suggests is somebody who brings a new product live or in some cases even a new business live into the market, whereas a growth PM role is something where the product already exists and the responsibility of the product manager is to understand the product better, understand customer perception and feedback about the product better and grow the product, grow the engagement and adoption of the product and increase the business role. I think these two roles are extremely different in terms of the mindset required for one to do this particular role. For zero to one PMs, usually you are looking at very long cycles to get the product into the market. So you will obviously, before you decide to go ahead and actually build the product, you will do a lot of customer research, you'll try to understand what is it that the customers are looking for, what problem are you trying to solve through this particular product and then get into the process of building the product. Now, the time required for you to do that research and for you to actually get the product out into the market in sometimes could be months or even years in some cases. Like take my example in this, so the product that I worked on as a zero to one PM, the cycle was about nine months from us doing the initial customer research to actually getting the product live into the market. And as a product manager, sometimes it can be very testing for you because you obviously are not getting customer feedback on a regular basis. You are building something based on what the research you did. I mean, you could do as much research or you could do it on a continuous basis as many times as you like, but pre-launch customer research to be very honest and from my experience is never the same as the feedback or the research that you do once the product goes live into the market and you get the true feedback from people who are actually using or trying to use your product. So zero to one PM does require a lot of patience. It obviously requires a lot of innovation because you don't, in some cases you may not have other comparables. You obviously don't have a product right now. So you're trying to build and design something from scratch and certainly a lot of risk-taking because I mean, you don't really know how the product turns out. It could turn out to be great. It could turn out to be not so great and you wouldn't know it unless the product actually gets into the market. For a growth PM, however, I think again, the mindset is extremely different. As I said, for the product that I launched as a growth zero to one PM that took about nine months to launch, I was then responsible for growing the product and growing the adoption and the business through it. Now, I had to actively condition myself to change my mindset because once the product is launched, you are trying to move much, much faster. What you want to do once the product is launched is try to get as much customer feedback, real customer feedback about the product as possible because customers can now see your product and use it and give you feedback. You want to be able to track and manage as many metrics as possible to be able to understand what's working, what's not working. You would want to do a lot of experimentation because experimentation is an idea, gives you a good idea of, okay, this is something that works, this is something that not works. You're not trying to overanalyze or over-optimize things in your head. Instead, you can put things out there, let the customers try out both things and then you get customer feedback around which one works better, which one doesn't work better. I think in this case, the mindset required is you need to be able to move very, very fast. The focus is a lot more on optimizing and scaling because when you're obviously in the build phase and the zero to one phase, there isn't a lot of revenue or growth pressure on you. The focus is on, how do I get this right? How do I build this right? And how do I get into the market as fast as possible? Whereas once the product is live into the market, it's then obviously a fully functioning business. There is a lot of stakeholder management. There is a lot of leadership review that you need to go through where there will be questions around, hey, why is the business going? Where is the business going to land in the next three years, five years? How can we improvise the growth? How can we grow faster, et cetera? And this is something that you need to be able to answer and address and have a plan for as a growth product manager. Once again, I'd say the core aspects of product management stay the same, customer, collaboration, communication, nothing changes here. You need to be able to do all of these effectively no matter what sort of product management role you are looking at. I mean, the extent to which you may do one or the other may change a little bit, but largely the core product management aspects stay more or less the same. The next one is less technical versus very technical PM roles. Now, you would notice that I'm using the term less technical and not non-technical because in my mind, there doesn't exist a non-technical product management role. As a product manager, you will always be working with technology at some level. You may not have to go into the weeds of the technology if you're on a relatively less technical product, but you will have to have a fair degree of understanding of technology and how you can leverage technology to improve the experience and the product for your customers because otherwise, otherwise you may not be able to apply technology to the extent that you may want to or there may be technology out there that you are just not aware of simply because you're not so much of a technical product manager. Now, in this case, I think where the difference lies between the two roles is I would say how closely or to what extent do you get into the details of technology typically for less technical product roles. I would say the focus is a lot on bringing in the business strategy, focus is a lot on bringing in the user needs, solving the problem of the customer using technology, of course, but not necessarily getting into the details. Whereas for a technical product manager, usually you're looking at products that will be used by other folks who work very closely on technologies. So let's take an example of where the product itself is an API. In this case, the API or your customers will typically be engineers. So unless you are someone who is very technical or have a good deal of understanding of how technology works, it will be very difficult for you to build a successful product that is actually being used by engineers who are obviously a core part of any software company. So this is where you need to understand. And again, I wouldn't say one role is necessarily better than the other. It's a function of what you've done in the past, where your strength and core competencies lie, and that's where you're likely to be more successful. And this holds true specifically for people who are trying to move into product management. I mean, if you're in a technical role, but not a product management role, you might want to consider moving into a technical product management role because you may not necessarily have the product jobs to bring in on day one, but you at least have a lot of technological tech knowledge that you can apply to product management as a new product manager. Whereas if you're coming in from more of a strategy role or someone who's worked very closely on the business, one of the few business roles, in that case, you may want to try out a less technical PM role because the tech aspects of product management is something that you can learn on the job, but where you can start contributing on day one is the business of the strategic aspects of product management. Now, again, the core aspects of product management remain unchanged, customer collaboration, communication, no changes whatsoever to any of these, no matter what sort of product management role you're looking at. The next one is a generalist versus a domain specific PM. This is probably my second favorite slide from today's session. A generalist PM is somebody who has a lot of product management skillset, has done product management for a long time. Is somebody who is comfortable using their product skillset and product knowledge, applying it to different contexts, different industries, different domains, being able to learn quickly, adapt to the environment and use and successfully build products across, as I said, different industries and domains. Domain specific PMs would be relevant in certain industries where the product that needs to be built requires or will benefit immensely from the product manager having a lot of technical, a lot of domain specific knowledge. As an example, if you're building a product that will be used by lawyers and something that goes into the details of legal, how lawyers work, how lawyers do their business, you would typically want someone who has worked in that particular industry who has a lot of domain knowledge that can be applied on day one and help make the product better. Now, again, coming back to my point, one is not necessarily better than the other. I think if you're somebody who's trying to move into product management, if anything, I would say a domain specific PM role may be a good opportunity for you because if you have a lot of expertise working in a specific domain and you see an opening for a product management role in that specific domain, it may be a good opportunity where on day one, you bring in your domain specific knowledge and skill set and on the job, then you have the opportunity to learn more of the product management skills. Once again, I would say from the core aspects of customer strategy, collaboration remain more or less the same, no changes here. And this is something that every PM, no matter what they do, will have to focus on and bring to the equation. Now, having gone through a lot of these different types of product roles, just wanted to sort of highlight what, and I know we discussed this through each of these slides, but just wanted to summarize, no matter what the product role, what are some of the core aspects of product management that stay consistent across these different types of roles. First one and the most important one is the customer. Every product management role starts with having an understanding of customer needs and then the product manager taking those needs and trying to identify a solution to a very complex problem. As part of this, the product manager would want to leverage technology and then by building the product, obviously would want to help grow the business and then reinvest into making the product better for the customers. As product managers build these products, they would have to collaborate with a bunch of cross-functional teams, understand their languages, communicate effectively with customers, with leaders, with a team, experiment and move fast, learn, analyze, rinse and repeat is I think the motto for every product manager. Now with this, we then get into the last section of today's session, which is we'll do a simple quiz where I'll give you three examples of product management roles and would ask you to fit these product management roles into one of the categories that we learned today. The next slide is where I have the answers and I'll walk you through my thought process and share my thoughts on what categories each of these roles fits into. The first one is developing a revolutionary learning app from scratch to cater to people moving to a new country. Now, is this a zero to one PM role? Is this a growth PM role? Is this a B2CP PM role or is this a B2B PM role? We'll obviously know and learn about the answers on the next slide but feel free to guess or take an attempt before we get there. The next one is leading the development of an AI powered diagnostic tool for cardiologists. Is this a less technical or a very technical PM role? Is this a generalist PM role or a domain specific PM role? And then the last one is creating an analytics tool to be used by the marketing employees of the current organization. Is this an internal or an external PM role? Less technical, very technical PM role. Let's get into the answers and our last slide for the day. Now, developing a revolutionary learning app from scratch. As the name suggests, right? You're building out something from scratch, very likely and obviously in this case is a zero to one PM role. The product doesn't exist which is why you're building something out from scratch. You're building out for people who are moving to a new country meaning you are targeting the end customers so it is a B2C app and not a B2B app so it is a B2C PM role. The next one is leading the development of an AI powered diagnostic tool for cardiologists. Now, because it's an AI powered diagnostic tool I think the product manager in this case will have to have a very deep technical understanding of the AI algorithms being used of the infrastructure decisions being made because it's a very tech heavy product and the tech decisions here will have a significant impact on the end product and how the end product is usable to the customers. So it is something that requires a deep technical expertise and also I would say domain specific knowledge is something that would make this product really successful because if you work with cardiologists or with doctors in the past you can bring in a lot of domain specific expertise that may be a general SPM may not be able to bring to the equation. Lastly, creating an analytics tool to be used by the marketing employees of the current organization as the name suggests or as the description suggests this is something that you're building internally for your organization so it is an internal product management role. As I said, no product management role is a non-tech role. It's less technical or very technical. I think this is one where you don't necessarily need a very technical product manager. The end customers are marketing employees. You'll be working and building an analytics tool. Of course you'll have to work closely with engineers but you don't necessarily need deep technical expertise to be able to build a product of this kind. With that said, I'd like to thank everyone for joining today's session. All the best for the future and thank you. Bye-bye.