 Hi, everyone. My name is Sid. I am a product manager, and today I will help you crack that product sense interview. Before we get into the interview content, let me tell you a bit about myself. I have been a product manager at several companies in a variety of spaces. Currently, I am a product manager at TikTok, where I'm building new ad products. Prior to that, I was at DoDash building consumer-facing products for DoDash restaurants. Before that, I was in gaming with PlayStation and in finance at Northwestern Mutual. Outside of work, I enjoy teaching and mentoring aspiring product managers to get better at interviewing so they can get their dream job. I have interviewed several people in the past and also been on the other side where I was interviewed by several top companies. Today, I will share with you what I learned and work well for me. All right, now let's get to the good part. Today, we'll be talking about product manager interviews and specifically the product sense round. I will then walk you through a framework that worked pretty well for me at interviews and also something that I look for when I'm interviewing people. To make it easy, I will walk you through a real example along with the framework. Finally, I'll give you some tips to keep in mind so you can get better at interviewing. Okay, so I think most of you know about this already, but a typical PM interview consists of these rounds. Most big and small companies have a product sense round and some may even have up to three rounds of these. These are common at companies like Google, Meta and even at startups. The type of questioning can vary and we'll get into that in just a bit. Execution type rounds are quite common as well, especially at companies like Meta where they try to see your analytical skills and how you may define success for a product. Next, behavioral rounds are very common as well. Some companies may have one to two rounds of these, while others like Amazon's entire process mostly consists of this type. Also, some companies may have case studies like Uber has a jam session where you are given a topic beforehand and are expected to make a presentation or a doc that you can then present to your future potential colleagues. Today, though, like I said, we will focus on product sense. A lot of people absolutely dread this round and some have good reasons to do so, and this is what I will try to make easy for you. This is typically a 45-minute round with about 10 minutes in total for intros and questions at the end and the rest for actually solving the problem, so 35 minutes in total. It may seem like a lot of time at first, but believe me, this typically flies by very quick, so let's get into it more. So as I said, this is the most common type of interview across various companies. The reason why companies like to do this is so that they can gauge your problem-solving skills by thinking about the users, breaking down the problem, going deep, and finally finding a solution that works. One popular misbelief among interviewees is that they are evaluated on the solution, but that is not true. In this round, what matters the most is how you get to the solution. It does help to be creative with your solution, no doubt, like Google encourages interviewees to come up with a moonshot idea while meta probably doesn't care as much. Either way, if you don't have a proper structure, you will not pass this interview. Some typical forms of questioning can be you are a PM at some company, build a solution for ex-users, or build a product that does ex. Another type can be, and also very popular one, is the what's your favorite product question? So they could ask you, what's your favorite product? What do you like about it? Or what would you change about it? Let's focus on the more challenging ones today, where you are going to build a product from scratch. Keep in mind, the framework that we are about to discuss is something you can plug anywhere, whether it is in other type of questions or even at your job. So here's a framework. This is the one that worked for me, but I would highly caution and highly encourage you not to merely copy something like this, but make one that works for you and that you are comfortable with. Going to the framework itself, once you are given the prompt, start by asking clarifying questions. If applicable, or if you know the company, then talk a bit about their mission and then define a vision for the product. Then set a goal for the product. This is where you can define a not star and you don't have to go too deep into the metrics here just yet. That is for the execution around typically. But we'll talk about it a little bit later. Next, you will talk about your users and prioritized one. Then talk about pain points of that user group and prioritized one, and then come up with solutions and prioritized one for an MVP. After that, you may be asked to wireframe, which is not very common, but something that you should potentially be ready for as well. And finally, you should talk about trade-offs. To make it all make sense and work through the framework, let's work through a previously asked question at Facebook. The question is, built a gardening product for Facebook. Now let's use the framework to solve this problem. Start off by asking some clarifying questions. These will help you understand the problem better. One thing that people do a lot is jumping into the problem straight away. The interviewer actually expects you to understand the problem and they may actually anticipate questions from you. So get the clarity you need, and that will actually set you up for success. Ask some basic questions about what they may be looking for or are they specific users to look at, or if the company has a broader initiative in mind that they would like to focus on. And whether solving for this problem would be a significant step for the company to achieve its goals. Make this part a bit conversational, but I would suggest not spending too much time here. Next, talk about the mission of the company. This may not be applicable in some cases, like a small startup that you may not even find a mission for. If you don't know it, it may be okay to skip. However, for big companies, this is definitely something you want to say out loud, especially for a company like Meta. Here, the Facebook mission is to give people the power to build community and bring the world closer together. And that's it. One line, and let's move on. Next, set a vision for the product. Take a few seconds to think about this. Again, this should be small, and perhaps even talk about how this ties to the mission of the company. In the case of our gardening product case, I would say something like making a gardening product for Facebook's large community would help connect people with similar passions like gardening. This is directly related to our mission, so a problem worth solving. Now, we'll set a clear goal for product and define a not star. We don't have to go too deep into the metrics unless you're asked, so you could well be prepared for it, but that is usually something that happens in the execution realm. I do talk about metrics in more detail later in case you are asked. Coming back to the goal, though, think about what is this product really going to drive? Is it engagement, revenue, or something else? You may also want to consider at what stage the company is at. Some might be smaller versus bigger, so some might be focused on revenue versus adoption. So be careful. Usually people do get a question on this, so it's critical how you choose the goal. So be very clear. For the question, I would choose something like increasing user engagement. I would provide a reason that the product would be new and could be an effective way of connecting people on Facebook. So I would focus on engagement with something like engagement metrics on the platform, that is likes, shares, comments, maybe my not star. Again, you may have a completely different opinion about this, and if so, that is great. Point being that you need to define the why behind your statement. Now we go deeper. Next, we focus on identifying our target user. Think of all the users that may use your product. Cohort them by age, demographics, skill level, individual, or businesses, et cetera. Come up with about three to five user groups, not more than that. Don't spend too much time doing that as well. But then prioritize one group. Make sure to explicitly define how you're prioritizing. Typically, I like to prioritize by scoping the problem and why this might be the right user group to consider while solving the problem. So for our example, I would first divide the users into two large buckets of people and businesses. Under the people bucket, I would go one level deeper to categorize them based on level of expertise, like beginner, intermediate, expert. Here's where you would make your best judgment to prioritize. In this case, I would choose the beginner user group as I think it is a bigger cohort size and scope. You may be asked why you would choose one over the other, so be prepared for it. Next, we need to define the user group's pain points. Think of it from the perspective of the user. If you were in their shoes, what challenges or pain points would you have? Come up with three to five pain points. You must prioritize one here based on the pain level and frequency of the pain. Take some time in the section. Really flush out those pain points and talk through them and then finally prioritize one based on how painful it is and how often does it happen or the frequency of the pain. For our example, I listed three points here, as you can see, and I would choose the one about not having enough guidance on what to do with plans. I think this is a big problem, especially for a beginner, as without proper guidance, my plans could die pretty easily. That's why this is a critical problem resolved. This is what I would tell the interviewer. Again, they could basically ask you why did you choose this over that. Keep in mind that's something that you can be asked, so be prepared for that question as well. Hopefully, so far, you were following the framework. By this point, the interviewer probably knows that you're a good candidate or not. Let's talk about the solutioning step now. Come up with three solutions potentially. One is too less, two is okay, and three is probably the best. Then prioritize based on cost and impact. Other things you can also consider are whether the solution is directly solving the problem or the pain point, and whether the solution is scalable. Something to keep in mind, but definitely talk about cost and impact. Others also use a rice framework, so that's proven to be effective as well, so you can consider that as well. In this example, I would list three solutions and choose the ask an expert solution as my MVP, where the user creates a post notification is triggered to all plant experts, and they can then post relevant solutions for my issue. As a future iteration, I would develop an AI solution that can pass through the top comments and show the best possible solution. I'm not going to detail into this particular solution because we don't have the time, but this is, as I said, this is very basic, so make sure to walk them through the entire user journey, and if asked a wireframe, then you should be prepared for that as well. I'm going to skip that wireframe part, but be prepared just in case. Finally, talk about trade-offs. This really shows a proficiency. I don't think most interviewees talk about this, but this definitely counts and is a huge plus in an interview. I would suggest not spending too much time here because by this time, at this point, you're almost about wrapping up the interview, but talk about a couple of trade-offs, why it is important, and potentially a workaround as well. I didn't mention that some interviewees may ask you to define success metrics, so please be prepared for this. Make sure to tie your success to the product. Consider you're not star, have about five to six metrics, so really having a breadth of metrics is great, as it shows you know your metrics pretty well. All right, so we've reached the end here. A few tips and suggestions. First and foremost, please, please, please don't jump into solutions. This is the number one mistake people make. Take your time, gather your thoughts, and when you're ready, say what you need to. Secondly, remember it is a structure and how you articulate each part of the problem that matters. It is not the solution, but how you get to the solution that gets you points and sets you apart. Please make sure to pause. Do not rush. There is no need for it. A good interviewee takes time to gather their thoughts. You can directly let the interviewer know that. Drink water, buy some extra seconds, do whatever you need to do, but try not to take over 90 seconds and avoid really long, awkward silences. You are going to be cross-questioned, so this is not going to be something you'll just go through pretty easily. You will be asked questions so the interviewer can know how you're thinking and why. So be prepared for that. Don't get too worked up about it. You might think you are losing time or the interview isn't going great and you might be surprised at the end of it. Just try to stay calm and get through without being too nervous. Finally, the most important thing, practice, practice, practice. The more you do it, the better you will get at it and you start to build more confidence over time. Even though you may be an experienced product manager somewhere, does not mean you'll go through this interview with zero practice. So find people you can mock with and also practice on your own. And that's it. Hope this was helpful and good luck on your interviews. Bye.