How to hire a Product Manager by @blossom_io

It’s been a while since I was hiring at a startup, and recruiting at a startup is very different from hiring at a big company. At Yahoo! Search, it seemed like we were constantly hiring. I did an average of 5-8 interviews a week. It was a never-ending drumbeat of resumes, interviews, and offer letters. Now, I wasn’t always the hiring manager. I only hired a handful of product managers in my time there. But somebody was always hiring a product manager and I was usually on the interview team. The first thing you notice at a big company is the amount of specialization. At a startup, everyone does a little of everything, so you need strong generalists. More importantly, it’s hard to predict the future, so you need people who can adapt. You might think you’re hiring somebody to work on something specific, but that something might change in a few months. It doesn’t work that way at big companies. Usually when you’re hiring you have avery specific role in mind, and the likelihood that that responsibility will change is low. Lots of people were hired at Yahoo! that probably wouldn’t have been appropriate at a startup. I recall a lot of post-interview conversations that went something like this – “well, I’m not sure they’re the perfect candidate, but they do seem suited for this very specific role, so let’s hire them.” That may work fine at a big company, but it’s deadly thinking at a startup.

I started my career as an engineer and advanced pretty quickly into engineering management. During the bubble, I probably hired over one hundred engineers. I learned a lot about hiring, mostly by making mistakes. When I transitioned to product management I was able to apply some of my experience hiring technical people, but I also learned a whole new set of lessons. Last week a friend called to say he needed to hire a product manager and wanted my advice. I realized there’s not a lot of good information out there about interviewing PMs (there’s not a lot of good information about product management in general). More to the point, there’s not a lot about what you should look for in a product manager no matter what kind of environment you’re in – startup or big company. So I thought I’d pull together some of what I learned.

Remember buddy, nobody asked you to show up

Product management may be the one job that the organization would get along fine without (at least for a good while). Without engineers, nothing would get built. Without sales people, nothing is sold. Without designers, the product looks like crap. But in a world without PMs, everyone simply fills in the gap and goes on with their lives. It’s important to remember that – as a PM, you’re expendable. Now, in the long run great product management usually makes the difference between winning and losing, but you have to prove it. Product management also combines elements of lots of other specialties – engineering, design, marketing, sales, business development. Product management is a weird discipline full of oddballs and rejects that never quite fit in anywhere else. For my part, I loved the technical challenges of engineering but despised the coding. I liked solving problems, but I hated having other people tell me what to do. I wanted to be a part of the strategic decisions, I wanted to own the product. Marketing appealed to my creativity, but I knew I’d dislike being too far away from the technology. Engineers respected me, but knew my heart was elsewhere and generally thought I was too “marketing-ish.” People like me naturally gravitate to product management.

1. Hire all the smart people

So what do I look for in a PM? Most importantly, raw intellectual horsepower. I’ll take a wickedly smart, inexperienced PM over one of average intellect and years of experience any day. Product management is fundamentally about thinking on your feet, staying one step ahead of your competitors, and being able to project yourself into the minds of your colleagues and your customers. I usually ask an interview candidate a series of analytical questions to gauge intelligence and problem-solving ability. Generally I’ll ask questions until I’m sure the candidate is smarter than me. For some reason, lots of people I know are reluctant to do that. They argue that it’s insulting to the candidate. I think the right candidate will relish the challenge. In fact, that’s the first test – how do they react when I say “I’d like to pose some theoretical problems, is that okay?” The best of the bunch are usually bouncing out of their chairs with excitement. The super smart sometimes counter with questions of their own.

2. Strong technical background

