How to interview a product manager

This is part 3 of a talk given to the CTO School in New York, covering how to interview for a product manager (Parts 1 and 2). While I continually iterate my approach in the hunt to spot talent and minimize disappointments, this is my latest structure.

I think of interviewing product managers as having 3 parts: 1. deciding what you want; 2. doing a series of traditional “conversational” interviews, and 3. pairing on a problem. At one point I dabbled with pairing-only interviews, but some problems slipped through the cracks. Now I do both.

First, you can’t interview effectively if you do not know what you are looking for. My views on PMs were listed out in part 1, Good vs Bad Product Management.

Interviewing

Ken Norton wrote a truly excellent post, which I try to periodically re-read, called “How to Hire a Product Manager.” If you are interested in this topic, go read or re-read it. He has an excellent list of questions which I often use which I won’t duplicate here.

In addition, here are some others I like to ask:

  • Describe your current role, what you like and what you want to change
  • How do you currently interact with customers?
  • Do you have any side projects?
  • What learning curves are you working on right on?
  • Describe a project you took on where you were initially out of your depth
  • Have you ever asked for forgiveness rather than permission? Tell me about it.
  • How do you handle the barrage of feature requests?
  • Have you been promoted in a previous role?
  • What interesting trends in product do you see coming up?
  • How do you discover new trends?

I am looking for examples of intellectual firepower, creativity, hunger (I love hiring people who can “punch above their weight class” and am willing to take a risk on a candidate to get that hunger), shared values, and the right mix of strength/backbone and humility/generosity. I want to feel like they will be open to our process, but they don’t need to have done our process before. Process can be easily taught.

I am always interested in the recruit’s questions about the company and the product. It can show off a prepared, strategic mind. However, as someone who believes in context, research and data as the underpinnings of good judgement, I don’t think that it would be terribly fair to expect brilliance from an outsider who has not had a chance to do any of that.

A lot of people ask about cool new products. I like to know that the candidate is aware of where the overall market is going, but personally I think it is a bad sign if someone seems too consumed by Product Hunt/Twitter/Techcrunch. As Yoda would say, “Never his mind on where he was!”

Lastly, I try to make sure that the candidate gets interviewed by the different roles they will interface with on a cross-functional team.

Pairing

I also do a pairing session, almost always at a whiteboard. I believe pairing is a useful practice for almost every role in the company. The more real the work, usually the better the pairing session.

Pairing lets me look directly for certain abilities: confidence and humility, asks good questions, thinks intelligently on the fly, reacts well to new data, shows good judgement. The specific exercise chosen lets me probe into specific concerns I might have.

Here are some ideas:

  • Give them a gnarly product problem you are currently working on and see if they can bring good ideas. Note: I usually care more about the questions they ask and their ability to collaborate on solutions, than getting a “solution” correct given their lack of context and history with the product and customer.
  • Give them a feature you are contemplating (or alternatively a startup idea) and ask how one could validate if it was a good idea before building it.
  • Ask them to 1. sketch out a single-screen application (say, an app to do “X”) and then 2. write every single user story behind that application.Note: I do this for candidates where I am confident in their ability to think strategically, but unsure of their ability to think through the details. PMs must do both well.
  • Give them a new business line you are considering, or alternatively an interesting product idea, and ask how one would go about best acquiring customers? Note: if I want to understand their business savvy.
  • Give them a new problem that has been personally bugging you, and ask how one could solve it with a new startup? And then if one should. Note: if I want to test for creativity and ability to think on their feet.
  • Give them a true, complex prioritization debate your team is having and ask them whether outcome, deadline, or output is most important. Note: their answer is usually less important than their questions.

Final note

It is hard to interview for a role if you do not have someone great who already does that role. That is true for engineering, design, product, sales, finance, etc. Part of it is not knowing what to ask. A deeper cause is that you will struggle to parse reality from bullshit in well-prepared answers. You wind up with people who look great on paper, sound great, and then are total disasters in reality. The truth is usually not that they suck, but that they simply do not fit your needs and your culture. Few things in business are worse than firing people, hence the importance of a good filtering process.

I’ve been in the software business for over 20 years and worked with a lot of amazing engineering partners, but I would not hire an unknown CTO without having an engineering friend whom I trusted talk to them first. And that is my same recommendation for teams hiring their first PM or head of product. Get an experienced PM whom you trust to talk to them before you pull the trigger.