Product interviews are not about product.
Why product management interviews don’t filter for real product skills.
Interviews for product management jobs select for smart people, but not good product managers.
Almost all PM interviews ask the candidate to walk through a product case. This typically means talking through a hypothetical situation in which they improve an existing product, or design a new one.
A quick search before the interview will reveal details about what a candidate should, and should not do during these cases. The resulting articles usually suggest a framework for answering these questions and boil down a few key pieces of advice.
One of the most common suggestions is this: when speaking about any product in the interview, make sure to list out the potential users and what each one would like out of that product. Every interview I’ve done has put significant emphasis on this. So much so, that if a candidate doesn’t do well on this simple task, their whole interview might be tainted.
Considering what a product manager does, this makes no sense. Actually, PM interviews as a whole don’t make much sense. They do an alright job of filtering for smart people, but don’t ask the right questions to filter for good product people.
Let me give an example. Say Erin is interviewing for a PM job. Erin is asked how he or she would design a bookcase. If Erin doesn’t start off by asking the interviewer something along the lines of “well, who is the book case is for?”, they’ll loose big points. Imagine they do ask this. They are told the bookcase is for a child. Having done the research, Erin knows that he / she is then expected to elaborate that there are potential users beyond just the child. They are also the parents who will buy the book case, the baby sitter who might help the child read, and even the grandparent who may visit the house. Here is the particularly weird part: they are then expected to list what each one of these people wants out of the book case.
Anyone who has even made anything knows that this is not how it works. If that same candidate got hired and proceeded to just guess what their users wanted on their first product, they might lose their job.
PM interviews cherish the “jobs for people” section of a candidate’s answer. The part that has them say, “this customer wants x so they can do y.” By doing so, they propagate a competition of who can make up the most arbitrary, yet convincing reasoning. That is maybe a decent measure of intelligence, but not of knowing how to build products. This is a small question, but it invalidates the entire interview’s legitimacy. It transfer’s the focus from product sense, to BS’ing ability.
It would be much more telling to ask a candidate how they would go about discovering those x values. It’s not important that a PM know book case use cases, but rather that they know how to discover the hidden needs of their customer. That is because most people who set out to build anything and really talk to their users, quickly discover that they are building the wrong thing.
There are a handful of counter arguments in favor of how these interviews are structured. First, in a big company, a PM will have those needs handed off the them by user researchers. But, the PM still needs to be able to vet and understand the process behind extracting those needs, in the same way they need to understand the technology. Second, a few PM’s I’ve spoken to have said that there just isn’t enough time to dive into how the candidate would learn about their users. But, the number one reason products fail is because teams build the wrong thing. What could be more important than asking a candidate how they will discover the right thing? This seems much more important than asking them to guess.
As I said before, it seems to me that PM interviews are good at identifying critical thinkers, not necessarily product managers. Maybe that is a good enough proxy. But I propose adding a simple question: how would you figure out what your users want?
