PM인데 개발은 하나도 모르는데요.
주니어 PM의 스타트업 적응기 #4
PM을 꿈꾸는 많은 사람들, 특히 나와 같은 신입/주니어 PM을 준비하는 사람들은 한 번쯤 이런 고민을 해봤을 것이다.
'개발에 대해서 잘 모르는데 PM을 어떻게 준비하면 될까?'
문과 출신인 나에게도 취준을 하면서 가장 크게 부담으로 다가왔던 부분이다.
실제로 여러 회사 면접을 봤을 때, 모든 회사에서 개발 경험이 없는데 어떻게 극복할 것이냐는 질문을 공통적으로 받았었다.
당연한 소리다.
PM은 개발자 디자이너와 가장 가까이에서 소통하고 해결책을 찾아나가야 하는데, 개발을 모른다면 해결책을 쉽게 찾을 수 있을 리 없기 때문이다.
하지만, 아직까지 개발에 대해서 거의 모르는 나도 PM으로 취업에 성공하고 실무를 진행하고 있듯이 개발을 모르는 사람도 PM 업무를 담당할 수 있다고 생각한다.
해답은 노력이다. (너무 뻔한 말이지만 어쩔 수 없다.)
조금 더 구체적으로 말하자면, PM 업무를 진행하며 발휘할 수 있는 역량을 최대한 강화하고, 개발 지식은 남들보다 조금 더 빠르게 배우고 익히면 된다.
이런 생각을 가지게 된 계기는 역시나 실무를 진행하면서 느낀 점이 있기 때문이다.
처음 입사했던 날, 많은 동료 PM이 있을 것이라 기대했던 것과 달리 회사에서 정확히 PM이라는 직무명을 가진 사람은 나뿐이었다.
물론 시니어 PM 역할을 수행하고 있던 사수가 있었지만, 그는 PM 자리가 공석이었기에 PM의 일을 하고 있었던 것이지 COO와 PM을 동시에 담당하고 있었다.
다시 말해보자면, 회사의 정식 PM으로는 내가 최초 입사자인 것이다.
스타트업에 PM 직군이 등장하고 인기를 얻게 된 역사가 짧기 때문에 어떻게 보면 당연한 얘기일 수도 있다.
(PM에 관심이 있어서 이 글을 읽고 있는 분들도 입사했을 때 회사의 첫 PM이 될 가능성이 꽤 있다.)
다만, 서비스가 출시된 지 4년이 넘었고 직원 수도 100명 이상인 스타트업에 PM이 없을 것이라고는 상상하지 못했기 때문에 살짝 당황스러웠었다.
다행히 원래 PM 업무를 담당하던 사수가 개발자 출신인 데다가, PM에 관심이 많았기에 업무를 진행하는 데 있어서 굉장히 많은 도움을 주셨다.
어느 회사의 신입사원과 마찬가지로 나도 처음 입사했을 때 회사의 서비스를 상세하게 파악하는 일부터 진행했다.
특히, PM은 서비스를 누구보다 잘 알고 있어야 업무 진행이 수월해진다고 생각했기 때문에 최대한 빠르고 깊게 서비스를 파악하고자 노력했다.
입사하기 전부터 알고 있던 서비스였고, 실제로 사용해봤던 서비스였기 때문에 파악하는 데는 큰 어려움이 없었다.
원래 예정되어있던 온보딩 기간 중 3주가 서비스 파악이었지만, 나는 입사 첫 주에 모든 정책 문서를 훑고 머릿속에 집어넣었다.
빠르게 업무를 파악한 만큼 실무에도 빠르게 투입되었다.
지금 다니고 있는 회사의 PM은 크게 '팀 리딩', '프로덕트 리딩', 그리고 '정책 설정' 업무를 담당한다.
나는 경력이 없고 주니어 직급으로 입사했기 때문에 바로 '리딩' 업무를 담당하지는 않았다.
주로 앞으로 출시할 새로운 서비스에 대해 정책을 고민하고 설정하는 업무를 담당했다.
그러나, 회사에서 PM에게 궁극적으로 기대하는 역할은 '리딩'이다.
때문에 나는 정책 설정 업무를 진행하는 와중에도, 사수가 참여하고 이끄는 회의에는 모조리 참석하면서 회의 진행 방법, 팔로우업 등에 대해 어깨너머로 배우고 있었다.
팀을 이끄는 방법이라던가, 하나의 프로덕트가 방향성을 잃지 않도록 붙잡고 있는 방식에 대해서 제대로 익혀두어야 한다는 점을 어렴풋이 알고 있었지만, 최소 6개월은 지나야 리딩 업무를 담당할 것이라고 생각하고 있었다.
그렇게 입사한 지 4주가 지나고, 새로운 PM분도 입사하게 되었다.
새로 오신 분은 경력자로 들어오셨고, 개발 관련 일을 해보셨기 때문에 나보다 훨씬 아는 것이 많으셨다.
나는 아직도 API가 정확하게 무엇인지 모르고 있을 정도로 개발 관련 지식이 없었기 때문에 차후 인원이 더 많아질 PM 직군의 리더는 새로 입사하신 분이 맡을 것이라고 예상하고 있었다.
이처럼 나와 '리딩'은 아직 동떨어진 부분이라고 느끼고 있었다.
불과 며칠 전이었다.
출근하면서 쌓여있는 메일함을 보던 중 누군가 내가 쓴 브런치 글을 보고 PM 멘토링 프로그램의 멘토가 되어줄 것을 제안했다.
PM으로 커리어를 시작한 지 한 달이 갓 넘은 시점이기에 멘토보다는 멘티에 더 어울린다고 생각해 정중하게 거절한다는 회신을 보냈다.
그러나, 브런치에 내가 쓴 글이 다른 PM을 준비하는 분들에게 도움이 될 수도 있을 것이라는 생각에 조금은 자신감이 생겼고 뿌듯하기까지 했다.
기분 좋은 발걸음으로 사무실에 출근하자마자 먼저 출근해있던 사수가 나를 미팅룸으로 불렀다.
"오늘부터 제가 담당하던 팀 회의 진행 직접 담당해보세요. 앞으로도 원래 제가 하던 팀의 PM 자리도 직접 담당하게 될 거고, 추후 입사할 PM들 중에서도 가장 시니어처럼 업무가 주어질 겁니다. 할 수 있죠?"
굉장히 부담스러운 업무를 내가 담당하게 될 것이라는 갑작스러운 소식에 어안이 벙벙해지고 두려움이 밀려오기 시작했다.
정말 내가 할 수 있는 일인지, 입사한 지 한 달이 조금 넘은 신입이 해도 되는 일인지, 내가 개발자랑 당장 바로 이야기를 할 수 있을지 등 오만가지 생각이 나를 압도했다.
압박감 속에 나는 힘겹게 대답했다.
"근데 제가 해도 되는 일인가요?"
정말 궁금한 부분이었다.
API, JSON 등 기본적인 개발 지식도 없는 내가 시니어 PM처럼 일을 한다는 게 말이 안 되는 것 같았다.
"PM에게 정말 중요한 건 역량일까요? 지식일까요?"
사수가 내게 되물었다.
아마도 지식이 부족해서 매번 회의가 끝난 뒤 사수에게 물어보고, 그동안 참여했던 회의마다 이해가 안 된다는 표정으로 모르는 용어를 끄적이는 것을 봤기 때문일 것이다.
과연 역량과 지식 중 어떤 것이 PM에게 더 중요할까?
현재까지 업무를 진행해보면서 PM에게는 역량이 더 중요하다고 생각한다.
여기서 말하는 PM의 역량이란 익히 알려진 커뮤니케이션 능력을 넘어서 일의 우선순위를 빠르게 캐치하거나, 목표/가설 등을 잘 세울 수 있는 능력을 말한다.
PM이 개발 관련 지식을 많이 가지고 있고 IT 방면으로 똑똑하다면 업무에 큰 도움이 되는 것은 부정할 수 없는 사실이다.
그러나, 이는 PM에게 핵심적인 부분이 아니다.
지식은 업무를 진행하는 동안 학습하고 배우면 되는 것이기 때문이다.
하지만, 역량은 지식처럼 단기간에 학습할 수 있는 것이 아니다.
만약 개발자 출신의 PM이 우선순위를 잘 정하지 못한다면 PM의 업무를 제대로 수행할 수 없을 것이다.
따라서, PM에게 더 중요한 것은 역량인 것이다.
따라서, 나는 지식이 부족하지만 역량에 있어서는 어느 정도 도전해볼 수 있겠다는 생각이 들어서 '리딩' 업무를 진행하기로 했다.
입사한 지 5주 만에 정말 남들이 말하는 PM처럼 OKR을 설정하고, 프로덕트 매니징을 통해 비전을 제시하는 일을 진행하게 되었을 뿐만 아니라 동료 PM들이 방향을 잃지 않게 도와주는 총괄 역할도 담당하게 된 것이다.
나 자신을 믿고 패기 있게 도전했지만, 사실 오늘 처음으로 회의를 진행해보고 리더급 회의에도 참석해보니 앞으로 잘할 수 있을까라는 두려움이 더 크게 다가왔다.
하지만 언제나 그랬듯이 적응할 수 있을 것이라고 생각하고 있다.
더욱이 앞으로 조금은 소홀해졌던 개발 관련 공부도 다시 진행해야겠다는 동기부여도 생겼다.
저번에도 말했던 것처럼 내일은 출근이나 잘해야겠다.
