How to Pass the Product Manager Interview
medium.com
medium.com
Of all the PMs I've worked with personally, this has been the single largest problem. A PM that has patience and knows how to pick and stick to the most important thing until it's done is worth their weight in gold. It takes balls, because priorities always seem to change from day to day, management applies pressure to the PMs to get more done than is realistic, and engineers are fickle and perfectionist and usually slower than they predict. I've seen a good PM walk this line, but people who can do it are rare. I'll take someone who really can do the job of prioritizing well over someone who knows a lot any day.
Comparatively speaking, the lower on the totem pole, the easier it is to get compliance. It's the higher-ups of the world who, in my opinion, tend to think of themselves as exempt from "getting with the program" until somebody pulls rank. I hate pulling rank but if the chain needs a yank, it's for the project and company, not me.
The job of a PM isn't to translate fickle external whims into a constantly churning set of priorities. That isn't management. It's reaction. And it's worthless.
A real product manager manages those competing interests and influences, and translates that into a focused, steady set of priorities and an overall direction. And if priorities must change or direction must move, that PM must make those decisions carefully, and must exude a sense of focus and control when doing so.
But the right question is not "What do I want?" but "What need to be done?". That means having different priorities than my wishes and understanding the work on some non-sexy features that will make the product stronger in the long run.
One thing I noticed, though, is that what needs to be done could change, in a startup environment pretty quickly, and having been on the other side, it is pretty difficult to understand. So you need to communicate clearly why priorities are shifting, and you need to be able to take the blame if they are shifting due to a mistake you have done.
Anyway, my suggestion to any wannabe PM: Thinks of what is important for the product, not what you (or the stakeholders) want in the product. Second, be clear in your communication.
Google suggests doing behavioral interviews instead (which I've also been trained to do and have gotten good results). Technical interviews and such may be necessary as well, of course.
Now that I'm an interviewer, I stay away from them completely. :)
I know the intuitive idea is that you'll get to see how the candidate reacts, but that can be done in a less arbitrary way (and in a job-dependent context) through behavioral interviews and the like. Brain teasers are also often poor candidate experience, since they can feel unfair and unrelated to the work. If estimation is a key feature for PMs, it should be part of the interview process with well-defined procedures.
This will give you the general idea of how they work. I'm sure there's classes and other resources, but we already have a training program at work so I haven't delved into them as much.
I find PMs need the ability to break down problems into manageable pieces to calculate, and estimate things with lots of ambiguity. How else do figure out whether an idea is viable or not, and worth spending more time on going deeper on?
And I meant to say fermi problems, not drake's equation.
I agree that product managers need the ability to break down big problems (or requirements/client requests/company direction) into manageable pieces for their team to work on. However, there are better ways to gauge this ability, such as...
- Ask directly for an example of how they have taken a big problem or assignment and broken it down in the past
- Give them a real-world big problem you've had recently and ask them how they would break it up into team tasks/user stories/whatever you use
- Ask them to explain their methodology for determining how long something will take to build or test (ex. some people love planning poker, other people love logarithmic buckets, other people base estimates on experience, and others do something completely different)
Basically you'll get a lot more value out of interviews if you ask directly for experience or process they'll be using rather than trying to back into a skill estimate using a brain game.
It's very unlikely that you have any way of knowing that, since you don't know how good people who fail would have been at doing the analytical part of the job.
Have you seen some tech websites? I used to research competitors as part of my prior job and some of the tech websites out there do a really bad job of explaining what their product IS, much less what it DOES.
For those of you here on the flipside, make sure your website explains WHAT you do, and more importantly, WHY I should care enough to call you and give you money. When I'm dealing with potential vendors/technology partners I am 100% more likely to call a company that tells me why I should care up front than a company that's blowing smoke on their website and doesn't want to tell me why I should care until I call them and talk to a sales rep.
If someone simply abruptly said "I don't know" without any follow up, then it would give me serious pause for concern.
By all means, be succinct. Admit you don't know. Ask if the interviewer wants to hear your methodology you would use to get to an answer.
A good PM tailors the message for their audience. My experience set is different from OP, I interview product managers in the non-technical B2B space.
FYI, this is known as a Fermi problem, named after the famous physicist Enrico Fermi. The classic Fermi problem is, "How many piano tuners are there in Chicago?" [1]
Every company wants a PM that is a jack-of-all-trades. This could be any degree of technicality, UX skills, marketing skills, developer skills, design skills, customer success skills, sales skills, and PM skills (prioritization, specs / user stories / strategy / go-to-market / scoping / shipping etc). If you aren't a jack-of-all-trades, pick up some hobbies / books / go to meetups to make yourself as well-rounded as possible.
Every company wants someone that is deep in one of the areas above.
Commonalities between companies are they want someone that is a foot deep across every skill set, and a mile deep on one skill set.
Figuring out where you fall on the scale of things and make sure you find a company that is looking for your exact strengths is the most important thing to pass a PM interview. Screen the company as they would screen you. Once there is a match, then Sam's advice kicks in if they are looking for a Technical Product Manager.
For aspiring PMs, I highly recommend taking a job in customer success as a gateway into product management. You learn a lot about working with customers, prioritization, and should be aligned with seasoned PM's at the company for advisement and mentorship possibilities.
- Understand the product, target audience, competition
I don’t really care if they understand the product during the interview process.
The purpose of the interview, in my opinion, is to see if they have good product intuition, a well reasoned problem solving framework, strategic insight, leadership qualities, mental horsepower, etc. If these things exist, they can learn about my product, target audience, and competition.
In fact, I actively prefer to not talk about the products I work on because it leads to a biased and loaded conversation. It’s a lot harder to impress me when it comes to something I think about every single day, especially when you’ve only had 3 days to think about it. However, if we both talk about Medium, for example, the playing field is leveled and the candidate will feel more comfortable.
- Metrics
Metrics absolutely matter. But if you’re letting them lead the conversation based on projects they’ve worked on and just talking about metrics they measured, your results will obviously not be calibrated.
I much prefer to ask a calibrated question that allows me to compare candidates to each other. Ideal questions walk through defining metrics that would dictate success for a certain product, outlining how to run experiments, and then walking through a fictitious metric drop to get an understanding of how they would decompose the problem.
- Don’t bullshit
Agreed. But I would prefer “I don’t know, <insert follow up questions to get to an answer>” when possible.
- Prioritization
Agreed, they should have a good framework for prioritization. I like to couple this with a product intuition question where we’re riffing off of each other to come up with solutions to a problem.
- Engineering Divide
Sure. I think it depends on the role, and if this is ideal for you then that’s reasonable.
- Brainteasers
Brainteasers are easy to game and don’t mean anything. Google famously published that brainteasers are not effective at predicting outcomes.
You can test their ability to make assumptions, tackle a problem, etc without giving brainteasers.
Want the job? This is the real selection criteria at west coast startups:
1) Went to interviewer's school and/or worked at my buddy's startup
2) Drinks the kool-aid? i.e. willing to work 60+ hrs/week below market
3) Previously held self titled "Chief Product Officer" position at "startup" that failed after 3 months
That comment was very insightful. People hiring product managers would now know how some others in the company think if they brought in friends or candidates with inflated titles.
One of my very talented friends quit his job for the exact reason. There are CTOs who do not know the difference between java and javascript. We tried to hire an accountant who had a title "Advisor to startups" after talking to her for few minutes we had to rethink hiring.
The specific experiences you describe in your comment are another matter. That kind of thing is substantive and can be the basis of a thoughtful comment.
If the company continues to succeed in spite of itself, eventually that guy (it's almost always a guy) gets sacked and they bring on someone who's at least managed a team of product managers elsewhere. The new person almost always has a hiring process similar to the one in the post, having either figured it out from experience or from reading one of the many articles very very very similar to this one.