어떤 프로덕트 매니저를 채용해야 할까
How to Hire a Product Manager
현재 GV(Google Ventures)에서 일하는 Ken Norton의 글입니다. Ken Norton은 Google에서 PM으로 근무했고, Google Docs, Google Calendar, Google Mobile Maps를 담당했습니다. 이 글은 Ken이 2005년, 구글에 인수되기 전 JotSpot에서 일했을 때 적은 것입니다. 그렇기에 대기업(야후!) 경험을 가진 스타트업 가이의 생각이라 보시면 될 것 같습니다. 이 글은 100만 뷰 이상을 달성했으며 Product Manager 관련한 글 중 고전이라 할 수 있습니다. 14년이 넘은 글이지만, 아직도 핵심은 다르지 않습니다. 읽으며 예시로 나오는 인터뷰 문항들에 대한 답을 생각해보시면서 읽으시면 재미있습니다.
참고로 글 제목은 PM을 어떻게 채용할까? 지만, 예시로 나오는 인터뷰 문항들에 하나하나 답 하며 읽다 보면 사실 내용은 PM은 뭐하는 사람이야? 어떤 능력을 가지고 있어야 하나? 에 더 가깝습니다. Ken도 이 글의 10주년 회고 글을 적으며 비슷한 이야기를 적었습니다(HTHAPM was mis-titled. It’s really an answer to the question “what is a product manager?”).
원문: https://www.kennorton.com/essays/productmanager.html
오랫동안 스타트업에서 채용을 해오다 보니, 스타트업에서의 채용과 큰 회사에서의 채용은 많은 차이가 있다는 것을 느꼈다. 야후! 검색 조직에서 일할 땐, 우린 항상 채용 중이었다. 일주일에 5-8번 정도의 채용 인터뷰를 진행했고, 이력서 검토, 인터뷰, 최종 오퍼를 보내는 일들은 끝나지 않는 드럼 비트 같았다. 매번 우리 팀의 채용 인터뷰는 아니었다. 난 PM을 소수만 채용했다. 그러나 누군가는 PM을 채용했고, 그때마다 인터뷰를 보러 들어가야 했다. 인터뷰 시 큰 회사에서 주목해야 하는 포인트는 지원자가 가지고 있는 전문성의 양이다. 그러나 스타트업에서는 누구나 모든 것을 해야 하기에 강력한 제너럴리스트가 필요하다. 더 나아가 스타트업에서는 미래를 예측하기 어렵기 때문에 변화에 잘 적응할 수 있는 사람들이 필요하다. 특정 업무에 적합한 사람을 찾을 수는 있지만, 몇 달 후 상황이 바뀔 수도 있다. 큰 회사는 이런 방식으로 동작하지 않는다. 큰 회사에서 사람을 채용할 때 어떤 역할을 맡기겠다고 계획하면 그 역할이 바뀔 가능성은 희박하다. 야후! 의 채용 인터뷰를 떠올려보면, 스타트업에는 맞지 않을 수 있는 많은 사람들이 인터뷰를 통과했다. 면접 이후에 나눴던 대화를 떠올려 보면 대부분 이런 식이었다. "흠, 내 생각에 방금 면접 보신 분이 완벽한 후보인지는 모르겠는데, 매우 구체적인 역할을 주면 잘하실 것 같아. 한번 채용 진행해보자." 이 방식은 큰 회사에는 맞을 수도 있지만, 스타트업에서는 이렇게 하면 안 된다.
난 엔지니어로 커리어를 시작했고, 엔지니어링 조직에 대한 매니지먼트 경험도 빨리 시작한 편이었다. 닷컴 버블 동안 난 100명이 넘는 엔지니어를 채용했다. 이때 채용에 대해서 많이 배웠는데, 대부분 실수를 통해 배웠다. 내가 PM 포지션으로 전환했을 때, 과거 테크 조직의 사람들을 채용한 경험이 도움이 되었으나 PM채용에 대해서 완전히 새로운 교훈도 얻었다. 지난주, 친구가 PM을 채용해야 한다면서 조언을 부탁했는데 생각해보니 PM 인터뷰에 대한 좋은 정보가 별로 없었다(뿐만 아니라 일반적으로 Product Management에 대한 좋은 정보도 부족하다). 더 중요한 건, 스타트업이든 큰 회사든 상관없이 PM이 어떤 자질을 가지고 있어야 하는지에 대해서도 정보가 부족했다. 이 글을 통해 PM 채용에 대해 배운 것들을 풀어보려고 한다.
기억하자, 아무도 하라고 말하지 않았다
Product Management는 굳이 담당자가 없어도 팀이 돌아가는 데 문제가 없다(적어도 좋을 때는). 엔지니어가 없으면 만들 수 있는 게 없다. 세일즈 조직이 없으면 팔 수 없다. 디자이너가 없다면 Product는 쓰레기처럼 만들어질지도 모른다. 만약 PM이 없다면, 팀의 사람들은 빈 역할을 메우면서 해나갈 것이다. PM은 스스로가 소모품이라는 걸 잘 기억해야 한다. 물론 좋은 Product Management는 장기적으로 이기고 지는 차이를 만들어 낸다. 그러나 이걸 당신이 증명해야 한다. Product Management는 엔지니어링, 디자인, 마케팅, 세일즈, 비즈니스 개발 같은 다양한 전문 분야들을 엮는 업무이며, 다른 곳에서는 통하지 않는 예외와 특이한 일들이 가득한 내부 규칙 같은 것이다. 내 이야기를 해보면, 난 엔지니어링의 기술적인 어려움을 좋아했지만, 코딩을 좋아하진 않았다. 단지 문제를 해결하는 것이 좋았고, 다른 사람들이 나한테 뭘 하라고 하는 건 싫었다. 전략적 결정을 하고 싶었고, Product를 리드하고 싶었다. 엔지니어들에게 존중받긴 했지만, 그들은 내 관심사가 다른 데 있다는 것을 알았고 내가 너무 마케팅적이라고도 했다. 나 같은 사람들은 자연스럽게 Product Management 업무에 빠지게 된다.
1. 스마트한 사람만 채용하자
PM을 채용할 때 무엇을 봐야 할까? 가장 중요한 건 지적 능력이다. 만약 경험이 없지만 평균 이상의 지적 능력을 가진 후보와 수년간의 경험이 있고 평범한 지적 능력을 가진 후보 둘이 있다면, 난 평균 이상의 지적 능력을 가진 후보를 선택할 것이다. 근본적으로 Product Management는 동료들과 고객들 입장에서 생각하며, 다른 경쟁자들보다 한 발짝 앞서 재빨리 대응해야 하는 일이다. 그렇기에 순간적으로 판단할 수 있는 능력을 필요로 한다. 이 능력이 있는지 여부를 파악하기 위해 문제 해결 능력과 지적 능력을 측정할 수 있는 분석적인 질문 리스트들을 인터뷰에 준비하였다. 이 질문들을 후보자가 나보다 똑똑하다는 확신이 들기 전까지 계속 물어본다. 주변 사람들 중 꽤 다수는 이렇게 하는 걸 꺼린다. 이 방식이 후보자를 모욕하는 것 같다고 이야기하는 사람도 있다. 그러나 내 생각엔 좋은 후보자라면 이런 인터뷰 과정을 즐길 것이라 생각한다.
2. 기술에 대한 높은 이해도
내가 아는 몇몇 매니저들은 PM을 컴퓨터 과학 학위를 가진 사람들로 채용해야 한다고 주장한다. 난 그런 잘난 체하는 사람은 아니지만, 나 역시도 기술 관련 역할을 해본 사람들을 선호한다. 엔지니어링에 대한 탄탄한 경험을 가지고 있는 PM이라면, 엔지니어가 가져야 할 능력과 어떻게 Product가 동작하는지에 대한 기술적인 세부사항의 이해, 두 가지에 대해 강점을 가지고 있다. 물론 Product에 따라 PM에게 요구되는 기술 이해도 수준은 다르다. 웹사이트를 만드는 프런트 개발자들과 일하는 PM보다 로우 레벨의 API들을 만드는 백엔드 개발자들과 일하는 PM은 더 많은 기술적인 이해를 필요로 한다. 그러나 기본 원칙은 같다. 기술적인 이해도를 가진 PM은 Product에 대한 요구 사항을 엔지니어들에게 더 잘 전달할 수 있고, 완성된 결과물을 기술을 잘 모르는 동료들이나 고객들에게 잘 전달할 수 있다. 여기엔 피해야 할 함정이 있다. 과거에 엔지니어였던 PM은 본인이 현재는 엔지니어가 아니라는 것을 깨달아야 한다. 엔지니어링 경험을 가진 PM은 종종 기술적인 결정이나 디테일한 구현 방법에 개발자들과 충돌하곤 한다. 이 때문에 나는 테크 경험을 가진 사람 중 이미 전 직장에서 PM 업무로 전환한 사람을 채용하는 걸 선호했다. 그들은 과거에 힘든 적응 기간을 거쳤을 것이고, 레퍼런스 체크를 통해서 그들이 얼마나 성장했는지 알 수 있을 것이다. 이 글에서 기술적 경쟁력을 측정하기 위한 인터뷰 문항들로 여러분들을 지루하게 만들고 싶진 않다. 엔지니어를 채용하기 위한 좋은 팁과 관련한 웹사이트는 정말 많다. 대신 기술 PM 역할에 잘 적응하고, 엔지니어와 함께 일하는 능력을 측정하기 위한 PM 인터뷰 문항들을 여기 소개한다:
왜 엔지니어에서 PM으로 전환하기로 결정했나?
기술에 대한 이해도를 가지고 있을 때 가장 큰 장점은 무엇인가?
가장 큰 단점은 무엇인가?
엔지니어에서 PM으로 전환했을 때 배운 가장 큰 교훈은 무엇인가?
엔지니어였을 때 알았으면 하는 지식이 있다면 어떤 것인가?
엔지니어링 팀에게 어떻게 신뢰를 얻을 것인가?
3. "직감", 제품에 대한 본능과 창의성
제품에 대한 본능과 창의성이라는 능력은 매우 주관적이며, 평가하기 어렵지만 매우 중요하다. 나는 어떤 사람들이 Product에 대한 본능을 가지고 태어났다고 굳게 믿는 편이다. 이들은 훌륭한 Product를 만드는 것이 무엇인지를 알고 있다. 그들이 항상 옳진 않아도 그들의 본능은 올바른 방향으로 인도한다. 그들은 어떤 관점에서는 열정적으로 일하지만, 동료들의 반발을 야기하기도 한다. 나는 운 좋게도 이 능력을 가진 여러 명의 사람들과 일할 수 있었고, 이 능력이 PM에게 필수적인 성향이라 생각한다. 이 능력은 조정될 순 있지만, 배울 순 없다. 특히 다양한 환경에서의 Product Management는 작지만 많은 의사 결정이 필수적이다. 물론 큰 규모의 고민과 전략도 필요하다. 그러나 위대한 PM과 그냥 괜찮은 PM은 이런 작은 의사 결정들에서 차이가 난다. 팀에서 아무도 생각하지 못했지만, 듣자마자 모든 사람들이 명백하게 맞다고 느껴지는 해결책을 제안할 때, 그들이 "직감", 제품에 대한 본능을 가지고 있다는 것을 눈치챌 수 있다. 제품 본능을 인터뷰를 통해 평가하기 위해 노력했지만 쉽지는 않았다. 그러나 불가능하진 않다. 내가 알아낸 유일한 방법은 PM 후보자가 한 시간의 인터뷰 동안 아래의 일을 수행했는지 여부를 체크하는 것이다:
내가 가지고 있는 Product 고민을 똑같이 이야기한다
좋은 PM이라면 본인이 담당한 Product에 대해서 가지고 있는 수많은 고민과 문제들이 있을 것이다. UI에 대한 단점 일 수도 있고, 일부 기능이 누락되거나, 고쳐야 할 구조적인 결함일 수도 있다. 어떻게 보면 이 문제들은 수정해야 할 것들이다. 좋은 Product 본능을 가지고 있다면, 고쳐야 할 문제들 중 적어도 일부는 똑똑한 외부 사람들에게 밝혀야 한다. 이런 내용을 들으면 인터뷰 도중에 난 "그래, 나도 알지. 그 문제들이 나도 미치게 했었지."라고 말하며 미소 지으며 고개를 끄덕이게 된다.
후보자가 내가 담당한 Product에 대해서 나도 모르는 무언가를 알려주었다
내가 담당하고 있는 Product 관련해서 나도 몰랐던 생각을 언급하는 후보자들이 종종 있다. 예를 들면 후보자가 Product에서 직접 발견한, 수정해야 할 문제일 수도 있고, 경쟁 제품에 대한 새로운 포지셔닝 아이디어일 수도 있다. 이런 이야기를 들으면 분명히 플러스 점수이다. 이런 후보자들은 (1) 비판적으로 말하는 것을 두려워하지 않고 (2) 아마도 나보다 똑똑할 것이다. 난 PM들이 두 가지 모두 해당하길 원한다.
새롭고 흥미로운 무언가를 나에게 알려준다
훌륭한 Product 본능을 가진 사람들은 다른 사람들보다 먼저 훌륭한 Product들을 알아차리곤 한다. 내가 만약 최고 수준의 후보자를 인터뷰하고 있다면, 그들은 나에게 새롭고 혁신적인 것을 알려줄 것이다.
Product 본능을 평가하기 위한 좋은 문항들은 아래와 같다:
최근에 발견한 좋은 Product에 대해서 말해보라. 왜 그걸 좋아했나?
[iPod, eBay처럼 성공한 특정 Product를 언급하며] 그 Product는 어떻게 성공했다고 생각하나?
우리 Product의 단점은 무엇인가? 어떻게 개선할 수 있는가?
1년, 2년 혹은 10년 안에 우리는 어떤 문제를 겪을 것이라 보는가?
설계가 잘 된 Product를 어떻게 구분할 수 있는가?
당신이 지금까지 생각한 것 중 최고의 아이디어는 무엇인가?
최악의 아이디어는 무엇인가?
Product를 출시하기 위해 언제 원칙을 무시해야 할지 어떻게 아는지?
지금까지의 경험을 통해 사용자 인터페이스 디자인에 대해서 배운 교훈이 있다면?
무엇을 만들지 말아야 할지 어떻게 결정하나?
당신이 만든 Product에 대한 가장 큰 실수는 무엇인가?
본인에게 Product Management 업무에 있어 흥미롭지 않은 부분은 어떤 부분이며 그 이유는?
스스로를 창의적이라고 생각하는가?
4. 경험을 통해 얻은 리더십
일반적으로 PM은 그 조직의 리더가 되곤 한다. 그렇다고 해서 그들이 다른 사람들보다 높은 권한을 가지고 있진 않다. 다시 말하면, 권한을 직접 얻어서 그걸 통해 리드해야 한다는 뜻이다. 리더십과 대인 관계 기술은 Product Management에서 중요하다. 리더십 관련해서 수천 권의 책이 있기에 난 이 글의 주제를 리더십으로 바꾸고 싶진 않다(대부분의 책은 쓰레기다). 리더십 스킬을 측정하는 가장 좋은 방법은 레퍼런스 체크다. 특히 후보자와 같이 일했지만 그에게 업무 보고를 하진 않은 사람들의 레퍼런스 체크가 도움이 된다. 내가 사용한 리더십 인터뷰 질문은 다음과 같다:
합의를 이루는 건 항상 좋은 방법인가?
매니지먼트와 리더십 사이에 무슨 차이가 있다고 생각하는가?
어떤 사람들하고 일하는 것을 선호하는지?
어떤 사람들하고 일하는 것을 어려워하는지?
팀이 잘 맞지 않았을 때에 대해서 이야기해봐라. 왜 그렇게 되었다고 생각하는가? 그 경험에서 배운 것은 무엇인가?
어떻게 팀이 일정을 지키도록 할 수 있는가?
언제 자신감을 잃는가?
각기 다른 업무를 하는 사람들을 다르게 매니징 할 수 있는지? 어떻게 할 수 있는지?
거절 의사를 표하는 것에 대해 배운 교훈이 있다면 말해보라.
Product를 만들고 외부에 론칭함에 있어서 최종 책임은 누가 가지고 있는가?
팀이 제대로 하지 못한 부분에 대한 비난을 당신 혼자 받아본 경험이 있는지?
실수의 크기/빈도에 따라 허용하는 정도가 다를 수 있다. 경력을 쌓으면서 이에 대한 생각이 바뀐 것이 있으면 말해보라.
좋은 소식과 나쁜 소식 어떤 소식을 먼저 전하는 편인가?
당신의 채용 전략은 무엇인가?
5. 여러 입장을 전달하는 능력
PM이 되려면 다양한 직책을 맡을 수 있어야 한다. 난 종종 PM 업무의 대부분은 현재 이 방에 있지 않은 고객, 엔지니어링, 세일즈, 마케팅 혹은 경영진을 대변하는 일이다 라는 농담을 한다. 이건 다른 사람의 일을 할 수 있는 능력이 있어야 함을 의미한다. 위대한 PM들은 다양한 관점을 전달하는 방법을 알고 있다. 그들은 악마의 대변인 역할을 한다. 그것도 자주 한다. 그들은 하나의 입장만 만족시키는 단순한 답에 만족하지 않는다. 그들은 요청사항이 기술적으로 가능하지 않다고 말하고 난 다음, 그 요청사항이 세일즈 파트 사람들에게는 어떤 의미가 있냐고 물어본다. 후보자가 여러 입장을 고려해 문제를 풀 수 있는 능력이 있는지 평가할 수 있는 방법이 하나 있다. 난 PM을 채용하기 위해선 최소한 엔지니어링, 디자인, 마케팅 부서에서 각각 면접관이 와야 한다고 주장한다. 역할에 따라서 사전 판매 엔지니어링, 고객 서포트, 개발 관계, 비즈니스, 법무, 또는 사용자가 직접 면접관으로 등장할 수도 있다. 다시 말하면, 이 사람과 일하게 될 사람은 누구나 인터뷰에 참가해야 한다. 물론 회사 구성원 전체가 다 PM 인터뷰에 참여해야 한다는 것은 아니다. 각 주요 기능 부서에서 선발된 대표 한 명씩이면 충분할 것이다. 물론 이 방식으로 한다고 해서 모든 부서의 대표에게 OK 사인을 받아야 한다는 건 아니다. 인터뷰를 보는 사람이 늘어날수록 합의를 이끌어내는 건 쉽지 않다. 그렇기에 사람들의 피드백을 적절하게 고려해야 한다. PM후보가 세일즈 과정을 잘 이해하고 있는지 여부를 판단하려면, 세일즈 부서 사람이 가장 적합하다. 물론 매끄러운 면접 진행을 위해서 면접관에게 구체적인 면접 지침을 제공하는 것을 추천한다. 예를 들면 "후보자가 현재 당신이 세일즈 채널을 새롭게 만드는 과정에서 겪고 있는 이슈에 대해서 이해하고 현장에서 잘 지원해줄 것인지 판단하고 싶습니다."와 같은 지침이 도움이 될 것이다. 관련 인터뷰 질문들은 아래와 같다. 여기 있는 직군은 예시일 뿐이니 직군을 바꿔서 질문해도 좋다:
세일즈 부서와 일하면서 어떤 것을 배웠나?
고객을 위한 가장 좋은 인터페이스는 무엇일까?
어떤 포인트를 마케팅 요소로 가져갈 것인가?
디자인이 옳은 방향으로 가고 있다는 걸 어떻게 알아내나?
PM은 어떻게 비즈니스 부서를 지원해야 할까?
매니징에 대해서 어떤 걸 배웠나?
경영진과 Product에 대해서 논의할 때 가장 좋은 방법은?
6. 실제 Product를 론칭한 경험을 가진 사람을 채용하자
마지막 요소는 가장 쉽게 판단할 수 있다. 채용하려는 포지션이 신입이 아니라면, 난 실제로 Product를 론칭해본 경험을 가지고 있는 PM을 채용하곤 한다. 여기서 론칭은 시작부터 끝까지를 의미한다. 과거에 이 경험을 가지고 있는지 여부가, 훌륭한 Product를 만들어서 고객에게 전달할 수 있는 능력을 가지고 있는지를 가장 잘 판단할 수 있는 지표이다. 과거 성과가 미래의 성공을 보여준다. 레퍼런스 체크를 할 때, 난 항상 그가 했던 프로젝트의 중요한 동료, 특히 그 PM의 매니저, 같이 일한 엔지니어, 세일즈 또는 마케팅 카운터 파트와 이야기하려고 한다. (한 가지 덧붙이면, 이 규칙들은 우선순위가 있다. 예를 들면 첫 번째로 언급한 것처럼 나는 똑똑한 PM을 채용할 것이다. 그가 이전에 실제 Product 론칭 경험이 없더라도.)
역자 주.
똑똑하고, 기술적인 이해도도 있으며, 경험도 있고, 리더십도 있어야 한다고 말하는 Ken의 글을 보고 이 사람은 확실히 욕심쟁이구나, 라고 느꼈습니다. 그렇지만 나랑 같이 일하는 사람이 이런 능력들을 가지고 있다면 마다할 이유가 없겠죠.
스마트함이 가장 첫 번째 가치로 언급된 것에는 이견이 없습니다. 그러나 회사에서 필요로 하는 스마트함이 어떤 스마트함인지는 생각해봐야 합니다. 스쿨버스에 골프공이 얼마나 들어갈지 맞춰봐라 류의 퀴즈는 똑똑함을 판단하는데 도움이 될 수 있습니다. 그러나, 이런 문제를 PM이 현업에서 진짜 풀고 있는지 생각해봐야 합니다. 논리 퀴즈보다는 사회적/조직적 상황이 복잡할 때 특정 이슈를 어떻게 해결할지 물어보는 게 더 PM채용에 적합한 질문이라 생각합니다. 항상 리소스가 부족하고, 성장은 해야 하고, 눈에 보이는 명확한 답이 없는 것이 스타트업의 업무 환경입니다. 그 업무 환경을 이겨낼 수 있는 똑똑함은 어떤 종류의 똑똑함일지 생각해보시고 PM 인터뷰에 임하시면 좋을 것 같습니다.
