Partner, Google VenturesFollow @kennethn
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.
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.
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.
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:
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:
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:
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 well 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):
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)
Ken is a partner at Google Ventures. Prior to joining Google Ventures, Ken was a group product manager at Google. Ken joined Google in 2006 with the acquisition of JotSpot, where he was vice president of products.Follow @kennethn