One exercise to improve at product job interviews
13 December 2020 ‧ 7 min read
I usually don't write much about breaking into product management—I believe that there are others who have more valuable insights to share than I do, and I therefore focus my writing on what I have learned while working as a product manager and product leader. Whenever I do share advice for people wanting to break into product, it's only because I have a perspective or idea that I consider reasonably unique. Today, I want to share one exercise to get better at product management job interviews.
There are several books and countless online resources to help land a product manager job. Two books that I can personally recommend are “Cracking the PM Interview” and “Decode and Conquer”. When I was first preparing for product management interviews myself, I liked the former for its comprehensive approach and overall advice, and from the latter I particularly liked the framework for addressing product interviews.
Product interviews come in different forms, but many are case studies in which the interviewee is asked to design or improve a product—it could be a software product or even something entirely non-electronic (like a piece of furniture). The purpose of these interviews is to see how well the candidate understands the process that a product goes through from discovery through design (into scoping and development), whether they have some level of product sense (understanding customer needs, proposing reasonable solutions for those needs, and evaluating related tradeoffs), and how well they can structure and communicate their thinking.
These product interviews have some obvious shortcomings—most importantly, in real life, product managers would never run through this entire process all by themselves. The entire point of product managers is that they form part of cross-functional teams and collaborate at least with design and engineering to discover and develop a product. However, since it is impossible to truly simulate this teamwork scenario in an interview setting, these interviews form a crucial part of the product manager hiring process at most companies, so anyone hopeful to land a product management job would do their best to be prepared for them.
To improve at product interviews, there are obviously a lot of things you can do: you can read books and articles about the interview process and learn relevant frameworks; you can research the company, product, and competitors; you can study typical product metrics and benchmarks; you can find someone who will actually conduct a mock interview with you.
One important thing to realize, though, is that following this product discovery and design process requires a kind of product “muscle”. Like other muscles, strengthening it requires exercise, which requires repetition. Mock interviews are obviously great to exercise this muscle, but you won't always have someone to mock interview you. So, similar to a basketball player who may practice by playing games sometimes but also often just improves their technique by shooting some hoops alone, you can practice this interview process by yourself, too. It's not going to be exactly the same, of course, but it will strengthen your muscle of following the process.
To do this exercise, dry-run a product design interview. Whenever you have 45 minutes to an hour of time, take out a sheet of paper and give yourself the task “improve product X for user group Y”. I would recommend using the products of the companies you are interviewing with, and somewhat randomly picking a user group or user persona that you are trying to improve the product for. As an example, let's say you are preparing for a product interview with LinkedIn, you might want to give yourself the task “improve LinkedIn for job seekers”, or even more specific, “improve LinkedIn for a software engineer looking for a new job”.
Start the clock, and then try to follow the design process along a framework of your choice, writing down the key steps on the sheet of paper that you might draw on the whiteboard if you were actually in the interview. As mentioned, a framework that I liked (partly because it has an acronym that is easily remembered) is the CIRCLES method from the book “Decode and Conquer”, which follows these steps:
- Comprehend the situation
- Identify the customer
- Report the customer needs
- Cut by prioritizing
- List potential solutions
- Evaluate tradeoffs
- Summarize your recommendation
You don't have to follow all the detailed recommendations of the CIRCLES method, but the overall steps are a good order to go through to make sure you don't miss anything that is typically required in the product interview. You might be asked to go deeper into specifics at one point or another—for example, you might be asked to come up with a quick wireframe for your chosen solution—but usually you won't be faulted for not doing that on your own.
This dry run of an interview has several benefits: firstly, as mentioned, it ensures that in an actual interview, you can confidently follow the process without missing any critical steps. Secondly, I suggest dry runs using the products of the companies you are interviewing for because it has the side benefit of getting to know the product better. If you have any blind spots, like not really understanding customer needs and pain points, this dry run makes that obvious. You can do more research and do another dry run, and it should go much smoother. Lastly, it doesn't just exercise the process muscle, it also exercises the product creativity muscle. In each dry run, you'll have to come up with several improvement ideas, sometimes for niche user groups. The first few times, your ideas will probably be very uncreative, but the more often you run through this process, the easier it will become to have ideas that are inspired but still realistic.
Just one word of warning: don't assume that the ideas you come up with in this process are going to be revolutionary for the company you are interviewing for. It's good to have some ideas how the product could be improved. If the interviewer asks you “so what would you change about our product” and you don't have any ideas, that's a huge red flag. However, thinking that an idea that you came up with in a few hours at home, without knowing any context or having access to any real customers or metrics, is going to be better than what people at the company have already thought about, is delusional. Moreover, product ideas are dime a dozen, and it's the execution that is really hard.
When I worked at Yammer (Microsoft's Enterprise Social Network, meaning a social network that companies can use internally), a candidate had somehow come up with the idea that Yammer should pivot to being a social network for music, and he tried to pitch this idea in every single interview. Needless to say, he didn't get hired. So, again: don't think the ideas you come up with based on desktop research are going to be groundbreaking. Your interviewer isn't looking for groundbreaking ideas, either. They are looking for reasonably creative ones along with a solid grasp of the process and a good understanding of customer needs and tradeoffs.
Just a few more pieces of advice on the actual interview, then, based on someone who's now been on the interviewing side a fair bit.
Firstly, one of the most important things in the interview is to properly evaluate and communicate tradeoffs. Evaluating product tradeoffs, especially in an interview setting where you don't have access to a lot of information and you can't validate ideas by testing a prototype or something similar, isn't a science. If you have multiple alternatives and you are trying to pick one of them, there's not a right answer. What's most important is that you can identify the most important arguments for and against the various options, weigh them according to your understanding, and come to a conclusion. If the interviewer disagrees with the weighting, they might challenge you or not, but having a different opinion than the interviewer is unlikely to give you any trouble.
What you need to avoid, though, is either failing to acknowledge tradeoffs or missing important points. Failing to acknowledge tradeoffs typically comes in the form of just trying to make the argument for the solution that you are preferring, without also discussing its weaknesses. That's never good in a product management interview. Remember: you are not trying to pitch a solution. You are trying to show that you can think through a problem clearly and rationally. Every product person knows that there's not a one-size-fits-all solution without any drawbacks. So acknowledge them and share why you believe the pros outweigh the cons.
Missing important points can be harder to spot and avoid. You basically need real or mock interview practice for this. I most frequently see this happen when candidates propose solutions that would be really resource intensive to build (meaning the solutions are technically challenging), but then fail to address the technical effort in a tradeoff evaluation. More often than not, there would be a less sophisticated solution with perhaps fewer customer benefits but far less technical effort. You should at least propose that kind of solution, even if in the end you still argue for the more sophisticated one.
The second piece of advice is to take your time, especially at the beginning of the interview. Taking time is really something that you should practice so you don't get derailed simply because you are nervous and jump ahead in the process. Often, candidates who don't do this jump to solution ideas too quickly without making sure they have really understood the problem. Instead, just ask “mind if I gather my thoughts for a minute”, and make a plan for how you will address the problem. Your answers will be of so much higher quality that you will easily make up the time. Don't think this will be seen as weird or problematic by the interviewer. A start where you stumble and mess up the process because you started talking without thinking is much more of an issue. In all my experience as an interviewer, I've only ever had a single candidate who took “taking their time” too far—but they literally responded with “let me think for a minute” to every question I asked, so that I didn't have the feeling we could get a conversation started at all.
Thirdly, make sure you ask clarifying questions. Product development is a team sport, and product managers never work alone. Even though in the interview the spotlight is on you, no one expects you to know everything. As long as you don't think there's a “right solution” that you can somehow coax out of the interviewer through probing questions, asking questions is absolutely recommended. Make sure you are on the same page regarding the context and problem, and then, whenever you feel that you have concluded a step, ask whether you should move on to the next step. Your interviewer then has the chance of interjecting if they feel like they would like to dig deeper somewhere.
The last piece of advice is to make (reasonable) assumptions, but make them explicit. As mentioned, you don't have access to a lot of the information that you would normally use in a process like this. So whenever there's a piece of information you are missing, it's okay to ask (see above) or make an assumption. Just make sure to call it out: ”I am going to assume that growth is currently a bigger priority than engagement” or “I would normally look at conversion rates by funnel step to see where I should focus, but given I don't have that information, I am going to assume that the biggest drop in conversion is on the checkout page”. Of course, try to be reasonable with assumptions. Don't assume something that's highly unlikely just because it makes it easier for you to argue for your favorite idea. Even if the interviewer disagrees with your assumptions, though, calling them out makes it transparent that this is something where you would have usually stopped and gathered more information, which is much better than just silently skipping over that step in the process.
I hope you found this article useful. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.