PM 직무가 신입을 뽑지 않는 이유

Product Manager로 커리어를 시작하는 방법

Product Manager로 커리어를 시작하고 싶어요.
하지만 다 신입은 전혀 뽑지 않더라구요.
Product Manager로 커리어를 어떻게 시작하면 좋을까요?

지금은 사라진 커피챗이라는 서비스가 있다. 필드의 멘토-멘티를 연결해서 필요한 정보를 주고받는 플랫폼이었는데, 개인적으로 참 애착을 가지고 이용했던 서비스였는데 지금은 서비스를 종료해서 다소 아쉽다. 필자는 커피챗에서 주로 Product Manager(Owner)에 대한 커리어 커피챗을 많이 진행했었는데, 간만에 기억이 나서 과거 자료를 찾아보니 당시에 진행했던 멘토링만 64회나 되었었다. 커피챗 플랫폼이 아닌 비공식으로 진행했던 커피챗까지 포함하면 얼추 100명이 넘는 멘티에게 직간접적으로 도움을 준 경험이 있다.

키리어 커피챗의 메인 아젠다는 주로 PM 직무에 대한 소개와, 어떻게 하면 PM 커리어로의 스텝인을 할 수 있을 것인가에 대한 부분이었다. 애초에 프로필 소개에 가장 도움을 줄 수 있는 부분을 그렇게 기재해둔 영향도 있었겠지만, 정말 많은 분들이 궁금해하시는 것이 ‘어떻게 하면 PM이 될 수 있느냐’에 대한 질문이었다.

오늘은 이 이야기를 잠깐 해보면 어떨까 한다.

1. PM은 신입을 뽑지 않는다.

가장 많은 질문은 역시 PM은 신입을 뽑지 않는데 어떻게 PM이 되었느냐는 것이다.

곰곰히 생각해보면 이상하기는 하다.

PM이 신입을 뽑지 않는 것은 일단은 팩트에 가깝다. 대부분의 채용 공고를 보더라도 3년(주니어)/5년(미들)/7-10년(시니어) 이상의 유관 업무 경험을 요구하고 있으며, 바를 아무리 낮춘다 하더라도 최소 1년 이상의 업무 경험을 요구하고 있다. 네카라쿠배와 같은 대형 IT회사 뿐 아니라 일반 스타트업 수준까지 낮추어 보아도 동일하다. 그렇다면 여기서 의문점이 든다. 그 많은 PM들은 도대체 어디서 튀어나온 것인가? 그들은 커리어를 어떻게 시작했다는 말인가?

이에 대한 답변을 하기 전에, PM 직무는 왜 신입을 뽑지 않는지에 대해서부터 짧게 알아보자.

지난 글인 PM의 역량에 대한 이야기: PM은 개발을 배워야 할까​에서도 짤막하게 다룬 내용이 있다. PM은 specialist가 아닌 generalist에 해당하는 직무라는 것이다.

본인 분야에서의 전문성을 바탕으로 기여하는 specialist와 다르게, generalist는 본인 직무에서의 전문성을 바탕으로 다른 직무들의 업무들까지 포괄하는 역할을 담당한다. Specialist라는 단어가 주는 ‘전문적인’ 어감 때문에 generalist가 전문성이 없고, 한 수 아래의 직무처럼 보일 수 있지만 그렇지는 않다. 되려 본인의 엣지 있는 역량을 기반으로 여러 specialist들의 의견을 조율하는 역할을 담당해야 하기 때문에, 기본적으로 어느 정도의 전문성과 통솔력이 요구된다. 여기서 generalist의 전문성은 의견을 종합하는 역량에 가깝다. 때문에 이들은 일 자체와 속한 도메인에 대한 어느 정도의 이해도가 있어야 하고, 본인과 함께 일하는 specialist들에 대한 리더십을 발휘해야 할 때가 많다. 따라서 기본적으로 어느 정도 이상의 업무 경험(연차)가 요구되는 편이다.

PM은 본질적으로 그 자체로는 아무런 가치를 생산하지 못한다. PM은 개발도 할 수 없고 디자인도 할 수 없다. 즉 PM 혼자서는 고객에게 아무런 가치를 전달할 수 없다. 그러나 PM은 개발자, 디자이너, 분석과 등과 같은 specialist들과 함께 팀으로 일하며 가치 있는 제품을 고객에게 전달한다. 이 과정에서 개발자/디자이너와 같은 specialist들의 의견을 조율하고, 어떻게 하면 최선의 제품을 고객들에게 전달할 수 있을지를 의사결정한다. 이러한 점에서 PM은 generalist 포지션이다.

