 Great. Hi, everyone. Welcome to another product school talk. I'm Cassandra. I'm excited to have everyone here today. As many of you know, we teach product management, coding, and data at our 14 campuses. Really excited about today's session. Since this week we have Randy Edgar, who is a product manager over at Uber, and he's going to be sharing his insights on cracking the PM interview. So hi, Randy. How are you doing today? Hey, good. Thanks for having me. Great. Well, thanks for joining us. It's really great to have you here this week. I know we've got your presentation pretty much ready to go. So before he takes over, just a quick reminder to everyone. We'll be taking questions in the Facebook comments right after his presentation, so you'll get some time there for Q&A. And Randy, I'll let you go ahead and take it from here. Okay, cool. Thanks for having me. So I've given this presentation a couple times over at product school in person. I've changed it around a little bit, but my background is I work as group product manager at Uber. I work on a lot of the communication products that we have here at Uber between rider drivers or through marketing. And in my background, I've done probably 500 interviews or so on the product management side and definitely seen sort of the pros and cons of things. And wanted to go over today the skills that hiring managers are looking for. And then some of the sample questions and go over like when you get that question, what are hiring managers actually looking for when they ask that question? And then at the end, I have some overall tips that go for any interviews, just not PM interviews that usually go pretty well. And the whole thing should go about 15 minutes or so, 20 maybe, and then I'll save the rest for questions at the end. So when we talk about the nine skills that product managers are looking for, what we do is certainly look for the main skill. And that is that you are focused on the customer, that you are creating features that you are constantly thinking of solving customer problems first. So the idea about, and we'll talk about this a little bit, but creating features just because you think it's a good idea, or you think that it'll solve some sort of need. What is the customer's need? Are you hyper-focused? Here we use the term customer-obsessed. Are you absolutely obsessed about the customer and what their needs are, or customer slash user, let's say? And making sure that everything that you're talking about is focused on the customer or user first. So what comes after that is that what a product manager's main job is, I see it as that the product manager is the person who understands what problems to solve. What is the right problem to solve? And how you go about doing that is by being very attentive to metrics and goals. Do you have the right goal for your product? Are you able to use data and metrics to determine success of your product? Like I said before, you can come in and be like, I want to build this particular feature without being data-driven. And we'll get to that to the next slide. But without being hyper-focused on a goal and an objective and key metrics that you're going after in order to be successful. So that's the second one. So as long as you're hyper customer-focused and being goal and metric oriented, that usually gets you through the main part of the interview, if you will, the main file. The third piece, and I talked about this a little bit, is being data-driven. So being customer-focused means that you are diving into data, both qualitative and quantitative and understanding customer needs and understanding what people need based on the data that you see. If you have intuition or gut feeling about a certain product, that's great for Steve Jobs, but for most product managers, it's really good to have the data behind you to make an informed decision. And you're going to need that data to be able to communicate to both engineering, to executives, to design, to operations, to use data. At Facebook, they like to say data wins arguments. And I think that's a great way of summing up why it's so important to use data in your decision making. The fourth piece is how innovative are you? So can you create features based on what we just talked about that are helpful for customers, that are data-driven, that are certainly unique and can move the company forward? Can you think about new features? Can you think about why to build a particular feature and come up with something just one feature that's new? I once had an interview and I asked someone to pick a product and they started talking about what the customer needs and that sort of thing. But they came up with the most, just this very small, innovative solution, which I was totally wowed by. And she tied it back to her key goals and metrics. And I'll talk about that in a little bit. But just being innovative and thoughtful about that. Fifth, certainly is what does good design and UX look like? So just because you've met a customer need doesn't mean that you're a good product manager. It means that you need to know what the customer needs within a particular product or within an application, right? So a lot of times you'll get, you might get a question about like, tell me about a product that has really good design or tell me about a product that is really poor user experience. And tell me about that. And the user experience question is really there to dive into the user need and the user flow and the mental model that the user has to go through a particular use case. So as long as you're driven by a good user experience, usually that's very helpful. So the main question I get usually is how technical do I need to be to be a product manager? And the answer to that, like a lot of the questions that we're going to go through is it depends. It depends on the company and the culture and what they're looking for. There are some companies that you need to know enough to dive deep enough to determine the right solution and be able to have a very intelligent conversation with engineering. And sometimes you need a CS degree. And sometimes you do not. And sometimes you need, you know, an experience of being an engineer. And sometimes you got there are certainly are companies that, you know, a computer science degree is required. But there are some that are not as well. So it really depends. But being the I would say it is a it certainly benefits you to have the technical acumen in depth. And to show that in an interview as much as you can. The the next one is really around inspiration. Do you have the the ability to create a vision for a product? So it's not just necessarily about features, right? So day in and day out, we have a three month roadmap or six month roadmap. Can you look deeper into the future? Can you go 18 months to two years on our or or three years on a product and really dive deep into where that product is going? And why that's so important is that you need to on your roadmap when you're building a roadmap, usually, certainly it's data driven and it's customer focused. But it's leading to an end state. There's an end goal there that you're trying to reach. And how do you get your your customers and your internal stakeholders and your and your team to buy into that vision to move towards that that vision and being an inspired communicator and have that vision and lead that team to move in that direction is really important. Certainly communication, right? So the ability to not only clearly articulate what we're what we've been talking about as far as your vision or your plan or your feature or what have you, but do it succinctly, right? So we will get through this in a little bit. But one of the questions that we usually ask at the beginning, right, is tell me about your background. As long as you can do that in a succinct manner and really clearly articulate what you want to do, that's what they're looking for, right? And so being able to just watch yourself as you communicate and give feedback, like, is this enough? Is this too much? That sort of thing. And the other one is around execution, right? So can you get your features built? It's great to have that vision. It's great that you have the acumen and skills to get a product built and get the right product built. But what is the work that you do in order to get work done? And do you mistake motion for progress? And what I mean by that is just because you're doing work doesn't mean you're making making progress towards your goal, right? So being able to clearly articulate that we have goals as a team and we have milestones and we're making progress towards towards those goals, not that just we're doing work. And the third part about that is collaboration, right? You get that in just about every interview. How do you collaborate with other teams? Product managers can't get anything built on their own, right? Unless unless you're also an engineer and a designer or a researcher, usually it's done with a team. So being able to prove and communicate that you have the collaboration skills to work with others is super important. So in a summary of this, like, it's really around, do you have the skills to determine the right, you know, problems to solve? Are you thinking about the customer and customer first and customer obsessed? Can you clearly articulate a vision? And can you build that product flawlessly and create big impact for your customers, right? So when we go into the sample questions, what what is next, the next part, you'll see that we're tying that back to the skills that we just talked about. So let's go through those typical questions that that you've probably seen on interviews, on product management interviews. And let's talk about what the what the hiring manager is looking for when they ask that question. And I put there the hint there is right, it's one of those nine school skills that we just talked about, right? So like I mentioned at the beginning, tell me about yourself or your background. That question certainly is to break the ice, but it's really also to to show the sickness and clarity in your communication. Keep it brief. Keep it just three or four minutes. If they want follow up, they can ask, but really keep it brief. I had one, I one candidate who went on for 18 minutes about their background, in a half hour interview, and I wasn't able to answer to get all the questions that I want. And you could, you could determine that that wasn't a very successful interview. But the real thing, the question that you're going to get a lot is I'll either tell you about a product here at at company X, right? Or you can pick one yourself. Just take out your phone, you might get this a lot. Take out your phone, pick any app on your phone. And tell me about a feature that you would build for that product, or we have a product here, you know, Uber eats is rolling out for fast food. Tell me about the product that you would build for that, right? You get that question a lot. So what are they looking for? So what we're looking for is the exact thing that we just talked about those nine skills. And the easiest way to break this down is to structure your answer into the skills that we just talked about, right? So first, what I would suggest is go to the whiteboard, right? And then write down the customer problem or customer needs that you see in your mind. So there's going to be more than one, right? And for and there's going to be there might be more than one customer, right? There might be like, you know, for for Uber, certainly there's, you know, right or right. There's two sides of the the market there. What are the customer problems? Right? What are their names? What do the customers have to say? What does the what a qualitative research say? What do focus groups say? What do sales say? What does support say? What is the feedback that you're hearing from customers? And then, secondarily, what's the data that you see, right? So dive into the data and make sure that you really truly understand the customer problem. Now, in this case, if you don't know what that is, you're going to have to make assumptions, right? So you'll have to say like, I assume the customer feedback said X, Y, Z or on if it's a question about a product that at the company that you're interviewing at, you're not going to know, right? So you're going to have to ask follow-up questions like, what does the data say? And what does focus groups say? And what is support saying about the product that the customer needs are? So after you go to the board and write down the problems, you'll want to write down like three or four different problems that you're trying to solve and pick one of them. And the most important thing we're looking for is the why, right? Like you're going to have to make assumptions around it, like I said, but you're going to have to say like, I'm going after this problem. It seems like the most impact for both our customer and our business and the main objectives that we're going at. So that's the third piece, right? Like what are the objectives that you're trying to solve? Right? Are you trying to solve for engagement? Are you going to start to solve for more users? Are you going to try to solve for a particular customer area? What is that objective of your product? And then come up with that feature that and then tie that feature back to the objective and the problem and the customer needs, right? As long as you've done that in a structured manner, I know as a hiring manager that you're thinking in a very structured way, the right how to solve that problem. And then as long as you have, so you come up with a feature and you're like, here's my feature and hear the key results that I see from that feature, right? This is what I'm going at. My objective is X. I'm going to go after it with these key results, Y and Z, right? And then then you talk about how I would actually measure success, right? I would measure it by by understanding the following and then the most important thing then is to tie back your answer of how I measure success. I'd like I measure success by understanding like the product adoption and the monthly active users, let's say, and then I would tie back how I got to that monthly active users to the feature that I built and not through any other cause and try to correlate that feature back to the product or sorry, the benefit, the measure of success back to the product. And then finally say, but that's not it, right? That's just my feature. But where I would go with that product after this is I would do more customer research. I would look at the data. I would understand how it's performing and then I would come up with a roadmap and iterate from there to make sure that I'm hitting my vision, right? So as long as you go to the board and structure that answer, that's really what we're looking for. So this is probably the most important slide that I'm talking about today. Another one clearly is how would you measure success of the product? What are the key KPIs? I can't tell you how many, how many interviews I've done where they did the candidate did not tie back a feature to the key product indicators, performance indicators that they're that they're looking for. If you don't have a goal, you don't have a feature, right? So make sure 100% of the time that when you have a feature that it's tied back to a customer need, but then you clearly articulate what the key the measures of success are, right? You have to have to do that. Other things you might get, I wanted to talk about this, is that you might get trade off questions. You know, what's more important, the number of weekly average users or engagement of those users? Or if you build a feature X and that's getting adoption, but it's cannibalizing another product, what do you do? Right? The answer to these questions is almost always, it depends on the goal. Right? So you're going to have to ask a question back that says it depends what is the goal of the company? Is it really to grow the number of user? Is it a brand new product that we're just trying to get as many users as possible on the platform? Or is it a stable product that we're trying to get more engagement, more user, more daily actives or more like time spent, that sort of thing? To drive other metrics. So if you don't have a clarity on what you're trying to solve, the answer will always be, it depends until you figure out exactly what the problem that they're trying to solve. It's a little bit of a trick question. So that's why I always say like, ask follow up questions or make assumptions and make sure that you're trying to figure out the key objectives of the product. Because if you don't then these questions become traps. Let me move. I know we're running a little shorter time. So I wanted to go through some of the overall tips. Okay. One that I didn't do too well on this one, but it's really about speaking slowly. The interview is a conversation. It's not a way to just talk at someone. You're talking with someone. So remember to slow down and be personable, be friendly, be kind, right? The one thing that, and there's a Malcolm Dadwell book called Blink, and the one thing they suggest in the interviews is to just smile, right? To be friendly. Like I said, follow up with questions and articulate assumptions. One of the most important things you can do is understand the company culture. So go on Glassdoor, read about it, talk to other people. The answers to your questions may depend on the culture of the company. At Facebook, there was a culture around move fast and break things. So if you talk about moving slowly and using waterfall as a technique to ship anything, you're not going to do well in that interview. So make sure you understand the culture. Really come prepared with thoughtful questions, right? Really think about what you want to ask. Any interview that ends with like, Hey, do you have any questions? And the answer is no, that's usually not a good sign because you're not really thinking through the questions that you want to ask. Also, certainly, you know, research who you're meeting with, right? Like, who is the person and do you have any shared connections with them, either through other companies, through education, through interests, like anything to break the ice and and to make the conversation more relaxed and more personable is certainly in your favor. Two last things. One, this interview is about you. So sell yourself. A lot of times people may overpivot and talk about we did this and we did that and we did that. That's not that's fine if you're talking about collaboration. But this interview is about you. So you should sell yourself. I did this, I did this, I did this, I think about this. This is how I this is how I get stuff done. And lastly, interviews are tough. They're difficult and they require practice just like anything else. Please, if you get an interview, take it even if there's a company you don't want to work for, take the interview. You'll learn something about yourself when you do that when you do that interview. So it's it's my biggest piece of advice. Take those interviews. Okay, so we got about eight minutes or so for questions. I'm happy to take anything. Awesome. Hi, Randy. Thanks for the great presentation and a really good point on understanding company culture. I think that's really so important. We have a couple questions coming in. So let's see here. One of the first ones was if you could give some more examples of KPIs when it comes to product management. Sure. So any KPI would be so you have an objective like you want to you have an objective to grow, let's say ridership by 1% or let's say less. So that the or to grow to to to, I won't use your example, to increase, you know, user sentiment. That's one of that's one of the things that I'm going after. I'm going, I think it's really important that people feel a sense of happiness or what have you about my product. What are those KPIs? So the KPIs might be a certain percentage or like how am I going to measure that? So it might say that the K are there. The key result might be I'm going to grow that by 5%. And how I'm going to do that is by sending out weekly surveys, but to to users every every X number of days. Right. It could be around engagement. So how often people come back to the to the particular product right over the app. It could be around how many monthly active or daily active or weekly active users. Those are all key KPIs. And usually they include a number over a period of time and how it's measured. Awesome. Thank you. Our next question comes from Igor. Do you have to be a domain expert in a specific industry in order to be a good PM? Yeah, that's an awesome question. The the answer like it almost every it depends, right? So there are some companies that only want to hire people that have a domain expertise in certain jobs. Usually it's very it's it's more like unique to a particular industry like I'm looking for someone with a like a really good oil and gas experience because I'm creating some product over there and that you do need to have that experience for me. And you so for a lot of the interviews we do, we're just looking for really good people. And and the answer for me is usually no, it doesn't matter as long as you stick as long as you have a product mindset, as long as you're thinking about a particular product in the ways that we talked about, it doesn't matter about the the background that you have as far as like different domain expertise. Awesome. We have quite a few more coming in. So let's see this next one is from. Okay, Winston, oftentimes product managers get overly obsessed with a specific KPI. What tips do you have to ensure you don't go down the wrong path or you're not analyzing the wrong metric? Yeah, that's a good question. So it could be that KPI is right. But like, so the question is really not just about like, are you solving the right problem? But do you have the right measures in place? Right? So I would say, what's the overall goal of your product? Right? So go back to the goal of your product, right? And it by moving a particular KPI, right by X percent or what have you, if you have four different KPIs, which one of those sort of that which one of those is moving the the needle of the objective in a better way, right? So always so Winston, what I would say with that is always go back to the key objective and try to understand which one of those KPIs is going to move that objective the best. That's that's the one that you should be focused on. The other one might be time considerate. So it might be that this is my key KPI for the first six months. And after that, I'm going to move over here. That's okay as well. As long as you're deliberately talking about why you're doing why you're going after that strategy. Awesome. And we have some more coming in on the interview process. Let's see here. Kelly, what's your advice if you're given a product challenge in a domain that you know very little about? So for example, a non social networking company asks you to dream up a new messaging tool for Facebook, but you don't use Facebook. So, so you can either, you know, be completely honest that that that is something that is out of your domain, which is fine. Like being completely honest in an interview is is is great. Like, certainly as a consultant, the best thing you can say oftentimes is I don't know, we'll get back to you. Right. So that one you could say like this is that is not my domain expertise. I might have to ask you a lot of questions or, you know, make a lot of assumptions about what I'm going to go through. Is there another example that may be maybe better? Do you have another example that we could go down? And if they say yes, great. If they say no, then you're going to have to say like, well, can you give me a minute or two overview about the product and or the domain or the product space just so that I understand the context a little bit better. Awesome. That's definitely a good way to go about it. Our next question comes from Winston. Here, actually, sorry, they keep coming in. Okay, here it is. Sorry, this is from Steven. I understand that you said we should talk more like I did this and focus on, you know, things that you've accomplished. But when I do that, sometimes I feel like I come off as selfish or showing off. How would you recommend focusing on what I did without appearing showy? Yeah, yeah, that's a good question too. These are all good questions. So you are there to sell yourself, right? So to come off as showy, you can balance the eyes and the wheeze. But when you talk about we, you talk about like, I didn't do this on my own. Certainly I was using, you know, I was collaborating with these different folks. As long as you're making a balance between the eyes and the wheeze, that's okay. But this is an interview about you, right? So we want to know how you think, we want to know what you've done versus like just in general, like, yeah, we built this product and we did this. It's really hard to decipher what it was that you did. So oftentimes I'll ask the question like, okay, I understand what it was that you worked on. What was it specifically that you did, right? So really, you know, it's more of a balance, but I'm just trying to articulate to not balance too much on the wheeze side. All right, awesome. Well, that's just about all the time we have today. We do have a lot more questions coming in. So we'll try to get back to those on Facebook and if, yeah. Yeah, I'll come back to to the Facebook group and then over the next day or so and try to answer as many questions as I can. Okay, awesome. Appreciate that, Randy. And thanks again for a great presentation. Before we let you go, I would love to hear your final advice for aspiring product managers. Final advice. It's a great field. It's really fun. Just keep practicing, keep at it. And the other one is my old manager used to do this and I used to love this. Every app that you use on your phone, think about what the objective that app is trying to solve. And if you were product manager, what would you do about it? And why? And you get into the cadence of thinking like that. It makes interviews like this so much easier. Awesome. Well, thank you again, Randy, for joining us. I appreciate it. Okay. Thanks very much. Yeah, thanks, everyone. If you guys want to get more information about us, you can go to productschool.com and we'll see you guys next week. Thanks. Bye.