產品經理(Product Manager),又稱品牌經理(Brand Manager)。是企業守門員、品牌塑造者、更是營銷骨幹。它既是一套完善的營銷運作制度,更是博大精深的營銷操作。舉凡產品從創意到上市,所有相關的研發、調研、生產、編預算、廣告、促銷活動等等,都由產品經理掌控。產品經理依據公司產品戰略,對某個產品(介質、服務、品牌)擔負根本責任的企業管理人員。
英文原文:How to hire a Product Manager
我的職業生涯作為工程師開始,並很快邁入高進工程管理隊列。在此期間,我大概僱傭了上百名工程師。我學到了大量和招聘有關的知識,大部分是從錯誤中汲取。當我轉而成為一名產品管理者的時候,我可以運用一些招聘方面的經驗以僱傭技術人員,但我又學到了一整套全新的教訓。上週,一個朋友告訴我,他需要僱傭一名產品經理,想聽聽我的建議。我意識到,關於面試產品經理並沒有豐富的好的訊息告訴他(一般意義上講也就是沒有 有關產品管理的豐富而又好的建議)。更關鍵的是,你應該尋找的產品經理,不管你是在什麼樣的環境 – 創業公司或大公司都不是很多。因此我想把一些我學到的組合在一起。
產品管理是一個團隊即使缺少了(至少一段時間內),也能正常運轉的職位。沒有工程師,什麼都做不出來。沒有銷售員,什麼都賣不出去。沒有設計師,你的產品看起來會像是垃圾。但在沒有產品經理的世界裡,大家都能簡單的填補這個空白然後繼續自己的生活。一定要記住——作為一個產品經理,你就不是必需品。現在,從長遠的角度講,好的產品經理確實能決定成敗,但你得給出證明。產品管理還結合了很多其他職位的元素——工程,設計,市場,銷售,業務拓展。產品管理這個學科,充滿了古怪的,被拋棄的,完全不適合其他地方的人。拿我來講,我喜歡技術方面裡的挑戰性,除了寫代碼。我喜歡解決問題,但討厭被別人指手劃腳。我希望參與戰術決策,我想要擁有產品。市場在創新性上很吸引我,但我知道我不想離技術太遠。工程師們都尊敬我,但也知道我的心在別處,他們都認為我是太「市場化」 的人。像我這樣的人們,自然都會被吸引到產品管理中來。
我在尋覓一名 PM 時該做什麼?更重要的是,天生聰明。我寧願要一個鬼靈精的沒有經驗的 PM,但他的智力要超過智力平平的和具有多年經驗的人。產品管理是從根本上講決定了你的出路,比你的競爭對手領先一步,並能夠將你自己印在你的同事和客戶的腦海裡。我時常問候選者一系列的分析問題以衡量他們的智力和解決問題的能力。通常來說,我問問題一直要問到我認為候選人比我聰明為止。由於某些原因,我所瞭解的大多數人都討厭這樣做。他們認為這是在侮辱候選人。我認為合適的候選人將津津樂道的挑戰。事實上,這是第一次測試 – 當他們怎麼反應過來的時候,我說「我想問一些理論問題,這樣行不行?」最好的一群人,通常會伴隨著興奮的表情跳出自己的椅子。而超級精明的人有時會用這些問題反問自己。
我認識的一些管理者都堅持只招聘有計算機科學學位的人作產品經理。我不是個勢利的人,但我也傾向於喜歡有技術背景的人,這可能跟我是文科出身有關。有堅實的技術背景可以給產品經理兩個關鍵的技能——與工程師聯繫起來的能力和管理驅動產品開發的技術細節的能力。當然這也跟產品有關係——一個接觸底層開發 API 的產品經理,肯定要比一個負責個人網站前端設計的產品經理需要知道的技術細節要多。但是基本的原則還是適用的——有技術背景的產品經理,在向工程師傳達產品需求和向非技術出身的同事及顧客解釋複雜的技術細節時,要更成功一些。雖說如此,還是有一些陷阱你需要避免。最重要的事情是,一個曾經是工程師的產品經理,他(她)必須認識到自己只是一個——前工程師。讓人驚訝的是,一個從工程師出身的產品經理,如果仍試著去控制技術決策和實現細節,他終將失敗。正因如此,我喜歡招聘一些有技術背景,而且在上份工作就已經轉為產品經理的人。他們已經經歷過了那段有挑戰的適應期,而且也可以通過看簡歷瞭解他們適應的怎麼樣。我懶得在面試的時候問一些問題來評估技術能力。這根具體的技術方向有關係,而且如果你想找的是工程師,有成百上千的網站可以給你提供不錯的建議。相反,下面是一些不錯的問題,能夠評估出一個產品經理對這個角色的適應性以及他與工程師一起工作的能力:
這個章節非常具有主觀性,很難表述但是又異常重要。我是一個特定人群產品本能是與生俱來這一觀點的忠實支持者。這些人就是知道什麼樣的產品是好的產品。他們或許不總是對的,但是他們的本能總會把他們帶到正確的方向。他們趨向於某一種觀點的強烈支持者,而這些觀點有時會使他們的同事懊惱。我很幸運曾經與許多這樣的人一起工作過,而且對於產品經理來說那是非常重要的鍛鍊。那種感覺只能意會不能言傳。對於產品管理,當處於像網絡這樣高度變化的環境中時,會涉及到許多小而雜的決定。當然了,這裡面也可以有大的構想與決策。但是呢,就是這些小的決策就能區分出這個產品經理是過的去的還是相當棒的。當同一小組的其他人都沒有想到而他們提出自己的建議後其他人立刻恍然大悟時你會發現他們的「超人能力」。當在一次面試中去評判這種產品本能確實是一種挑戰。但是這也是可以完成的。我經常做的一件事兒就是在一小時的面試中去觀察他們是否完成了下面所有的面試任務:
獨立的重複我對我的產品的一些我自己的看法-如果你是一個好的產品經理,你就會考慮到許多影響產品的事情。或許是產品的外觀不好,功能太少亦或是產品構造本身就有需要被指出來的缺陷。這些是你應該想著去彌補的事情。我一直在等到一個時刻,那個時刻讓我微笑,點頭,甚至的忍不住的說:「對對對-你說的那些也是很讓我們抓狂的事情」。
展示一些關於我們產品的新東西給我-這些新東西可能是我從沒想到的對產品的改進,一個打到競爭對手的主意亦或是一個一直被忽視的問題。當我從應聘者哪裡獲得這些訊息,我就知道了兩件事兒:第一他們勇於評判,第二他們比我聰明。而這兩件事兒正是我需要的產品經理所應該具有的。
引導我去瞭解新的或者有趣的事物-有好的產品本能的人趨向於在其他人之前就意識到更好額產品。如果我正在面試一個一流的應聘者,我往往會一邊想著新的發現或者新的創意一邊走開。
以下是一些關於判斷對產品的直覺的不錯的問題:
講個你最近遇到的好的產品吧。你喜歡他什麼地方。[順便說下,面試時候候選者說出一個我的產品的話,實在是要搞的我要瘋了。我在 Yahoo! 經歷過一段痛苦的日子,招聘的時候他們經常說最近碰到的最棒的產品是 Yahoo!,真是痛苦死了。]
什麼使得[在這說個產品]成功?[我通常選個流行的產品,像 iPod 或者 eBay, 這都是在擁擠的市場裡輕易取得顧客青睞的產品。]
4. 領導力是贏取來的
產品經理常常是他們機構裡的領導者。但是他們常常沒直接領導其他人的權利。這就意味著他們必須通過影響力來贏得權威和領導。領導和人際關係技能對一個產品經理來說是起決定性作用的。關於領導能力有成千上百本書,所以我不願把這篇文章變成這個主題的文章(這些書中大多都是廢話).我發現背景調查是衡量領導能力最有效的方法,特別是涉及到同行和一起工作的個人參與者的調查。但是不要把這些給候選者提及。但是這裡有我過去用到的幾個問題:
成為一個產品經理需要戴多頂帽子。我經常開玩笑說產品經理大多數工作時間是在叫喚誰沒在房間——客戶,工程師,銷售,主管們,營銷們。這意味著你需要有做其他人工作的能力,但是你要足夠聰明的話這是不必的。好的產品經理知道如何引導多樣化觀點。產品經理常常扮演魔鬼的角色。他們有不滿意簡單回答的傾向。在一次交談中他們可能告訴你這個需求似乎技術上不可行,同時問這對銷售員又有多少意義。有一個簡單的方法來評價一個應聘者的能力,通過想一個多角度的問題——在面試過程中會遇到許多人。我常常堅持至少能代表工程,設計,營銷的才算一個潛在產品經理。根據特定的角色這個列表可以添加——售前,工程,支持,開發者關係,業務開發,法律或者是客戶他們自己。最終要和這個人工作的人要滿意,注意我沒說需要每個人都要滿意。一個精心挑選出的人能滿足一個關鍵點就行了。這並不意味著每個人都要讚揚才行——在一個很多應聘者的面試過程中很難達成共識,所以適當的考慮反饋。但是沒有人能夠判斷產品經理像銷售員一樣理解銷售流程。我也強烈建議你給應聘者詳細的說明,例如:「我想讓你明白在引導開發中人們所面臨的問題以及實際現場中我們怎麼做他們會支持你」 。這裡有一些我以前用的詳細問題(這些僅僅是例子,感覺很輕鬆來替換功能的名字):
最後一個特性也許是最容易評估的。除非是招聘初級的職位,否則我通常會僱用那些做過實際產品的經理們。這裡「做過產品」指的是從頭到尾,從概念設計到產品運行的整個過程。沒有什麼比之前做過一個成功產品,更能說明一個人具有做出好產品的能力。過去的表現預示著未來的成功。更重要的是,在一堆需要評估的無形的特性中,它是有形的。當需要驗證時,我總是確保跟應聘者之前項目中那些重要的同事談話,尤其是項目經理的經理、他們的工程師、銷售或市場同行。(順便提一下,上面這些規則的排序是有原因的。正如我在前面第一條中提到的,我寧願選擇一個雖然沒有成功經驗但非常聰明的人作項目經理,也不會選擇一個雖然有經驗卻表現平平的人)。
說明:我寫此文的時候是在 2005 年,當時我還在 JotSpot,而 2006 年的時候, Google 收購了 JotSpot。從那時開始,我有機會同一些非凡的項目經理們共事,並且參與了兩百多位項目經理的面試。我非常確定我的觀點發生了變化,但這些年只是讓我進一步確認了偉大項目經理們的這些特性。我偶爾會去更新這邊文章,但是每次我都決定保持它原來的樣子。
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:
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:
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:
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):
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.
Recent Comments