PM은 다양한 직군들의 이해관계를 조율하고 의사결정해야하기 때문에 어느 정도의 리더십 역량 역시 요구된다. 또한 비즈니스와 엔지니어링을 연결하는 접점에 있기 때문에, 제품 개발 환경에 대한 이해와 동시에 비즈니스 업무 환경에 대한 최소한의 이해도를 동시에 갖추고 있어야 한다. 이러한 영역의 개발은 인재의 역량 포텐셜에도 영향을 받지만, 그것보다는 가치 있는 업무를 얼마나 많이 경험해보았느냐에 조금 더 직결된다. 비즈니스 영역에서는 다양한 비즈니스 모델과 환경에서의 의사결정을 직접 경험해볼 수록, 엔지니어링 영역에서는 다양한 제품/피쳐 릴리즈와 엔지니어링 이슈들에서의 의사결정을 경험해볼 수록(+그 인재의 러닝 커브가 빠를 수록) 이 역량이 더 빠르게 개발되는 경향이 있다. 자전거 타는 법을 책으로 보고 배울 수 없듯, 이와 같은 의사결정의 경험 역시 직접 경험하며 체화되는 영역에 가깝다.

보다 현실적인 이슈도 있다. Product Manager를 뽑을 때는 Product Manager 1명만 단독으로 일하는 환경을 가정하지는 않는다. 최소 1명의 디자이너 + 1-2명 이상의 개발자가 붙어 있는 경우가 대부분이며, 경우에 따라 데이터 분석가 등과 같은 직무들도 포함되어 있을 수 있다. 즉 Product Manager 1명의 채용은 그 1명의 생산성만 연관되어 있는 것이 아니다. 회사 입장에서 Product Manager 채용은 최소 3-4명 이상의 생산성에 영향을 주는 상황에서 이루어진다는 사실을 잘 곱씹어보아야 한다. 회사 입장에서 새롭게 1명을 채용을 했을 때 그 1명의 생산성만 검증해야 하는 것과, 3-4명 이상의 생산성을 검증해야 하는 것은 완전히 다른 문제다. 생산성에 이슈가 있을 때, 전자라면 회사 입장에서 어느 정도의 인내심을 가질 수 있지만 후자라면 이야기는 달라진다.

Product Manager의 이런 특성을 잘 생각해본다면, 회사 입장에서 Product Manager에 신입을 뽑지 않는 이유를 어렵지 않게 이해할 수 있다. 이런 상황에서 지원자의 잠재 역량이 얼마나 뛰어난가는 중요한 판단 요소가 아니다. 제 아무리 좋은 학교를 나왔거나, 뛰어난 공모전 입상 경력을 가졌는지는 중요하지 않다. 회사 입장에서는 이 지원자가 ‘양질의 의사결정을 내릴 수 있는 역량이 충분한 경험을 통해 검증되었는지‘를 중요하게 본다. PM의 포트폴리오가 역시 얼마나 많은 문제를 해결했고, 양질의 의사결정을 내렸는지를 위주로 작성되는 것 역시 이와 무관하지 않을 것이다.

이 외에도 PM이 신입을 뽑지 않고 경력직으로 구성되어 있는 이유들은 차고 넘친다. 어쩌겠는가. PM이 본질적으로 그런 직무인 것을. 간혹 가뭄에 콩 나듯 신입 포지션으로 PM을 채용하는 공고가 나기는 한다. 하지만 위와 같은 이유에서 이런 포지션은 정상적인 포지션이라 볼 수 없으므로 지원자의 주의를 요한다.

2. 그 많은 PM은 어디서 왔는가

이제 다시 중요한 질문으로 들어가보자. 그렇다면 그 많은 PM들은 다들 어디서 왔는데?에 대한 질문이다.

답은 간단하다. PM은 신입을 뽑지 않는다. 때문에 이 PM들은 거의 대부분 연관 업무를 하다 직무 전환을 한 사람들이다. 주변 PM들이 어떻게 커리어를 시작했는지를 물어보면 스펙트럼은 의외로 넓다. ‘아니 이런 직무에서?’라고 생각했던 PM들도 있고, 고개가 끄덕여지는 백그라운드를 가진 PM들도 있다.

