What I’ve Learned After Years of Interviewing for Product Management Roles
I’ve been doing product management for over 15 years. Over this time, I’ve interviewed hundreds of people for various product roles, in different business sectors and companies, in both B2B and B2C environments. As I shaped my interviewing skills and techniques and looked for high-quality content in this space, I realized that while much has been written on interview techniques and processes, there is very little practical information about hiring for product management roles that address discipline’s specifics and the applicable complexities.
Here you can review what I consider to be the key lessons from years of experience. I skipped the obvious — you don’t need me to tell you to define the role, the ideal candidate profile, and the hiring process. You can google that. I put together the insights that are trickier to uncover and reach.
What’s written here is probably more relevant for product leaders who hire for product management roles, but I think there’s much to learn from it also for product managers who are on the candidate side.
Only some of the candidates are product managers
Most of them aren’t. Not by experience, but more importantly, not by understanding the role and the profession. When I talk about this with colleagues, they share the same experience and perspective, and some think it is a perception problem. For many people the Product Management role sounds attractive and powerful — you define priority, guide the R&D, and talk to customers. In some cases, you create wireframes and define the experience of users in websites and apps. Sounds attractive indeed.
I think there’s a deeper reason and it has to do mainly with understanding the Product Management role — not only among people who are new to the profession, but in some cases, also among people who have been working in Product Management roles for years. What makes someone a product manager is not defined by prioritization, wireframing and features delivery. It is about being problem-aware and a solution-maker. This is why when hiring for Product Management roles, I’m looking for people who have the capabilities and determination to constantly try to identify problems and friction on the customer’s end and come up with solutions. Again and again.
How to identify a problem-aware and a solution maker candidate?
There is no simple way to reach high certainty. Especially not in a short, 1 or 2-hour interview. One simple yet effective way to assess this is by asking the candidate, “What does your company do?” I almost never pass a candidate who fails to answer this question. The answer I’m after covers exactly the 2 aspects of being a product manager — the problem and the product that solves it. The answer I’m after is delivered in terms of a market problem statement, customer challenge, how the product solves this, the value proposition, and differentiators. You’d be surprised to find how complex it is to answer this question clearly, in a structured manner, even if the company they work for is big and has a well-known and widely used product.
One simple yet effective way to assess this is by asking the candidate, “What does your company do?”
The skills you can’t avoid having
There are many important skills and characteristics you want a product manager in your company to have. Experienced product professionals who hire for their teams, sometimes prioritize technical knowledge, domain expertise, communication skills, analytical capabilities, and other skills. All are indeed important, but I consider them a bonus. The 3 most important characteristics I’m looking for in any candidate are curiosity, being an interviewer and practicality. Why? Because these attributes are strongly tied to the core of what a product manager is, synonymous with almost everything needed for a person to identify a problem or opportunity, look for ways to solve it, and, out of many options and factoring all relevant constraints, build a practical solution.
Curiosity, being an interviewer and practicality
The home assignment debate
There’s a long debate about the concept of home assignments. Many companies give a candidate a task to prepare, usually at an advanced stage of the hiring process. I see this as annoying, but necessary. Unlike some other disciplines, in product management, you can’t give the candidate a technical or analytical problem to solve and learn about her capabilities. Being problem-aware and a solution-maker is difficult to uncover. When giving a candidate a home assignment I usually make sure to follow these principles:
- make it the last step in the hiring process
- send it in writing
- make sure the assignment includes a wide business problem/opportunity to address
- include questions (and look for answers) that are typical to the product management thought process — problem definition, opportunity size, assumptions, alternatives, selection, scope definition, and success metrics
- align expectations — about the scope of the work, the deliverable and how it will be provided
Using big words
Many candidates (and people in general), including the smart and experienced professionals, use big and abstract words to describe concepts, products, and solutions. It sounds good and impressive. It is even required in some cases. Still, I tend to prefer candidates who use plain language. It is a strong sign that the candidate has the depth and the understanding required to translate ideas and concepts to simple words, in a way that anyone can understand — me, peers, developers, customers, and top management.
Self-awareness — bet on it over experience and knowledge
From time to time we fail. So do other professionals. It takes high maturity for someone to talk about failures openly — especially in an interview. I’m always inspired to see, even after years of working together, how people who are armored with the self-awareness that is required to admit failure and are open to feedback, are the material that makes product teams excel. Discussing failures and identifying openness to feedback during an interview process is critical. If you are caught in a situation in which you need to choose between a candidate who is self-aware and open for feedback and another candidate who is more experienced and knowledgeable but lacks this ability, I’d go for the first one. No doubt.
The annoying “why?”
“Why?” is probably the question I ask most. I use this to challenge my team, my peers, my management and myself. I do so in interviews as well, for many professional details a candidate tells me. As product managers, we are required to prioritize ideas, features, requests, and many other things on a daily basis. A crucial part of the job is explaining our decisions — to ourselves, and to others. It is almost impossible to do so without passing through the “why?” question — in every decision we make. Use “why” again and again, long after you’ve hired someone for your team. It will make your product team much more reasoned and data-backed for any decision they make.
Use “why?” to challenge your team, peers, management, and yourself
Being alternatives-aware
We all try to look for the right answers, to make sure we make the right decisions. It is deeply inherent in us as human beings. I’ve seen candidates and product managers who are so passionate about making just the “right decision”, that they can no longer see there’s more than one option in front of them. I have much higher appreciation for product professionals who are attentive to the alternatives to choose from when solving a problem or building a solution, over others who were able to come up with a solution — even if it’s the right, even perfect solution — but didn’t comb through the dilemmas, options, and alternatives.
Finally, interviewing and hiring a product manager vary significantly depending on the company, its need, role definition, organizational structure, and more. Hiring a product manager for a B2C company can be quite different than hiring for a B2B company. Screening for a product manager for a startup is very different from hiring for a large corporation. Still, save for some adjustments, in my experience, my lessons here apply to most types of companies and product management roles.
