17. How to Ace your Product interview
And common mistakes that set you up to fail
Welcome! I’m Vincent and this is a Product Manager’s Notebook, a series of notes for people who are interested in sharing and learning the art of product management and career development. You can read my archive here.
If you appreciate reading this post, please consider liking and subscribing.
After my last post of my story of how I got into product management (I’m avoiding the term “ended up”, since that suggests it just “happened”), this is a short follow up with some hyper specific suggestions on how to pass your product interview. Since becoming a PM, I’ve now been on the other side of the interviewing table. These are some of the things I look out for, and common mistakes I see.
What is a good PM?
To understand how to pass the Product Interview, you must start with an understanding of the definition of the qualities of a good PM, as per the interviewer. In my view, the ones that are generally acknowledged and agreed on are:
Customer Empathy
Intense Curiosity
Ability to solve problems
Ability to reflect and improve
Ability to prioritise
You can also break down the PM role into several key areas:
Business management (P&L, KPIs)
Project delivery (Requirements, Roadmap management, Milestones)
Product marketing (GTM strategies, internal and external marketing)
Product design (Technical and UX)
With these two areas in mind, organisations will be on the lookout for someone to matches the qualities they expect from a PM, and capable of carrying out the duties expected of them in the role. You can expect questions to relate back to these areas at all times. Here are 3 typical examples:
“Walk me through a recent project…”
As a PM, it’s important to be able to think through a product process: from understanding a customer problem, assessing potential impact, starting small/experimenting, prioritising, managing the build and release, tracking usage/feedback, and scaling. The key points here are two-fold:
Do you understand what an iterative process looks like?
What was the target and final outcome?
Hot tip 🔥
Ignoring or not mentioning the outcome of a project will give you major minus points. Being able to quantify the outcome gives you major bonus points.
“How would you design…”
Sometimes you will be given a scenario beforehand and asked to mock up a design. The questions that will be asked are:
Is it simple and intuitive for customers to understand? Are things where you expect them to be? Are there unnecessary design elements like lists or buttons which introduce extra steps for no reason?
Is it consistent with the rest of the product, in the way it works, looks and feels?
What happens next? So you’ve designed a page with 3 buttons: what happens after you click on them? What action are you trying to drive or information are you trying to get?
End to end thinking is a key area here. If you are being asked about a design with commercial implications, think about what’s needed from a purchasing and billing perspective. You would need to know who the user/customer is, what they’re buying, how much they’re buying and how much we charge, right?
Hot tip 🔥
Boil your design down to the simplest elements possible and put yourself in the user’s shoes. Walk yourself and the interviewer down your scenario and guide them from the vision to the nitty gritty.
Some interviewees present a grand vision but fail on the flow that they’ve either not thought through, or doesn’t stand up to scrutiny.
“How would you prioritise…?”
Prioritization is one of our main, if not the main challenge, for all product managers. How do you consider ROI and trade-offs you’re willing to make? What factors do you take into account, from business impact, customer problems, systems design, technical feasibility and product strategy?
Hot tip 🔥
This is obviously a golden opportunity to show off your reflection of your PM qualities, as well as a minefield for potential red flags. 🚩
The key is to gather information by asking clarifying questions and walk through your thinking process. The question isn’t even necessarily about your choice, but really to understand about your ability to identify and ingest information that are pertinent to the problem, and understand nuance.
So ask questions to gather information, like:
If it’s a customer problem, who is the customer? Is it your biggest client or a small client? How many customers does it impact?
Is there a current workaround? How much do clients care about fixing it? Do they care enough to cancel their purchase, or potentially buy more if we fix it?
The theme to the questions you’re asking, is showcasing your search for evidence and information to make your decision on how to prioritise. The way you approach a prioritisation question is a great tell of whether you’re going to be a PM who “goes by their gut” or someone “who makes evidence-guided decisions”.
Bonus - 3 Great ways to Fail
Jumping straight to answers and conclusions is a common occurrence I see from candidates who are keen to show decisiveness and clarity of mind. Instead, it suggests a lack of critical thought since you’ve grasped at the most readily available answer, based on either your existing knowledge or experience. Stop, take a breathe, ask a few questions and think your answers through.
The world, and product management, are not black and white - your ability as a PM to understand nuance is key to finding the right solution!Ironically, being too vague and noncommittal is also a way to find yourself in a tough spot. If having asked clarifying questions (or often times not), your answer to one of the questions above is “it really depends”, “it’s hard to say”, “you really need more information”, without a view- that’s a red flag.
Having a view as a PM is a non-negotiable, and the absence of one is a sure fire way to not deliver. Instead, try: “Based on the information available, such as x and y, I would suggest for us to do do z because…” It’s not supposed to be a perfect answer, but it should show what you’ve thought about, such as commercial impact, scalability, or customer support. Chickening out of an answer for fear of “getting it wrong” is a lost opportunity for you to show the interviewer what you’ve got. 🐔Somehow not answering the question at all is a particular skill sometimes encountered. While yes, you should have your STAR stories at the ready, occasionally you’re so eager to tell the story (and it could be a great story!) that you forget the question completely. It’s fairly clear when it happens because the way it usually goes down is that you launch into your story and halfway through (hopefully) catch yourself and ask: “I’m sorry, what was the question again?”
It’s time!
So you’ve got a product interview in the diary and it’s finally your time to shine! Remember the basics - it’s supposed to be a conversation, not an inquisition/Q&A session. Not only are interviewers looking for product qualities, ultimately you’re hired based on whether people like you and can see you fitting into their team or not.
The questions you’ll receive really depend on the product you’re interviewing for, the company culture, your interviewer’s experience, personality, and other factors. Some you can prepare for, and some you can’t. If it’s a more technical product, you may expect questions around scalability, load factor, or API connectivity. Are you able to build a product that users can understand how to use? Do your research - good research shows.
If it’s any relief, the state of product management seems to be better in recent years. Previously, a lot of organisations and interviewers didn’t really know what they’re looking for in a PM, and that was reflected in the interviews too. With the growing emphasis on product management as a discipline, outcomes over outputs, it should also give you, as an interviewee, more clarity on what to expect.
Be authentic, not a parrot of product frameworks. Tell stories, and most importantly, the Story of You. Good luck! 🫡