如何聘請出色的產品經理?

在一個初創公司干招聘有段時間了，在初創公司招人跟在大公司是相當不一樣的。在 Yahoo! Search ，感覺好像我們總是在招人。我每週要做5-8 個面試。像是有永無止境的簡歷，面試和錄用協議。現在我不總在做招聘經理了。工作的時候，也就只招聘很少的幾個產品經理。但是公司也總在招聘，我經常是面試團隊的成員。在大公司，你首先能注意到的就是分工很細緻。在初創公司，大家都要或多或少做各種事情，所以你需要的是全能手。更重要的是，未來是難以預測的，所以你得招聘適應性強的人。你可能認為你要找個來幹某項特別工作的人，但是沒準幾個月之後情況就變了。這跟大公司的招聘方式不同，通常招聘的時候，你腦海裡就知道你要的是什麼職位的人，而且發生變動的可能也很小。在 Yahoo! 招聘到的人，大多數可能都不適合初創公司。我記得一些以前招聘的對話，差不多都像是這樣的—— 「好吧，我不太確定他們是完美的候選者，不過看起來都挺適合這個職位，那就都收了吧。」 在大公司這樣可能有用，在初創公司的話，這就是找死的想法。

我的職業生涯作為工程師開始，並很快邁入高進工程管理隊列。在此期間，我大概僱傭了上百名工程師。我學到了大量和招聘有關的知識，大部分是從錯誤中汲取。當我轉而成為一名產品管理者的時候，我可以運用一些招聘方面的經驗以僱傭技術人員，但我又學到了一整套全新的教訓。上週，一個朋友告訴我，他需要僱傭一名產品經理，想聽聽我的建議。我意識到，關於面試產品經理並沒有豐富的好的訊息告訴他（一般意義上講也就是沒有 有關產品管理的豐富而又好的建議）。更關鍵的是，你應該尋找的產品經理，不管你是在什麼樣的環境 – 創業公司或大公司都不是很多。因此我想把一些我學到的組合在一起。

夥計，記住，沒人叫你出現

產品管理是一個團隊即使缺少了（至少一段時間內），也能正常運轉的職位。沒有工程師，什麼都做不出來。沒有銷售員，什麼都賣不出去。沒有設計師，你的產品看起來會像是垃圾。但在沒有產品經理的世界裡，大家都能簡單的填補這個空白然後繼續自己的生活。一定要記住——作為一個產品經理，你就不是必需品。現在，從長遠的角度講，好的產品經理確實能決定成敗，但你得給出證明。產品管理還結合了很多其他職位的元素——工程，設計，市場，銷售，業務拓展。產品管理這個學科，充滿了古怪的，被拋棄的，完全不適合其他地方的人。拿我來講，我喜歡技術方面裡的挑戰性，除了寫代碼。我喜歡解決問題，但討厭被別人指手劃腳。我希望參與戰術決策，我想要擁有產品。市場在創新性上很吸引我，但我知道我不想離技術太遠。工程師們都尊敬我，但也知道我的心在別處，他們都認為我是太「市場化」 的人。像我這樣的人們，自然都會被吸引到產品管理中來。

1. 只招聘聰明人

我在尋覓一名 PM 時該做什麼？更重要的是，天生聰明。我寧願要一個鬼靈精的沒有經驗的 PM，但他的智力要超過智力平平的和具有多年經驗的人。產品管理是從根本上講決定了你的出路，比你的競爭對手領先一步，並能夠將你自己印在你的同事和客戶的腦海裡。我時常問候選者一系列的分析問題以衡量他們的智力和解決問題的能力。通常來說，我問問題一直要問到我認為候選人比我聰明為止。由於某些原因，我所瞭解的大多數人都討厭這樣做。他們認為這是在侮辱候選人。我認為合適的候選人將津津樂道的挑戰。事實上，這是第一次測試 – 當他們怎麼反應過來的時候，我說「我想問一些理論問題，這樣行不行？」最好的一群人，通常會伴隨著興奮的表情跳出自己的椅子。而超級精明的人有時會用這些問題反問自己。

2. 較強的技術背景