Some managers I’ve known insist on hiring only PMs with computer science degrees. I’m not as snobby – maybe it’s my own liberal arts undergraduate education – but I do tend to favor people who’ve been in technical roles. Having a solid engineering background gives a PM two critical tools – the ability to relate to engineers and a grasp of the technical details driving the product. It depends on the product of course – a PM working on low-level developer APIs is bound to need more technical chops than one working on the front-end of a personals web site. But the basic principle applies – product managers with technical backgrounds will have more success conveying product requirements to engineers and relaying complicated details to non-technical colleagues and customers. That said, there are pitfalls you need to avoid. Most importantly, a PM who’s a former engineer needs to realize that he or she is just that – a former engineer. PMs who come from engineering and still try to take charge of technical decisions and implementation details will crash spectacularly. For that reason, I like hiring technical people who’ve already made the move to product management at a previous job. They’ve already gone through the challenging adaptation period and by checking references you can get a feel for how well they’ve evolved. I won’t bore with you with interview questions to evaluate technical competency. They depend on the skill set and there are hundreds of web sites that give good tips for hiring engineers. Instead, here are some good questions for gauging how well a technical PM has adapted to the role and their ability to work with engineers:

• Why did you decide to move from engineering to product management?
• What is the biggest advantage of having a technical background?
• What is the biggest disadvantage?
• What was the biggest lesson you learned when you moved from engineering to product management?
• What do you wish you’d known when you were an engineer?
• How do you earn the respect of the engineering team?

3. “Spidey-sense” product instincts and creativity

This next category is highly subjective, difficult to evaluate, and extraordinarily important. I am a strong believer that certain people are born with innate product instincts. These people just know what makes a great product. They’re not always right, but their instincts usually point in the right direction. They tend to be passionate advocates of a point of view, sometimes to the chagrin of their colleagues. I’ve had the good fortune to work with a good number of these people, and it’s an essential trait in product managers. And it can be tuned, but it can’t be learned. Product management, especially in highly dynamic environments like the web, involves lots of small decisions. Sure, there’s a lot of big thinking and strategy. But it’s the little decisions where a great PM distances him or herself from a decent one. You know they’ve got the “spidey-sense” product instinct when they suggest approaches that nobody on the team has thought of, but immediately strike everyone as obvious when they hear them. Evaluating product instinct in an interview is challenging at best. But it can be done. One thing I always do is check to see if the candidate has accomplished the following tasks during a one-hour interview:

• Independently echoed some of my own concerns about my product – if you’re a good PM, you’ve got a bunch of things that worry you about your own product. Maybe they’re UI shortcomings, missing features, or architecture flaws that need to be addressed. They’re things you know need to be fixed. At least some of these should be obvious to an intelligent outsider with strong product instincts. I look for that moment in the interview when I smile, nod, and say “yeah, I know – that’s been driving us crazy too.”
• Taught me something new about my product – it could be an obvious improvement that I’d never considered, a new idea for positioning against a competitor, or a problem they encountered that needs to be addressed. When I learn something from a candidate, I know two things: (1) they’re not afraid to speak critically, and (2) they’re probably smarter than me. I want both in a product manager.
• Turned me on to something new and interesting – people with great product instincts tend to notice great products before everyone else. If I’m interviewing a top-notch candidate, I usually walk away having discovered something new and innovative.

Here are some good questions for judging product instincts:

• Tell me about a great product you’ve encountered recently. Why do you like it? [By the way, it drives me crazy when candidates name one of my products in an interview. I had a hard time hiring anybody at Yahoo! who told me the coolest product they’d come across recently was Yahoo! Good grief.]
• What’s made [insert product here] successful? [I usually pick a popular product, like the iPod or eBay, that’s won over consumers handily in a crowded market.]
• What do you dislike about my product? How would you improve it?
• What problems are we going to encounter in a year? Two years? Ten years?
• How do you know a product is well designed?
• What’s one of the best ideas you’ve ever had?
• What is one of the worst?
• How do you know when to cut corners to get a product out the door?
• What lessons have you learned about user interface design?
• How do you decide what not to build?
• What was your biggest product mistake?
• What aspects of product management do you find the least interesting and why?
• Do you consider yourself creative?

