P.M Must Read 02 : How to Hire a Product Manager vol.01

오늘 번역할 글은 이미 테크 씬에서 너무 유명한 명불허전 Ken Norton의 가장 유명한 에세이인 How to hire a product manager" 입니다. 구글에서 PM 으로 근무하면서 우리가 현재 쓰고있는 Google Docs, Google Calendar 및 Google Mobile Maps 팀에서 일했습니다. (그냥 레전드..)

 

레게노...

 

 

How to Hire a Product Manage

The classic essay that defined the product manager role

https://www.bringthedonuts.com/essays/productmanager.html

How to Hire a Product Manager

 

프로덕트 매니저란 무엇이며 그들이 하는 업무는 무엇인가

어떤 것이 위대한 프로덕트 매니저를 만들며 어떻게 그렇게 될 수 있는가  

 

저는 엔지니어로서 커리어를 시작했으며 꽤 빨리 매니저로 승진을 했습니다. 닷컴 버블 기간동안 100명이 넘는 엔지니어들을 고용했으며 이때 고용을 하며 저지르는 대부분의 실수에 대해 배웠습니다. 이후 프로덕트 매니저로 전직을 한 뒤 이전의 경험을 살려 기술인력 채용에 적용시켰으며 완전히 새로운 경험 또한 얻었습니다. 지난주 저의 친구가 프로덕트 매니저를 고용해야 한다며 조언을 얻기 위해 전화를 걸어왔고 저는 이때 PM을 인터뷰 하기 위한 좋은 정보들이 많이 없다는 것을 알아차렸습니다 더욱 중요한 것은 대기업이든 스타트업 이든 어떤 환경에 놓여있는지 상관없이 pm 에게 무엇을 바래야 하는지 명확하지가 않다는 것이며. 제가 배운 것들을 같이 공유하기로 생각했습니다.

 

아무도 너에게 오라고 한적 없다

PM이 없어도 조직은 잘 돌아갑니다(적어도 한동안은), 하지만 엔지니어가 없으면 아무것도 만들어지지 않으며, 세일즈맨이 없으면 아무것도 팔리지 않습니다. 디자이너가 없으면 모든 디자인은 쓰레기처럼 보일 것입니다. 그러나PM 없으면 그저 그들은 서로의 간의 간극만 있을 뿐입니다. PM은 소모품이라는 것을 기억하는 것은 매우 중요합니다. 물론 장기적으로 보면 훌륭한 프로덕트 매니지먼트는 승패를 가르는 차이점을 만들지만 여러분들은 이것을 증명해야 합니다. 프로덕트 매니지먼트는 여러가지 요소가 융합되어 있습니다 –엔지니어링, 마케팅, 디자인, 세일즈, 비즈니스 개발 등..- 이처럼 서로 어울리지 않는 분야들로 제품관리는 가득차 있습니다. 저의 경우 나는 공학적 도전을 매우 좋아했지만 코딩은 정말 싫었습니다. 문제를 해결하는 것은 좋아했지만 다른 사람들이 저에게 이래라 저래라 하는 건 싫어했습니다 저는 전략적 결정의 일부가 되길 원했으며 나만의 프로덕트를 가지기를 바랬습니다. 팀과의 관계도 마찬가지 입니다 마케팅팀은 저의 창의성을 자극시켰지만 그렇다고 기술팀과 멀어지기는 싫었습니다. 엔지니어들은 저를 존중했지만 제가 항상 마케팅으로 치우쳐있다고 생각했습니다.

 

위에 설명한 저 같은 사람들은 자연스럽게 PM에 끌릴 겁니다.

 

1.      똑똑한 사람을 고용하세요