한국의 PM의 출신 백그라운드 중 가장 많이 보이는 포지션들은 다음과 같았다.

- 제품 운영 매니저

- 서비스 기획

- 제품 데이터 분석가

- 프로덕트 디자이너

- 개발자

- (IT 회사의)CS운영, 운영기획, 사업기획

- (IT 회사의)사업개발(BDM), 영업

굳이 ’한국의 PM‘이라고 단 것은 한국의 특수한 PM 시장 상황 때문이다. 미국의 경우 PM은 Engineer 출신 위주로 발전해왔다. 때문에 Product Manager라고 했을 때는 어느 정도의 engineering 경험과 동시에 computer science 또는 engineering  학사 학위들을 요구하는 경우가 많다. 이에 반해 한국은 PM 포지션이 2010년대 중반 즈음부터 하여 비교적 늦게 소개되기 시작했다. 그 이전에는 ‘서비스 기획자’라는 역할이 PM 포지션을 일부 겸하고 있었고, 2010년대 중반 이후 agile 제품팀 문화가 소개되며 PM 포지션이 몇몇 기업에서부터 생겨나기 시작했다. 그러나 동시에 IT 생태계에 서비스 기획자의 역할이 뿌리 깊게 박혀있었기 때문에, PM이 서비스 기획자와 비슷한 직무처럼 이해되는 경우가 아직도 많다.(실제로는 매우 다르다) 이러한 한국의 PM 시장 상황 덕분에(?) 한국의 PM은 engineering 역량을 요구하지 않거나 최소한의 수준으로만 요구하는 경우가 많은 것은 취준생들에게는 희망적인 소식일 수 있겠다.

물론 한국에서 그 필수 정도가 덜하다는 것 뿐이지, 개발자 혹은 engineering 백그라운드를 가지고 있다면 크게 유리하다. 심지어 이 백그라운드가 인정받을 경우 일반적인 Product Manager가 아닌 Technical Product Manager(TPM)이라는 훨씬 더 전문화된 직무로까지 연결되곤 한다.

여하튼 본론으로 돌아가자면 한국의 PM은 위에서 나열한 포지션 출신들이 많다는 것인데, 다 달라보이는 이 직무들의 공통점은 어떠한 형태로든 제품의 의사결정에 직간접적으로 영향을 주거나, 경험해볼 수 있는 직무들이라는 것이다. 이들은 제품 의사결정에 조금씩이나마 자연스럽게 참여하기 때문에 관련 경험을 쌓기에 상대적으로 용이하다. 동시에 IT 제품이 어떤 식으로 구성되는지에 대한 필드 이해도 역시 다른 직무에 비해 훨씬 더 쉽게 접하게 된다. 일반인들에게는 그 단어조차 생소한 서버, 백엔드/프론트엔드, 클라우드, 데이터베이스 등과 같은 개념들을 어렴풋이나마 경험할 수 있다는 점 역시 유리한 배경일 것이다. 또한 실제 제품을 사용하는 고객들과의 접점을 경험해보며 제품이 고객에게 어떤 영향을 주는지도 경험해볼 수 있다는 사실 역시 중요하다.

이 직무들을 해보았다고 하여 모두 Product Manager로 직무 전환을 할 수 있는 것은 아니다. Product Manager로 직무 전환을 한 사람들은 해당 영역에서 어떠한 형태로든 문제 해결에 대한 주도성 발휘한 경험이 있다. 이것은 PM들에게 놀라울 정도로 공통적으로 발견된 백그라운드 요소다. 이들의 스토리 역시 대부분 비슷하다. 비록 [본인이 제품에 대한 직접적인 의사결정을 할 수 있는 환경은 아니었지만 본인의 직무를 수행하면서 ‘이것은 문제다’라고 느끼고 -> 제품팀에 제안하거나 스스로 문제를 해결할 수 있는 방법을 찾아서 -> 실제 문제를 해결하고 결과까지 도출해본 경험]이 공통적인 포맷이었다.