我認識的一些管理者都堅持只招聘有計算機科學學位的人作產品經理。我不是個勢利的人，但我也傾向於喜歡有技術背景的人，這可能跟我是文科出身有關。有堅實的技術背景可以給產品經理兩個關鍵的技能——與工程師聯繫起來的能力和管理驅動產品開發的技術細節的能力。當然這也跟產品有關係——一個接觸底層開發 API 的產品經理，肯定要比一個負責個人網站前端設計的產品經理需要知道的技術細節要多。但是基本的原則還是適用的——有技術背景的產品經理，在向工程師傳達產品需求和向非技術出身的同事及顧客解釋複雜的技術細節時，要更成功一些。雖說如此，還是有一些陷阱你需要避免。最重要的事情是，一個曾經是工程師的產品經理，他（她）必須認識到自己只是一個——前工程師。讓人驚訝的是，一個從工程師出身的產品經理，如果仍試著去控制技術決策和實現細節，他終將失敗。正因如此，我喜歡招聘一些有技術背景，而且在上份工作就已經轉為產品經理的人。他們已經經歷過了那段有挑戰的適應期，而且也可以通過看簡歷瞭解他們適應的怎麼樣。我懶得在面試的時候問一些問題來評估技術能力。這根具體的技術方向有關係，而且如果你想找的是工程師，有成百上千的網站可以給你提供不錯的建議。相反，下面是一些不錯的問題，能夠評估出一個產品經理對這個角色的適應性以及他與工程師一起工作的能力：

• 你為什麼決定從工程師轉為產品經理？
• 你覺得有技術背景的最大優勢是什麼？
• 最大的劣勢是什麼？
• 你在轉型為產品經理過程中得到的最大教訓是？
• 你希望你在作為一名工程師時就已經學會的東西是？
• 你如何取得一個工程師團隊的尊敬？

3. 「超人能力」的產品本能和創造力

這個章節非常具有主觀性，很難表述但是又異常重要。我是一個特定人群產品本能是與生俱來這一觀點的忠實支持者。這些人就是知道什麼樣的產品是好的產品。他們或許不總是對的，但是他們的本能總會把他們帶到正確的方向。他們趨向於某一種觀點的強烈支持者，而這些觀點有時會使他們的同事懊惱。我很幸運曾經與許多這樣的人一起工作過，而且對於產品經理來說那是非常重要的鍛鍊。那種感覺只能意會不能言傳。對於產品管理，當處於像網絡這樣高度變化的環境中時，會涉及到許多小而雜的決定。當然了，這裡面也可以有大的構想與決策。但是呢，就是這些小的決策就能區分出這個產品經理是過的去的還是相當棒的。當同一小組的其他人都沒有想到而他們提出自己的建議後其他人立刻恍然大悟時你會發現他們的「超人能力」。當在一次面試中去評判這種產品本能確實是一種挑戰。但是這也是可以完成的。我經常做的一件事兒就是在一小時的面試中去觀察他們是否完成了下面所有的面試任務：

獨立的重複我對我的產品的一些我自己的看法-如果你是一個好的產品經理，你就會考慮到許多影響產品的事情。或許是產品的外觀不好，功能太少亦或是產品構造本身就有需要被指出來的缺陷。這些是你應該想著去彌補的事情。我一直在等到一個時刻，那個時刻讓我微笑，點頭，甚至的忍不住的說：「對對對-你說的那些也是很讓我們抓狂的事情」。
展示一些關於我們產品的新東西給我-這些新東西可能是我從沒想到的對產品的改進，一個打到競爭對手的主意亦或是一個一直被忽視的問題。當我從應聘者哪裡獲得這些訊息，我就知道了兩件事兒：第一他們勇於評判，第二他們比我聰明。而這兩件事兒正是我需要的產品經理所應該具有的。

引導我去瞭解新的或者有趣的事物-有好的產品本能的人趨向於在其他人之前就意識到更好額產品。如果我正在面試一個一流的應聘者，我往往會一邊想著新的發現或者新的創意一邊走開。
以下是一些關於判斷對產品的直覺的不錯的問題：

講個你最近遇到的好的產品吧。你喜歡他什麼地方。[順便說下，面試時候候選者說出一個我的產品的話，實在是要搞的我要瘋了。我在 Yahoo! 經歷過一段痛苦的日子，招聘的時候他們經常說最近碰到的最棒的產品是 Yahoo!，真是痛苦死了。]
什麼使得[在這說個產品]成功？[我通常選個流行的產品，像 iPod 或者 eBay， 這都是在擁擠的市場裡輕易取得顧客青睞的產品。]

• 你不喜歡我產品的什麼方面？你會怎樣改進？
• 我們在一年內會遇到什麼樣的問題？兩年呢？十年呢？
• 你怎麼確定一個產品的設計是好的？
• 你想出的最好的點子之一是什麼？
• 最差的一個呢？
• 你怎樣判斷什麼時候該走捷徑讓產品上市?
• 在交互界面設計方面你有什麼經驗教訓？
• 你怎麼決定什麼東西不該做？
• 你最大的產品失誤是什麼？
• 你對產品經理的什麼方面最不感興趣，為什麼？
• 你覺得自己很有創新性嗎？