4. Leadership that’s earned

Product managers are usually leaders in their organizations. But they typically don’t have direct line authority over others. That means they earn their authority and lead by influence. Leadership and interpersonal skills are critical for product management. There are a thousand books about leadership, so I won’t turn this post into a treatise on the subject (most of the books are crap anyway). I find reference checks to be the most effective way to measure leadership skills, especially references that involve peers and individual contributors who worked with – but did not report to – the candidate. But here are a few questions I’ve used in the past:

• Is consensus always a good thing?
• What’s the difference between management and leadership?
• What kinds of people do you like to work with?
• What types of people have you found it difficult to work with?
• Tell me about a time when a team didn’t gel. Why do you think that happened, and what have you learned?
• How do you get a team to commit to a schedule?
• What would somebody do to lose your confidence?
• Do you manage people from different functions differently? If so, how?
• What have you learned about saying no?
• Who has the ultimate accountability for shipping a product?
• Have you ever been in a situation where your team has let you down and you’ve had to take the blame?
• How has your tolerance for mistakes changed over the years?
• Which do you like first, the good news or the bad news?
• What’s your approach to hiring?

5. Ability to channel multiple points-of-view

Being a product manager requires wearing multiple hats. I often joke that much of the time your job is to be the advocate for whoever isn’t currently in the room – the customer, engineering, sales, executives, marketing. That means you need to be capable of doing other people’s jobs, but smart enough to know not to. Great PMs know how to channel different points-of-view. They play devil’s advocate a lot. They tend to be unsatisfied with simple answers. In one conversation they might tell you the requirements don’t seem technically feasible and in the next breath ask how any of this will make sense to the salespeople. There’s one obvious way to evaluate a candidate’s ability to think through a problem from multiple angles – gets lots of people in the interview process. I always insist that at a minimum, representatives from engineering, design, and marketing meet a potential PM candidate. Depending on the specific role, this list can grow – pre-sales engineering, support, developer relations, business development, legal, or customers themselves. Ultimately anyone who will be working with this person should meet them. Note that I didn’t say everyone needs to meet them. One carefully selected representative of each key function will suffice. And it also doesn’t mean everybody has to give a thumbs-up – it’s hard to build consensus in an interview process as the list of interviewers grows, so consider the feedback appropriately. But nobody will be able to judge how well a product manager understands the sales process like a salesperson. I also strongly recommend that you give specific instructions to the interviewers, like “I’d like you to see how well this person would understand the issues you face in channel development, and how we’ll they’d support you in the field. "Here are some specific questions that I use (these are just examples, feel free to replace the functional names):

• How have you learned to work with sales?
• What is the best way to interface with customers?
• What makes marketing tick?
• How do you know when design is on the right track?
• How should a product manager support business development?
• What have you learned about managing up?
• What’s the best way to work with the executives?

6. Give me someone who’s shipped something

This last characteristic may be the easiest to evaluate. Unless the position is very junior, I’ll usually hire product managers who’ve actually shipped a product. I mean from start to finish, concept to launch. Nothing is a better indication of someone’s ability to ship great products than having done it before. Past performance is an indication of future success. Even better, it gives something tangible to evaluate in a sea of intangibles. When checking references, I always make sure to talk to important colleagues from a previous project, especially the PM’s manager and their engineering and sales or marketing counterparts. (Incidentally, these rules are ordered for a reason, and as I mentioned under #1 I’ll still take a brilliantly smart PM over a dimmer experienced one even if the former hasn’t shipped before).

Note: I wrote this in 2005 when I was at JotSpot. Google acquired JotSpot in 2006. Since then, I’ve had the opportunity to work with some marvelous PMs and have performed 200+ PM interviews. I’m sure that my opinions have evolved, but the intervening years have only further reinforced the characteristics of great PMs. I occasionally set out to update this essay but I always decide to leave it as is. (—Ken, February 2013)