6 Common Mistakes People Make in PM Interviews
Common mistakes I see from candidates who've applied to my teams
Before we get started - I recently did a podcast with Digital Leute.
Given I recently wrote about how to attract top product talent, I wanted to do a followup on mistakes I regularly see from candidates who apply for roles or who make it to interviews for product management roles.
There are many reasons a candidate might not succeed when interviewing for a product management role. Finding the right match comes down to skills and cultural fit. The company and candidate must be aligned on values, goals, and intent. Unfortunately, you only have a short amount of time to demonstrate to each other that this role is the perfect fit.
Given all the information available on LinkedIn, Glassdoor, and the internet, there is no excuse for knowing nothing about the company or the person interviewing you. Having said that, preparing for an interview takes a lot more than Googling the company beforehand. It’s about coming up with a real strategy that will define the way you see yourself and your skills fitting into the company. It’s about working out how you will stand out. You must walk in with a strategy that matches your skills to the needs of the organization.
To that end, it's critical to try to get a good sense of the organization before you apply and before your first interview. Listen to podcasts with the founders and with the team. Learn what you can so that you can speak intelligently about the business and the metrics you assume they are tracking closely.
In my experience of interviewing people to join my team, I see six common mistakes:
Mismatch between Product Management background and the skills needed to do the role
It’s in an employer’s best interest to be very clear with a candidate about what they’ll be doing day to day and what the role will entail. The candidate needs to feel confident that they can deliver against the key challenges of the business.
For example, if you are a consumer-facing product manager interviewing for a SaaS role, then you need to prove why and how you will apply your skillset to the Enterprise SaaS challenge. How does your experience apply to the role, even if it’s not a perfect fit? Can you clearly articulate the gaps in your experience and how you would fill them? That’s key as you interview and become more senior as a product manager.
In the previous example, you need to be able to relate your experiences with customer experience and other critical elements in the B2C space to a B2B product and how you could bring those skills to enable a different type of product. Ask the company if they are looking to improve their customer experience, their overall UX, or other elements where you would likely have more expertise. Be honest if you don't have clear expertise with elements like ARR (annual recurring revenue) or if understanding the business model is going to be an area you'll need to learn.
Other examples would be trying to move from a consumer facing product role to a more backend or technical role. In that context, it's critical to provide some reasoning as to why you are interested in the role transition, how you could bring those skillsets to the table, and what elements of your product background would be relevant (managing teams, getting things shipped) and what areas you'd need help (design, customer centric thinking, etc.).
Inability to prioritize and make trade-offs
Prioritization is key in any role and within any company. Most product managers are able to come up with lots of great product ideas. However, when asked to prioritize those ideas based on impact, they are unable to provide a clear answer. It’s vital to have a clear methodology for prioritization and you need to demonstrate it during the interview process.
I recommend something simple for prioritization: what's the expected return of investment vs the effort? While it's not always possible to assess effort, the key is having a rough idea. Part of product management is demonstrating an ability to differentiate between high and low impact ideas and how hard or easy those ideas are to implement. Come to an interview with a framework for how you make decisions, explain it, and use it.
I often ask PMs to do a case study about how they'd solve a particular product challenge we are facing. One of the key things I'm looking for is not only a strategy that leads to a set of possible concepts, but also an understanding of how the PM would prioritize the work, what tradeoffs they'd make, and how they view each feature, optimization, or idea versus the others in their list. If the PM can't show a clear ability to make tradeoffs, it usually indicates they won't be a good fit on my team.
Lack of understanding about the key metrics for the business
When a candidate interviews for a product role, they must spend time hypothesizing the most important metrics and performance drivers for the business. It's good to have a framework in mind for the business you are talking with.
A few examples:
A two-sided marketplace is going to have supply and demand dynamics
Subscription businesses are all about optimization of the funnel to drive subscribers and then retention of those subscribers on a monthly basis
E-commerce businesses are about driving initial and repeat purchase.
Social companies likely have onboarding and then viral loops as their key acquisition and retention drivers
If you can’t identify the key metrics for a business and share ideas of how you would improve them, then you aren't likely to do well in the interview process. And it's ok if you aren't totally sure - no one expects you to perfectly understand the metrics. But it's important that you demonstrate a general sense for the business model. And it's even more important that you have a sense for the metrics for the area you are going to own.
If you take a look at my post about how to structure your consumer facing product team, it's a helpful primer to at least have a general understanding of the key metrics for different types of businesses.
Not able to understand the customer/ not taking the time to understand the customer
It's essential that any product person can understand the customer, their behaviors, and what they want. It's also important to explain the differences in how you will use features for certain types of customers. Larger experience changes, for example, will require more feedback and learning.
I recommend having a methodology in mind for how you approach customers. You should be able to explain how you would contact your users, what sorts of questions you'd ask them, and what you'd be trying to learn. Also, what tools do you typically use to do this? Be able to clearly outline them.
Additionally, make it clear when research is or is not required. For simple A/B tests, it's not critical. For larger product changes, make it clear how you'd structure research and what you would want to learn. It's always good to have an example of how you've leveraged customer feedback.
There are going to be some roles where this skill is less important (technical product roles, backend product managers, etc.). However, even in those, you should be able to articulate who your "customer" was, whether it was an internal stakeholder or someone else. And you should be able to explain how you held yourself accountable to that stakeholder and made sure you were delivering solutions that would meet their business or product need.
Lack of clear data driven results
If you are a product person, you should be able to demonstrate an ability to move the key metrics for the business. You should have:
Clear examples where you worked with your engineering and design teams to move critical metrics for the business
Learnings about things that did not move those key metrics
Clear stories for how you learned and adapted to make important change occur
Why is this so important? A data-driven mindset means you think outside of your personal biases and instead, focus on what the evidence says. It’s one of the best ways to drive improvement; challenging your own assumptions and beliefs, and what you want the results to be, allowing yourself instead to be data and results oriented.
You should also be able to explain the different types of data tools you are comfortable with and how you've used them. It's important as a PM to demonstrate an understanding of at least a few key data tools, whether they are externally or internally built. You should be able to explain the key metrics that you focused on, what you were tracking, and how it impacted your roadmap and plan as a product manager.
Working with an "I" mentality vs a "we" mentality
A big red flag is when a product manager talks about their accomplishments as things they did vs things they accomplished as a team. A successful team is one where members contribute different perspectives, resulting in more creative and productive results. There’s a fine line between knowing what you're capable of achieving and unintentionally appearing to not be a team player. Any successful product manager will work closely with a team of engineers, designers and analysts to meet deliverables. Being able to demonstrate how you lead and work together with these teams to drive the right results is invaluable.
If a PM is taking overwhelming credit for their work and not acknowledging the accomplishments of the team, it's usually a warning sign for me. I want to hear how the PM worked together with their design, engineering, and other partners to build a great setup for a successful team. The best PMs build great squads to work with them. The worst PMs generally are not leveraging the people around them to build a great team and work environment.
One thing is clear: preparation is make or break for any interview. Preparation will enable you to ask the right and relevant questions; it will enable you to be able to clearly articulate your skill-set, aligning it to the company’s business and cultural objectives. Be considered, be innovative; know your strengths, research the company and prepare to impress.
Enjoyed this one as much as the previous article!
Thanks for sharing - very practical and well-written. Looking forward to the next post :)