One of the things I realise I have been spending quite a bit of time, as I have grown in my career, is in interviewing candidates for Product Management role. Initially when I started doing this, I was rather uncertain about what questions should I be asking that would provide meaningful insight into the candidate's ability to function effectively in this role. Over time, I have evolved a framework to help me structure the interview process so I feel more confident with the hire/no-hire decisions/recommendations I make. I thought it might be worthwhile to share these here for couple of reasons: a) for potential candidates who I might get to interview, so they know ahead of time and are perfectly comfortable with what to expect, and b) there hasn’t been much written online on this topic (besides Ken Nortons essay “How to hire a PM”), so I am hoping that others reading this will share their own methods/techniques that’ll help me evolve my own process.

Needless to say, interviewing is not an exact science, the candidate one rejects may well go on to do great things at other places, but despite its imperfections, for lack of better alternatives, we continue to use this process and attempt to optimise for the odds that we don’t end up hiring a candidate that may not turn out to be good fit for the role; there's an opportunity cost to poor hiring decisions. Depending on your organisational setup, you may optimise your hiring process to be more or less tolerant of false positives at the expense of incurring false negatives depending on the downstream costs of such decisions.

I’ll list out some of the key areas that I focus on, of course, depending on the seniority of the position for which the candidate is being hired, I’ll chose to focus more or less on some of these areas. Essentially when choosing a conversational topic when interviewing candidates, I always apply the litmus test of whether the answers to those questions might be indicative of the candidate's strength or weakness in any area that I intend to assess. As it is, there's very limited time in an interview, so having a conversation without a purpose is a being wasteful of the candidate and the company's time.

Role understanding: A PM role is rather loosely defined, it takes varying forms at different organisations, if anything it's evident by the number of articles written about this role. So, it's natural that the understanding and perception of the role might vary as well, particularly when hiring candidates from college. So, it’s important to get a sense for the candidates understanding of the role and its key responsibility areas. I have penned my thoughts on this in an earlier post. When hiring straight out of college, I recognise the curriculum doesn’t quite prepare one for this role, so it would be unfair to expect the candidate to have a reasonably sound understanding. So, with college candidates I usually take this opportunity to help the candidate understand the role better so they can re-calibrate if this role is aligned with their aspirations. With industry hires, it's generally about understanding how the role was applied at the organisation they worked at, to identify and clarify any variance in that role at your organisation. With industry hires, it helps to understand the structure of the candidates prior organisation as a good proxy to the responsibilities they may have undertaken as PMs. For instance, was there a TPM (technical program manager) role in addition to a Product Manager role what were their responsibilities? was there a separate analytics team, what were their responsibilities? what would a typical feature execution plan look like? etc. are the type of questions I would typically ask to get a better understanding of the candidate's background in this role at their past organisation(s).

Knowledge application: PM is a knowledge worker profile. So, this is a key assessment area, and the focus here is mainly on evaluating your past projects at school or industry to gauge how well you have applied what you have learnt (through school or otherwise) in building great products. The questions I would ask here would be on the lines of why did you decide to build it? who would find it valuable? how did you mitigate your risk on the value proposition being wrong? how did you plan to tell your potential customers about your product? what were the key trade-offs you had to make? etc. Of course, there’s no right answer to these questions, what I look to find in the candidate's answers to these questions is whether he/she exhibits evidence of sound judgement in applying her knowledge and experience when building products.

Action oriented: One of the key attributes that differentiates an ordinary PM from a great PM is a relentless drive to make things better. Drive can’t be drilled into an individual. The nature of the role is such, lot of what becomes of the product you manage is to a large extent influenced by the changes you drive into the product. So, one can sit back and let the product be driven by the business priorities (top down) or take charge and influence product priorities. The easiest way to evaluate this is, to pick some of the projects a candidate has listed on their resume and probe how those projects came about. Typically for the exec-driven projects the answers on ‘why’ would fizzle away quickly and you can filter them out from consideration. Based on a random sampling, you can gauge approximately what % of the projects listed on the resume were driven by product priorities championed by the candidate based on her understanding of the customers using their product and what % were business driven initiatives. A healthy balance is generally indicative of candidates who are driven by the purpose of their role and their responsibility towards their products customers. It’s also a proxy for how well can the candidate influence product priorities with decision makers, engineering, design and other stakeholders.