4. 領導力是贏取來的

產品經理常常是他們機構裡的領導者。但是他們常常沒直接領導其他人的權利。這就意味著他們必須通過影響力來贏得權威和領導。領導和人際關係技能對一個產品經理來說是起決定性作用的。關於領導能力有成千上百本書，所以我不願把這篇文章變成這個主題的文章（這些書中大多都是廢話）.我發現背景調查是衡量領導能力最有效的方法，特別是涉及到同行和一起工作的個人參與者的調查。但是不要把這些給候選者提及。但是這裡有我過去用到的幾個問題：

• 共識始終是一件好事嗎？
• 管理和領導之間的區別是什麼？
• 你喜歡和什麼樣的人共事？
• 你覺得什麼類型人難於共事？
• 告訴我一個團隊沒有凝聚力的情況。你認為是什麼發生了這種情況？你從中學到了什麼？
• 你如何讓一個團隊給你個時間表？
• 做了什麼事的人會讓你失去對其的信心？
• 你管理不同職位的人會有所不同麼？如果有，有什麼不同？
• 從說不中你學到了什麼？
• 上線一個產品誰要負最終的責任？
• 你的團隊有過讓你失望，並且讓你不得不承擔責任的情況麼？
• 過去今年你對容忍錯誤有什麼變化？
• 你最喜歡好消息還是壞消息？
• 你招聘的方法是什麼？

5. 引導多樣化觀點的能力

成為一個產品經理需要戴多頂帽子。我經常開玩笑說產品經理大多數工作時間是在叫喚誰沒在房間——客戶，工程師，銷售，主管們，營銷們。這意味著你需要有做其他人工作的能力，但是你要足夠聰明的話這是不必的。好的產品經理知道如何引導多樣化觀點。產品經理常常扮演魔鬼的角色。他們有不滿意簡單回答的傾向。在一次交談中他們可能告訴你這個需求似乎技術上不可行，同時問這對銷售員又有多少意義。有一個簡單的方法來評價一個應聘者的能力，通過想一個多角度的問題——在面試過程中會遇到許多人。我常常堅持至少能代表工程，設計，營銷的才算一個潛在產品經理。根據特定的角色這個列表可以添加——售前，工程，支持，開發者關係，業務開發，法律或者是客戶他們自己。最終要和這個人工作的人要滿意，注意我沒說需要每個人都要滿意。一個精心挑選出的人能滿足一個關鍵點就行了。這並不意味著每個人都要讚揚才行——在一個很多應聘者的面試過程中很難達成共識，所以適當的考慮反饋。但是沒有人能夠判斷產品經理像銷售員一樣理解銷售流程。我也強烈建議你給應聘者詳細的說明，例如：「我想讓你明白在引導開發中人們所面臨的問題以及實際現場中我們怎麼做他們會支持你」 。這裡有一些我以前用的詳細問題（這些僅僅是例子，感覺很輕鬆來替換功能的名字）：

• 你學到怎樣和銷售一起工作了麼？
• 和客戶溝通最好的方法是什麼？
• 什麼使營銷起作用？
• 你怎麼知道設計是在正確的軌道上？
• 一個產品經理怎麼支持業務發展？
• 關於管理你學到了什麼？
• 和高管們工作的最好方式是什麼？

6. 給我一個已經做出過東西的人

最後一個特性也許是最容易評估的。除非是招聘初級的職位，否則我通常會僱用那些做過實際產品的經理們。這裡「做過產品」指的是從頭到尾，從概念設計到產品運行的整個過程。沒有什麼比之前做過一個成功產品，更能說明一個人具有做出好產品的能力。過去的表現預示著未來的成功。更重要的是，在一堆需要評估的無形的特性中，它是有形的。當需要驗證時，我總是確保跟應聘者之前項目中那些重要的同事談話，尤其是項目經理的經理、他們的工程師、銷售或市場同行。（順便提一下，上面這些規則的排序是有原因的。正如我在前面第一條中提到的，我寧願選擇一個雖然沒有成功經驗但非常聰明的人作項目經理，也不會選擇一個雖然有經驗卻表現平平的人）。

說明：我寫此文的時候是在 2005 年，當時我還在 JotSpot，而 2006 年的時候， Google 收購了 JotSpot。從那時開始，我有機會同一些非凡的項目經理們共事，並且參與了兩百多位項目經理的面試。我非常確定我的觀點發生了變化，但這些年只是讓我進一步確認了偉大項目經理們的這些特性。我偶爾會去更新這邊文章，但是每次我都決定保持它原來的樣子。

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.