이들의 중요한 특징은 본인의 업무 혹은 루틴한 환경에 갇혀있지 않다는 것이다. 본인의 업무에 파격을 주기 싫어하는 분야의 사람들이 있다. 이러한 사람들은 안정된 프로세스를 잘 수행하고, 그 안에서의 역할을 확장해나가는 구조를 가진다. 그러나 PM 직무전환자들은 그렇지 않다. 본인의 업무 환경에서 ‘이것은 문제다’라고 느끼는 부분이 있다면 어떻게 해서든 이것을 고치려고 하고 실제로 고쳐본 경험이 있다. 이들은 ’지금까지 큰 문제는 없었으니까 그대로 두자‘와 같은 의사결정은 용납될 수 없다. 문제라고 판단되면 주변 사람들을 설득해서라도, 안되면 본인이 스스로 나서서라도 문제를 고친다. 이른바 문제 해결의 주도성을 발휘해본 경험이 있는 것이다. (필자가 이렇게까지 자신감 있게 단언할 수 있는 이유는, 이렇지 않은 PM은 대부분 PM 직무에 흥미를 금방 잃고 튕겨져 나가기 때문이다. 역량보다는 직무 특성과 캐릭터에 가깝다.)

이러한 결에서 문제 해결의 경험이 몇차례 쌓이다 보면 다음과 둘 중 하나의 선택지로 이어진다.

1. 회사에서 먼저 알아보고 PM/PO 직군으로의 직무 전환을 제안하거나(대개 원래 있던 PM/PO가 퇴사했을 때 이런 경우가 많이 발생한다)

2. 본인이 먼저 PM/PO 직무에 흥미를 가져서 포지션에 지원하거나

1번이든 2번이든 필요조건은 충분한 수준의 문제 해결 포트폴리오를 보유하고 있다는 것이다.

PM으로의 직무 전환/스텝인이 가장 많이 일어나는 시기는 보통 2-3년차이다. 본인의 최초 직무에 대한 어느 정도의 이해도(본인만의 전문성) + 비즈니스 환경에 대한 이해도 + 제품 환경에 대한 이해도를 모두 최소 수준 이상으로 달성되는 시기이기 때문이다. 또한 본인도 스스로 본인이 루틴한 업무를 하는 것보다는 문제를 주도적으로 해결하는 데에 더 흥미가 있는 사람이라는 것을 깨닫는 시기이기도 하다.

3. 일단은 문제 해결 경험부터

PM 직무를 처음부터 시작하는 방법은 없다

그럼에도 불구하고 PM 직무를 꿈꾸는 취준생들에게 필자는 다음과 같은 조언을 한다.

어떤 회사라도 좋으니, 실제 IT 제품을 서비스하고 있는 회사에 들어가라. 그리고 고객들을 직접 만나고, 다양한 이해관계자들과 협업하며 본인이 직접 고객의 문제를 풀 수 있는 환경을 접해라. 모든 업무가 대부분 도움이 될 것이지만, 그나마 가장 직접적으로 경험을 쌓을 수 있는 직무는 제품 운영 매니저 혹은 운영 기획 포지션이다. 대고객 이슈들을 접하는 것이 메인 업무이면서, 제품팀(개발팀)과의 스킨십 경험 역시 충분히 많이 있기 때문이다.

이 때 주의해야할 점이 있다. 실제 제품이 서비스되지 않고 있는 극초반의 스타트업 혹은 창업팀에 들어가는 것은 대개 비효율적이다. 창업이나 개발, 비즈니스 환경에 대한 이해도는 어느 정도 쌓을 수 있으나 본인이 직접 문제 해결과 결과를 증명할만한 사례들을 만들기는 어렵다. 때문에 본인이 PM으로서의 커리어를 노리고 있다면 1. 실제 서비스되고 있는 제품이 있는지, 2. 어느 정도의 고객들이 확보된 상태인 제품인지를 보는 것이 중요하다.

회사의 규모로 보았을 때는 30명-300명 규모의 회사가 적합하다. 이보다 작은 규모의 회사일 때는 아직 제품 운영보다는 신규 제품 개발에 더 집중하기 때문에 문제 해결 경험을 쌓을 수 있는 기회가 생각보다 적고, 그보다 더 큰 규모의 회사일 경우는 이미 프로세스가 너무 잘 갖추어져 있어 생각보다 주도적인 문제 해결 경험을 쌓기 어려울 수 있다.

——-

PM은 분명 매력적인 직무다. 그렇기에 수많은 취준생들이 PM으로 커리어를 시작하고 싶어할 것이다. 그러나 아직 어떻게 시작해야 하는지 모르는 예비 PM들이 부디 이 글을 보고 더 좋은 경험을 가져갔으면 좋겠다는 마음으로 글을 마친다.

#PM #PO #Product Manager #Product Owner