Curiosity: This a helpful attribute to have as a PM. One of the simplest means to gauge a candidate's natural curiosity is to ask for their favourite books, blogs, podcasts etc. I love to ask this question, for a couple of reasons: a) it tells me how the candidate informs and builds on her knowledge b) it allows me to explore some new and interesting sources to add to my own reading list. Technology is a fast moving field, so it’s important to use any and all means to stay current. How well aware, for instance, is the candidate of the state-of-the-art in their current projects? How do they anticipate that field evolving over time. This is great conversational topic and gives me a good sense for how clearly the candidate can think ahead and apply what they are reading to their own projects. This is particularly useful in the PM role, to be aware of what's out there so you can calibrate your own products trajectory.

Discipline: While some of what's written online about this role might project it as rather glamorous (mini-CEO and what not) it’s important to recognise that a lot of day-to-day PM work is just execution rigour against a plan and there’s hardly anything glamorous about that. One needs to have great discipline/work ethic to be able to execute well against a plan. While it can be difficult to assess this in an interview, in my experience a good way to gauge this is to ask the candidate what does a (working) day in your life today look like? Look for signs that might be indicative of some structure to their day, what % of their day goes into planned activities compared to the unplanned ones. While everyone has a certain portion of their day spent dealing with unplanned events, that shouldn’t be the overwhelming majority of your day, most days. That’s typically indicative of days primarily spent fire-fighting and reacting to events. PMs with strong execution history, typically tend to be quite disciplined about planning their day/week and executing on this plan.

Planning: A candidate's approach to planning can be evaluated by working together on a mini-project. To make the candidate comfortable, I’ll usually have them pick any product they use and ask them if they could change one thing about it what would that be and how would they could go about building/fixing it. Over the course of this conversation, I am essentially trying to assess, how well have they thought about dependencies, declared their assumptions, defined the scope of the problem, identified bottlenecks etc. Anticipating and planning for these ahead of time, usually makes all the difference between landing a project on time or suffering perpetual slips. Planning is as much about making an inventory of the ‘known unknowns’ as it is about listing the 'known knowns’.

Humility: As a PM, one should be humble enough to recognise that the role is dispensable. In other words, you can build a product (though not at scale) without having a PM, someone from engineering or design can fill those shoes (early on). As PMs we understand that not all ideas that can make a product better have to come from PMs. Though by virtue of us spending a disproportionate amount of time using the product and speaking with customers, it invariably happens. The PM should be humble enough to recognise this and accept ideas and feedback from everyone. As you bounce your ideas off other people on the team, maybe design, engineering, QA, operations or whoever, you’ll have disagreements about the rationale/approach, and over the course of these debates sometimes realise, that they have looked at the problem from a different perspective that’s more logical than what you have been peddling all along. Now, some folks may feel defensive at this point and the conversation will spiral into a stalemate. As a PM you have to realise that you’ll be remembered by the products/features you ship rather than by the arguments you won. So swallow your pride, if you must, as long as it yields a better outcome for the product. In an interview, look for instances where the candidate when challenged on certain approach, gets defensive and rather than building on a logical point, gets stuck in her ways.

Besides these, there are some softer skills such as communication, confidence, enthusiasm, dickishness that can be assessed while the candidate goes about answering these questions. You’ll also have questions around candidate's value system, and look for alignment with the company culture. I have talked about culture in a earlier post. Though, culture is not an everyday conversational topic, it’s not uncommon at places where culture is deeply valued to have questions around these to assess alignment.

I hope this framework is useful, both, to people who are new to the process of interviewing PMs and folks who are looking to get hired in the role of a PM. My goal, as I stated earlier, in documenting this framework, is to take away the stress of unexpected questions during an interview. An interview is not the right forum to be springing surprises on candidates to catch them off-guard or to evaluate how well the candidate can think on her feet (unless of course, your organisation functions that way). In my experience that approach doesn’t necessarily yield the most effective PMs. I’ll look forward to hearing about other evaluation areas, tips and techniques that you may have been employing when hiring for PM role.