제가 PM에게 바라는 것은 무엇일까요? 가장 중요한 것은 순수한 지적능력 입니다. 저는 경험 많고 평균적인 지능을 가진 PM보다. 정말 똑똑하지만 경험없는 PM을 선호합니다. 제품관리란 기본적으로 직접 발로 뛰며 경쟁자보다 한발짝 더 빨리 생각하며 동료나 고객의 마음을 자신의 마음에 투영할 수 있어야 합니다. 저는 보통 지원자들에게 그들의 지적능력과 문제해결 능력을 측정하기 위한 분석적인 질문을 던지며 보통 지원자가 저보다 똑똑하다고 장담할 때까지 계속됩니다. 하지만 몇몇 이유 때문에 많은 사람들은 이를 꺼려합니다. 몇몇사람들은 지원자를 모욕한다고 생각합니다. 하지만 올바른 지원자라면 이런 도전을 즐길 것이라 생각합니다. (그런 의미에서) “사실 몇가지 가정적인 상황을 제시하고 싶은데 괜찮을까요?” 라고 물었을 때 반응을 보는 것이 첫번째 테스트 입니다. 가장 뛰어난 사람들은 보통 흥분해서 의자에서 뛰쳐나오거나 그들의 질문으로 받아치는 경우도 있습니다 (비즈니스 케이스 풀이의 중요성, 컨설팅 펌에서 비즈니스 케이스 풀이를 면접에 포함시키는데 앞으로는 PM 면접에도 이것이 포함될 것이라 생각합니다, 실제로 미국이나 인도의 경우는 이를 많이 적용해서 고용중이며, 비즈니스 케이스를 풀려면 해당산업에 대한 백그라운드, 프레임워크 등등 공부할 것이 정말 많으며 이를 융합하여 문제에 녹여낼 수 있어야 합니다..)

 

구글의 사례

https://www.wired.com/2015/04/hire-like-google/

Here's Google's Secret to Hiring the Best People

 

2.     강력한 테크적 백그라운드

제가 아는 몇몇 매니저들은 컴퓨터 사이언스 학위가 있는 PM들만 고용해야 한다고 강력하게 주장합니다. 저는 그렇게 까지 빡빡하진 않지만 (제가 인문학을 전공했지 때문인지는 모르겠지만) 기술적인 역할을 맡았던 사람을 선호하는 경향은 있습니다. 기술적 백그라운드은 PM에게 강력한 도구를 부여합니다.

 

1)      엔지니어들과 소통하는 방법

2)     제품의 기술적 디테일을 파악하는 방법

 

물론 제품의 종류에 따라 다르겠지만, 저수준의 API에서 일하는 PM이라면 개인 웹사이트의 프론트 엔드 개발자보다 더 많은 기술적 배경을 가지고 있어야 합니다 (?!) 그러나 기본적인 원칙은 동일합니다

기술적인 배경을 가진 PM이 제품요구사항을 엔지니어에게 전달하고 기술적 배경이 없는 동료들에게 복잡한 디테일을 더 잘 전달할 수 있습니다. 그렇지만 여러분들이 이런 과정속에서 피해야할 함정 또한 있습니다. 엔지니어 출신 PM은 본인이 엔지니어가 아님을 분명히 인지해야 합니다. 엔지니어 출신 PM들은 기술적 결정과 구현을 책임지면 프로젝트는 크게 망해버릴 수 있습니다. 이러한 이유에서 저는 이전 직장에서 PM으로 이미 이직한 엔지니어들을 선호합니다. 그들은 이미 힘든 적응기간을 거쳤으며 레퍼런스들만 확인한다면 그들이 얼마나 발전했는지를 확인할 수 있습니다. 기술적 역량을 알아보기 위한 지루한 질문들을 여기서 설명하진 않겠습니다. 어떤 기술역량인지에 따라 질문을 달라질 수 있으며 이미 그런 팁들을 제공하는 좋은 사이트는 수백개나 있습니다. 따라서 그런 질문 대신에 테크 배경을 가진PM들이 엔지니어들과 같이 일하는 능력과 역할에 얼마나 적응했는지를 측정하는 질문들이 있습니다

 

1)      엔지니어에서 PM으로 전환하기로 결정한 이유는 무엇인가

2)     기술적 배경이 있으면 어떤 장점이 있는가

3)     가장 큰 단점은 무엇인가

4)     엔지니어에서 PM으로 직무를 변환함으로써 얻은 가장 큰 교훈은 무엇인가?

5)     엔지니어때 알았으면 좋았을 점은 무엇인가

6)     엔지니어링 팀의 존중을 받는 방법은 무엇인가

 

테크적 백그라운드의 기본 SDLC(Software Development Life Cycle)

https://chobopark.tistory.com/222 

[쉬운설명] 소프트웨어 생명주기 정리!! (정의,단계,종류)