ISSUE #156 - FEBRUARY 24, 2023
In this post, I am sharing my thoughts on formulating a solid interview process for hiring a product manager, given the role requirements and the available interviewing tools.
Hiring is one of the most critical functions within a company. Your people's quality defines your company's quality, and the same stands for product teams. At the same time, hiring is difficult for the employee and occasionally unfair for the candidate. You only have a few hours to evaluate a person's skills and experience. This is a challenging task since just a bad day for either the interviewer or the interviewee could end up with a bad result.
Over the past few years, I have been on both ends of the table, so in this post, I will draw from my experience on how to formulate a solid interview process that will help you hire a competent product manager.
As in product, before defining the solution, you must first identify the requirements you'll build on. In general, the high-level requirements that you need to take into account are:
Are you looking for an entry, mid or senior candidate? The seniority of a person you will hire will significantly affect the process and interviewing tools that you will select. For instance, when looking for an entry-level individual contributor, the scope of responsibilities and required experience are limited. When looking for more senior people, like a senior product manager or a group product manager, to manage broader product areas or even people, the areas you have to evaluate are more in number and more complicated simultaneously.
It's no secret that product management is a versatile craft. Although every product manager should possess a particular core skill set, in most cases, even in the same company, the role of a product manager and the necessary skills will differ from team to team. As a result, you must consider the main aspects of the role that need to be satisfied to define what type of product manager you are looking for and consequently adapt your interview process and tools.
For instance, you sometimes need people who are great at managing demanding stakeholders. Or in other cases, you need someone with an aptitude or a background in design because this particular product area demands it. You might need someone more experienced with B2C products with loads of data and a huge space for experimentation. Or a person who has struggled with early stages of the product lifecycle.
As you can easily understand, possibilities are endless here. In my experience, finding someone exceptional at every aspect of the job is pretty rare. Consequently, it's essential to have a clear picture of what type of product manager you are looking for.
Before setting up the process, let's look at the tools you have at your disposal to help you evaluate the skills and competencies of a candidate:
Before writing any further about interviews, I must stress that setting up a proper interview plan is highly complicated, and this post cannot cover this topic to the appropriate extent.
However, as we all know, during interviews, you can ask a series of questions to help you learn more about the person in front of you and their experience. My favorite type of question is what is called "behavioral questions." They usually have this format:
"Tell me about a time that..."
What I love about this type of question is that they require the candidate to draw from their experiences and talk about something specific rather than dumping generic theory about product. For instance, if you want to understand the candidate's experience with managing stakeholders, you could ask, "Tell me about a time that you had to make a decision opposing a powerful stakeholder's request and how you handled it."
As a bonus, this type of question also helps you understand if the candidate can structure and present their thoughts properly.
With assessments, I'm primarily referring to "take-home assessments." They are a great tool to help you better understand how candidates think, work, and present their work. They have the benefit of giving the candidate space and time to work on a certain case, but on the other hand, they require the candidate to dedicate time and effort that they might not have or are not willing to.
The scope and deliverables of the assessment can vary depending on the seniority and skillset you seek. Usually, the scope would be narrower for entry-level positions and broader as seniority increases. At the same time, you should adjust the particulars or the type of deliverables depending on the core skill set you want to evaluate.
For instance, let's assume that you are hiring for a slightly junior position, and you need your candidate to possess some core analytical skills, basic prioritization competencies, and knowledge of some craft fundamentals like writing user stories and acceptance criteria. On top of that, let's add one more important requirement, to be exceptional at identifying problems via leveraging data and experiments. In this case, it might be more sensible to present the candidate with some data and ask them to identify a problem in a narrow product area. Then ask them to break down the problem further, think about potential solutions, prioritize them, and think about how they would evaluate success.
On the other end of the spectrum, you could be hiring for a senior person and looking for more advanced competencies, like the ability to execute on large-scale initiatives, run structured monthly and quarterly cross-team planning, or even coordinate discovery sessions to align on the product mission. I could keep adding to the list, but in that case, a more advanced case study would serve, where the candidate would be presented with a broader business problem and would be asked to present not just a tactical approach of how they would attempt to solve this problem, but also a more strategic view, emphasizing on business viability and risks evaluation.
When it comes to case studies, there are also some caveats. Firstly, I would avoid assigning a case about the product that I am currently working on. Because of our knowledge of our products, we tend to judge the candidates based on that knowledge, mistakenly expecting them to make the same considerations that we make after years of experience with this product.
Furthermore, even if you are using a case study that is not about your product, regularly change the concept. After some time and a few interviews, you're so familiar with this case, that you will fall prey to your own bias and expectations, having unrealistic expectations from a candidate that sees this case for the first time.
Last, don't make the case study unnecessarily big. You don't need to check every single aspect of the product management craft, but only the skills that are important to you. The smaller the assessment, the greater the chances that the candidate will dedicate time and effort to the areas that matter, and you will get a more realistic picture of their competencies.
This could be considered a hybrid approach of the two above tools. In hypothetical scenarios or role-playing exercises, you can work with candidates on specific exercises, interact with them in real-time, and get a more representative idea of how a candidate communicates, thinks, and works with others.
In this interview area, "product jams" have been quite popular over the past few years. Uber introduced them, and during such a product jam session the candidate is presented with a problem and is asked to work alongside the interviewer toward a solution. For instance, such a case could be: "You are working with Uber and are asked to launch Uber rides for kids. How would you approach this?"
Product jams are fun as they are interactive and creative. It's also a more direct evaluation medium; you can often get a more realistic idea of how a candidate collaborates and discusses with others about a problem. However, you must always remember that not all candidates operate well under circumstances that require instant responses. Some people work at their best when they can take their time while studying a problem.
An interview process can be split into three high-level stages. The first would be the introductory part, where you usually validate that you are on the same page with the candidate and the candidate has the fundamentals needed, so it will make sense to invest more of your and your colleagues' time interviewing them. It's usually consisted of a maximum of one or two interviews, the first one generally with a recruiter that will check the high-level craft competencies and ensure that the candidate's expectations are aligned with the company's expectations and requirements. The second one is with the hiring manager or a fellow product manager who will dig deeper into the core competencies required for the role.
The second stage is the longest and longest stage of the interview in terms of time. It's where the deep dive into the candidate's skill set happens and can be consisted of multiple steps, and frequently many different people participate. It's also the most "expensive" stage of the interview process. At this stage, you must ensure that the candidate possesses all the necessary skills to give them the best chance to succeed once they join the product team. Depending on the seniority and the areas evaluated, it could take between two to four sessions.
The last part is the one where you practically do your sanity check. At this point, you already have a clear picture of whether you will likely extend an offer or not. So, at this stage, you are either trying to dig deeper into particular areas in which you might have small doubts, or you are just looking for any red flags that you might have missed in the previous stages. During this stage, it's common to focus more on the cultural fit, so it's a good idea to let the candidate meet their reporting line or even the rest of the team.
Given the above stages, I have found that the hire's seniority plays the most crucial role in deciding how many steps should consist of the process and its content. I'll describe the hiring process I would select for three cases: Junior-mid level Product Manager, Senior Product Manager - Individual Contributor, and Group Product Manager.
The process described below is more relevant when looking for an individual contributor with limited experience in product to take ownership over a specific narrow product area.
I would break the process into four steps:
In this case, the process described is more appropriate when looking for a more seasoned product manager to join the team as an individual contributor working with sufficient independence and taking ownership of a broader product area.
The process would be quite similar to the previous one in terms of steps with a few more additions:
The ideal candidate for this kind of position is someone who takes ownership of a broad product area and manages at least three other high-performing product managers contributing to that area. People management and coaching are also crucial to the desired skill set.
Given the above, the process would be slightly extended in this case:
As you have already realized, hiring is not just a tricky and complicated process but also extremely costly. Many people are involved and it's time-consuming both for the interviewers and the interviewee. So, setting up the proper hiring process while evaluating the product managers to onboard to your team is crucial to increasing your chances of finding the right person.
ISSUE #13 - JANUARY 24, 2023
In this post, I am sharing some thoughts on my OKRs and how they look like, planning and the time horizon of early-stage roadmaps, and opportunism when..
ISSUE #12 - DECEMBER 15, 2022
Ten product leaders from US, UK and Greek startups, scale-ups and Big Tech share their greatest learnings for the past year.
ISSUE #11 - NOVEMBER 14, 2022
How to create an experimentation-driven culture within your product team? What are the steps to set this up? How to manage & prioritize your experiments?
Once every month, I’m sharing my thoughts on product, growth & entrepreneurship.
Latest Newsletters
ISSUE #25
What to do when you don't know what to do next
ISSUE #24
When good docs go bad: Learning from a PM's misstep
Copyright © Manos Kyriakakis