 Okay. Hi, everyone. I'm really excited to be here with you today and talk a little bit about how to choose the right PM role for you. This is a conversation that I have with a lot of new PMs, aspiring PMs, PMs early in their career, and I'm excited to be able to share some of that knowledge with you here today. In terms of what we're going to cover today, first, I'm going to tell you a little bit about myself, so you have some context about who I am and where I'm coming from. Then I want to zoom out and talk a little bit about what exactly the PM job is to deconstruct some myths about it. Then I want to talk a little bit about some of the different factors that go into the PM job to help you conceptualize what are the different areas that you should be thinking about when selecting a PM job. Then finally, I want to leave you with some concrete questions that you can ask yourself when thinking about the next PM job for you. Let's get right into it. I'm Ani Mohan, and I spend most of my time today as co-founder and general manager of Game Snacks. We're building a new gaming platform for first-time internet users in countries like India and Indonesia and Nigeria and Mexico where users are coming online to the internet for the first time on primarily mobile devices, on flaky networks like 2G and 3G networks. The business is being incubated out of Google's new business incubator called Area 120. Prior to that, I was a product manager on a couple different teams at Google. Most recently, before Game Snacks, I was a product manager on the Google Chrome team where I was working in a very developer-facing role. We were building new APIs for the web platform. Prior to that, I was a PM on the Android team, which is a much more hardware-centric role where we're building new Android devices for users in India and Indonesia. I've had a few different experiences on my career, working on consumer products, developer products, hardware products. I've worked on multiple different team sizes as well, and I've worked with a bunch of different functions, engineering, design, legal partnerships, operations, and have you. I want to use some of those experiences to help highlight to you how the role varies in a bunch of different contexts. What I want to talk about next is a little bit about the PM role itself. As you all know, PM stands for Product Management, but I think the name Product Management is a bit of a misnomer for what the job actually is. Let's dive into that a little bit. First of all, when you're early in your PM career for the first few years, you're not a manager. You are unlikely to really have people reporting to you, most of the people that you work with, and even the folks who might be reporting to you over the course of your career end up being other PMs. Whereas in reality, I mean, you're working with folks from across the entire org, folks in engineering and design and partnerships and marketing and sales and so many different functions where folks don't actually report to you. That's one piece of it that I wanted to debunk because you're not officially a manager in large part, especially in the early days of your career. Secondarily, you don't actually in practice spend as much time to keep out the core product as you might think you might. Often when people first discover the PM role, they think they spend a lot of their time on whiteboards with engineers and designers coming up with new product features and envisioning what the next great product will look like. While that's certainly part of the role that's only a very small piece of it. I actually think both parts of the job's name, product management are both a bit of a misnomer. Ultimately, what the PM job really is is about influencing people to build the right things for the company. I really want to highlight the people part of this job. The PM role at the end of the day is a highly people-centric job and it's a job where you need to constantly influence people. You might not have official authority over in order to ultimately build the right things for the company. With that in mind, with that framing of what the PM role is like, what are some of the different ways that the day-to-day job could be impacted? I like to pose this question as thinking about, what are the key factors that actually matter when taking a new PM job? There's three in particular that I want to talk about today. Here they are. The first, the lifecycle of the product. Where in the project trajectory, where in the lifecycle of all the different stages of a product that a product could be in, is your team operating in that has a very big impact on the types of activities and the types of jobs that you actually perform in the PM role. Second is the team size, just very simply, how many total people are you working with? Then third are the functional stakeholders. Who are the types of people that you're actually interacting with and what parts of the company's functions are they coming from? We'll dive into each of these in a little bit more depth. Let's start with the product lifecycle. Now, I think the way to think about this is, there's many different stages that a product could be in over its lifecycle. In the very early days, it just starts with an idea. Most of the work in those days is around actually getting support for that idea, and getting funding for that idea within the company. Are the executives on board with it? Once they are, are they actually willing to put headcount and dollars behind that idea? That's the first stage, the funding stage. The second is once you actually have the idea funded, you have support from the executives, you have headcount that's available, you have dollars available for you to spend towards the product, actually building the team. How do you get people to actually get excited enough to want to work on it? Then after that, it's about finding product market fit. You have funding, you have the people in place, but do you actually have a product that end users want to use? I think this is the part of the PM job that a lot of people think about, that involves a lot of the core product work. But as you can see here, it's only one small piece of the overall puzzle of where a product might be in its lifecycle. After product market fit, a lot of the effort tends to be around growth. It might start with focusing on actually growing the user base or the customer base. Then finally, growing the actual revenue. How do you convert all of that user growth and that great product that you built into revenue for the business to ultimately drive the business forward? Because that's what your job is at the end of the day. That's what I think about the different stages that a product might be in, and what I call the product lifecycle. Based on where your project is in this lifecycle, the types of activities that you're doing might look very different. In the early days, when you're focused on actually getting your idea funded, a lot of your job is going to actually involve storytelling and pitching. When I started working on GameSax three years ago, I would spend 50 percent, it's about more of my time, putting together a vision of what GameSax could be, why is building a new gaming platform actually compelling for Google and spending time with people across the company from many different parts of it to get support for it, to get excitement for it. A lot of that time is spent, like I said, storytelling and really thinking about what the product might be and why it might be compelling to different parts of the company. Then once the idea is actually funded and you're starting to build a team, a lot of your time is going to be spent recruiting. It's interesting because a lot of the recruiting activities actually share a lot in common with the pitching activities. It's still very much about getting people excited about what you're doing, that storytelling, that painting a vision for what's possible if people work with you, but the audience that you're focused on is very different. In the early days, you're probably focused on bringing engineers and designers on board to want to work with you and your engineering counterpart to choose to work on this project over all the different things they could be doing. But if you're excited about trying to get other people on board to actually work with you, then this is a great stage of a project to want to join, to really focus on those recruiting activities. Then once you actually have the funding and the team in place, and you're focused more on the core product development work, the types of activities that you start doing end up shifting again and tends to involve a lot of qualitative analysis. In the early days of a product when it's not very clear who the customer segment might be and who exactly it's being built for, a lot of the work might be spent, and a lot of the time might be spent actually talking to users to brainstorming different versions of the product and building prototypes of them, working with designers to build different types of mocks that envision different ways that the products could live and actually putting those in front of people, getting their feedback, really listening to them. And so if you're someone who really cares a lot about spending time with end customers and hearing from them in customer interviews and user research sessions, this is a great part of the product lifecycle to be focusing on. And then finally, if you're more focused on the growth parts of the product, so if you're focused on growing users or growing revenue, a lot of the work tends to be more quantitative and analytical in nature. You start thinking about scale, and once you operate at a certain level of scale, you can no longer rely on these types of qualitative signals to really tell you if you're going in the right direction. You're probably spending a lot of your time working with analysts, diving through data, maybe writing SQL queries, and maybe digging through Google Analytics or Mixpanel to see how users are actually using your product to develop quantitative arguments and refine kind of your quantitative sense for why the product is working. So clearly you can see as you're in different stages of the product, the headspace that you're in and the types of activities that you're doing vary a lot. It sort of roughly evolves from more storytelling, which is what it looks like in the early days, to qualitative analysis, to then quantitative analysis. And different people are interested in different parts of this. And so I would think a lot about sort of which types of activities resonate the most with you and how you can find a product in the appropriate stage of the product lifecycle so that you can maximize the chance that you're doing that. So that's the first factor, the product lifecycle. Now, let's talk about the team size. The actual number of people that you're working with on a day-to-day, week-to-week, month-to-month basis very much changes, again, the types of activities that you're doing. And so there's a very simple way of conceptualizing this. This is literally what is the total number of people that you're working with. It could be as few as two. Again, when I started working on GameSax, it was just myself and my co-founder. I came from a product background. My co-founder came from an engineering background. It was just the two of us in a room for three or four months. And then as the team has grown, we're now seven people. We're much closer to that five to 10 bucket and the nature of the team has changed quite a bit. And the types of activities that I find myself doing has changed quite a bit as well. And then of course, teams can be much bigger, especially in larger companies. You might be working with 10 people, 20 people, 50 people. Think back to my Android PM days when I would work with teams of 50 or more people from all around the world across a bunch of different functions. It's funny over the course of my career, I feel like I've progressively gone towards smaller teams, but it's not always the case. People can go in other directions and the types of activities that you do, again, change quite a bit. And let's make this a little bit concrete. What do I mean by that? When teams are sort of in the smaller stage, two to five, again, you spend a lot of your time kind of doing storytelling, pitching style activities. Because a big part of what you're trying to do is gain support within the organization for more people wanting to come and join you so that you can actually turn your vision into reality. Depending on what type of environment you're in, beyond pitching, you might spend your time doing a lot of actual building as well. When it was just myself and my co-founder in the early days of Game Snacks, I was actually writing code. I'm not a formal engineer. Kind of, I studied engineering in school. I hadn't worked professionally as an engineer, but I had to do whatever it took to get the product off the ground. And in that case, it actually ended up involving writing code and making mocks and building the product. And so if you like actually getting your hands dirty and doing a lot of the IC work, if you like actually doing the end building and you like sort of pitching, then operating at this stage of the team size, where it's relatively small, two to five people can be a great place to focus on. Then as the team starts growing a little bit, let's say you are five to 10 people in which case maybe your team of yourself is the product manager, maybe one or two designers and maybe seven or eight engineers, you have a lot of different things that you could be working on. And a big part of your job as a PM is to actually think about how do you make sure that the team is working on the right product at the right time and is moving in the right direction? You can't rely as much on ad hoc communication. And so this is where a lot of the job ends up becoming, writing product requirement stocks, PRDs, which is the canonical artifact of the PM job, where you spend a lot of your time thinking about how the actual product works and how you can articulate it in a way that builds consensus and gets everyone on board across the design and engineering functions to understand what the purpose of the product is. So if you like really thinking about what the core product does and how it works, then spending your time sort of focused on writing product requirements docs would make a lot of sense. And this team size is a great sweet spot to focus on where you'd be doing a lot of that type of work. Then as the team starts scaling a little bit larger to let's say the 10 to 20 range, now you might be thinking about multiple engineering teams, maybe two or three engineering teams, each of which has five or six people, maybe two or three different designers for each of those projects. A lot of your work then evolves from thinking specifically about the product to more project management sort of work. How do you make sure that all 20 people are on the same page and have a sense of what the most important parts of the project are and are aware of things like status and are aware of things like dependencies across other teams. Communication then becomes a bottleneck to make sure that everyone is just aware of what's happening. So if you're someone who cares a lot and gets a lot of energy from building process and structure on your team and making sure that the ship is moving on time, that things are being executed on time, that this is a great, great type of work for you to be doing as project management start work. And I'd say teams that are roughly between 10 to 20 people really benefit from PMs who are very strong at this type of work. And that's something for you to consider. And then finally, when you start thinking about teams that are much larger, 50 plus people, which is something you'll really find only in the largest of companies, then what matters a lot more is you being able to navigate cross-team dynamics. So how do you think about what the purpose of your team is within the larger company and how might the incentives of what your team trying to accomplish, how might that align or not align with other teams' incentives? You need to be sort of very carefully attuned to why the different parts of the company exist. How it is that their projects are prioritized and how you could think about how your projects might ultimately fit into this larger puzzle. And so you'll notice a lot of this work might not actually involve thinking day-to-day about how the core product actually works. It's a lot more about thinking about sort of the organizational complexity of the broader environment that you fit in, even though your job title is still product manager at the end of the day. And so that's always the thing that I marvel at when I think about a graphic like this is the actual job title that you have, whether you're a two-person team or a 50-person team is product manager, but you can see here that the actual work and activities that you do very considerably at different stages. When I would spend my time on the Android team, I would spend a ton of time navigating these types of cross-team dynamics and thinking about how our team would work with the Chrome team, how we would work with the Play team, how we would work with different functions, marketing, operations, a lot of my time doing that. And so it's a valuable skill and something that can be very important to the organization, but it's very different from core product work. So it's just important for you to keep that in mind. And then the third thing I wanted to talk about, thinking very much impact PM role are the functional stakeholders that you work with. So who are the different categories of people within the company who you spend a lot of time and a lot of effort with on a day-to-day basis? Most PMs, when they think about the PM role, they're primarily thinking about these two functions, engineering and design, maybe the folks who are actually building the product, the engineering function, and the folks who are envisioning what it looks like and feels like the design function. And those are certainly two very key functions that PMs work with. But the reality is, I mean, within more organizations, it's a lot more complex than that. Even within engineering, there's obviously different flavors of engineering. And at a rough first pass, the one way to think about it is front-end engineers versus back-end engineers. But there's also all sorts of other functions as well, partnerships, sales, marketing, legal operations, a bunch that I've left out here. And different PMs get energy and excitement from spending their time working with different functions. And I think an important thing to consider what are the functions that you want to spend your time primarily working with? One way that I think about that is roughly segmenting it into different industry sectors. Obviously, this is quite simplistic, but I think it's illustrative to help you think about how different functions fit into different types of companies. And companies that belong to different types of sectors might primarily involve working with different types of functions. So for example, if you're working at a media company and building a media business, like we're doing with Game Snacks, we're building a gaming business, a lot of your time is probably gonna be spent around thinking about how consumers actually interact with the media, which is a very design-oriented way of thinking, but also partnerships. How are you actually gonna get the content out on your platform? What is the relationship the content provider's gonna look like? And so a lot of your time, if you get excited about working with designers and partnerships folks, maybe you should consider working at a media business or a media product. Contrast that with something like a crypto company. If you are trying to build a new crypto protocol or work at a crypto exchange, then you might be spending a lot of your time thinking about how the actual blockchain works. And a lot of that might involve working with backend engineers, but also spending time working with a function of the legal department to make sure that what you're doing is compliant in different states and countries that you might be launching your product in. You can see here the types of functions that you work with are clearly quite different from where you might be working if you work in a media company, even though that might not be obvious when you initially think about sort of how a crypto company's day-to-day work might differ as a PM from the media company's day-to-day work. You know, I could keep going. You know, if you go to a SaaS company where you're trying to sell software into a larger enterprise, you'll probably be spending a lot of your time with the sales function. They might be actually the most critical functional counterpart for you because they're the ones spending a ton of time with the core customers that you're gonna be selling to. And so do you enjoy that? Do you get energy working with sales folks? And do you enjoy that the way that they think? If so, I mean, working at a SaaS company is a great choice for you. And then finally, maybe you get excited about sort of the operational parts of building a business, making sure that things are moving on time, making sure that, you know, you're able to construct a very high quality, heavily detailed, long-term plan that are excited about executing towards that. If so, I mean, consider working at a hard work company where it lives and dies by these types of operational efficiency. A company like Apple is known for that. It's a very different type of skill set and a very different type of functional expertise from a media company. And so I think it's very important for PMs to be aware when they're taking new PM jobs of what functions it is that they wanna be working with. And so that's in a nutshell, I think three kind of simple ways to think about how the PM role varies by different types of environments. You know, where in the product lifecycle are you when you're joining a new team? How large is that team? And what are the types of functions that you're gonna be interacting with and working with when you join that team? So what I've tried to do is distill a bunch of those into simple questions that you can ask yourself as you're exploring the next PM role for you and potentially in the final stages of an interview for a new PM role. The first is just how well funded is this product? You know, how much resourcing has the team that you're gonna be working for and team that you're gonna be working with willing to actually put behind that product? Cause this will give you a hint as to where in the product lifecycle you are. Is it the case that it's just an idea that's sitting around in a bunch of different pitch decks? Is it the case that executives that have sponsored it and are willing to allocate a certain amount of headcount towards the product over the next year? Is there also operational sort of dollars behind it? Having a good sense of how well funded it is will give you a proxy for where in the product lifecycle the product sets. Second, how many different people are you actually gonna be meeting with on a week to week basis? Is it one other person? I mean, that's what it was for me with game snacks in the early days. Is it seven other people? That's what it tends to be now. You know, I meet with a ton of folks across the company but most of my time is spent with the seven people on my team. Is it 50 different people? You should be able to get a pulse of this even before you join. And you might be surprised by how dramatically your day-to-day changes based on the answer to this question. And then finally, just very concretely, who are the top three stakeholders for the success of your project? Is it the VP of sales and the VP of engineer? Is it the VP of partnerships and the VP of marketing? Is it the VP of product and the VP of legal? You can try to get clarity on this even before you start the job and take the next role and this will give you a rough sense of what functions you're gonna be spending most of your time interacting with. So I hope this was helpful and gives you kind of an alternate way of thinking about how to approach the PM job with the perspective that it's ultimately a people-centric job and that product and thinking about product is just one part of the many different things you can be doing in the job. If you have any questions or feedback about what I said or even if you disagree about something that I said or disagree with the framing, I would love to hear from you. Please reach out by Twitter's right there, Ani underscore C underscore Mohan. You can find me on LinkedIn as well. But thank you for listening and watching and looking forward to being in touch. Thank you.