PM의 역량에 대한 이야기: PM은 개발을 배워야 할까

Product Manager는 어떻게 성장하는가

by 도락구

Product Manager는 본질적으로 신입이 존재할 수 없는 직무이다. 기본적으로 제너럴리스트(generalist)의 직무 속성을 가지고 있기에, 본인이 개발한 전문성을 기반으로 다양한 직무의 사람들을 품을 수 있는 역할이기 때문이다. 대부분의 회사에서 PM포지션은 3년 이상, 아무리 레벨이 내려가도 최소 1년 이상의 경력을 요구하는 것은 바로 이러한 이유에서이다.


2010년대 후반 이후 PM 포지션의 인지도가 높아지면서, 새롭게 사회에 나온 초년생들 입장에서도 PM 직무가 소개되기 시작했다. PM은 분명 매력적인 직무이기에 PM으로의 취업을 원하는 취준생도 많아지는 것은 매우 자연스럽다. 문제는 PM 직무가 앞에서 말한 이유에서 신입이 존재할 수 없는 직무라는 것에서 발생한다. 때문에 신입 레벨에서 포텐셜 채용이 이루어지는 경우가 극히 드물 뿐더러, 신입이 PM으로 성장하기 위한 정석적인 코스나 로드맵같은 것 역시 당연히 존재하지 않는다.


신입 입장에서는 막연하다. PM 실무 지침서나, 각종 소개 영상 등은 접할 수는 있어도 정작 '내가 PM이 되기 위해 어떠한 역량을 개발해야 하는지'나 '어떤 경험을 쌓아야 하는지'와 같은 답변은 얻기 어렵다. 이런 막연한 불안감을 가지고 있는 분들을 위해, 어떠한 마인드셋을 가지면 좋을지에 대해 아는 만큼의 글을 써보고자 한다.



1. PM은 제너럴리스트다

PM 직무에 대해서 가장 먼저 알아두어야 할 것은 PM은 제너럴리스트(generalist) 직무라는 것이다.


지식노동의 직무들을 크게 두 범주로 나누어본다면 generalist와 specialist로 구분할 수 있을 것이다. 후자인 specialist는 본인의 영역에 있어서의 전문성을 기반으로 기여를 하는 직무다. 흔히 개발자나 디자이너와 같은 영역이 여기에 속하고, IT회사 밖에서는 재무, 회계, 법무 등과 같은 전문 부서나 세일즈/영업이나 마케팅과 같은 부서의 직무도 여기에 속할 수 있다.


Generalist는 그 반대다. 그 자체의 전문적인 스킬을 강조하기보다는, 여러 specialist들과 협업하며 이들의 전문성을 조율하여 최상의 성과를 이끌어내는 역할을 담당한다. 어느 정도 이상의 연차를 보유를 요구하며, 대개 specialist 직무에 속하는 사람들이 본인의 역할을 확장하며 generalist로 전향하는 경우가 일반적이다. 주니어 레벨에서는 specialist가 본인만의 전문성을 가지고 있으므로 generalist는 전문성이 부족하며, 한 수 아래처럼 인지되는 경우가 종종 있다. 그러나 위에서 언급했듯 실상은 그 반대다. Generalist는 본인 직무에서의 전문성을 바탕으로 다른 직무들의 업무들까지 포괄하는 역할을 담당하기 때문이다. 때문에 대부분 manager 이상의 직급들이 generalist로서의 역할을 담당하며, 어느 정도 이상의 연차를 요구한다.(일반적인 직무명에 들어가는 manager가 아닌, ‘관리자’로서의 manager 직급을 의미한다)


PM의 풀네임은 Product Manager다. Management를 기본으로 하는 직무임을 전제로 한다. 어느 정도의 관리 업무가 주를 이룬다는 것이고, 그 과정에서 개발자, 디자이너 등과 같은 다양한 직무의 커뮤니케이션이 필요하다. 때문에 업무 경험이 아예 없는 신입 포지션이 이 역할을 하기는 힘들며, 운영, 기획, 개발 등의 타 업무를 수행하며 개발자, 디자이너 등과의 커뮤니케이션을 간접적으로 경험해보며 PM으로 직무 전환을 하는 것이 보통의 테크트리이다. 개발자나 디자이너와의 협업 경험이 없더라도, 최소한 타 직무와의 협업 경험에서의 excellance가 요구된다.





2. PM의 핵심 역량을 잘못 이해했을 때

Product Manager는 기본적으로 IT 서비스의 제품을 다룬다. 때문에 IT 개발적인 요소와 뗄레야 뗄 수가 없다. 필자 역시 하루에도 수많은 개발 용어들과 마주치며, 타 직군이 보기에는 거의 개발자와 개발 언어로 프리토킹을 하는 것처럼 느껴질 것이다.


여기서 오해가 나온다. PM은 개발 역량을 필수적으로 갖추어야 하는가?

이것 역시 PM에 대한 질문이나 멘토링을 받으면 가장 많이 받는 질문 중 하나이다. 보통 비전공자 출신이 PM으로 취업하고자 하거나, 비개발자 직군이 PM으로의 직무전환을 할 때 이와 같은 벽에 부딪힌다. 이같은 질문은 PM은 개발자와의 커뮤니케이션이 메인이기 때문에 PM도 개발자 출신이거나 개발자에 준하는 업무 지식을 가지고 있어야 한다는 오해하기 때문에 발생한다.


PM이 개발 지식을 가지고 있으면 당연히 매우 좋다. 담당 제품에 어떤 개발 이슈들이 있는지 속속들이 파악할 수 있고, 개발자 입장에서도 비개발자와 대화할 때처럼 PM을 위한 통역 과정을 거치지 않아도 되기 때문이다. 새로운 기능을 만들고자 할 때에도, 어떠한 개발적인 접근들을 선택 가능한지와 불가능한지 등을 직감적으로 파악할 수 있기 때문에 허황된 이야기를 할 가능성이 현저히 낮아진다. 여러모로 개발 지식이 없는 것보다는 있는 쪽이 훨씬 더 유리하기는 하다.


아니, 앞에서는 불필요하다고 해두고서 개발 역량이 얼마나 중요한지를 이야기하고 있다니?




결론을 이야기하기 전에 다른 사례로 들어가보자.


PM이 개발 역량이 필요한지에 대한 질문만큼이나 자주 받는 질문이 바로, PM이 데이터 분석 역량을 필수적으로 갖추어야 하는가?이다.


큰 틀에서 데이터 분석 역량의 요구사항도 개발 지식과 같다. PM이 데이터 분석 역량을 보유하고 있다면 매우 유리한 것은 변함이 없다. PM은 담당 제품에서 발생하는 다양한 이벤트나 지표들을 추적해서 관리해야 한다. 많은 새로운 요구사항들이 데이터에 기초해서 나오기 때문에, 필요한 경우 직접 제품의 쿼리를 때려보며 제품 인사이트를 발견할 수 있다면 매우 좋을 것이다. 새로운 기능을 출시했을 때도 이것이 어떻게 사용되고 있는지, 나의 실험이 어떻게 진행되고 있는지, 실험의 결과를 어떻게 해석해야 하는지 등등 데이터 분석 역량이 빠지면 섭한 경우가 많다.



빠르게 다음 질문.


PM이 UX 디자인 역량을 필수적으로 갖추어야 하는가?


UX(User Experience) 디자인 역량 역시 개발이나 데이터 분석 역량과 같다. 사용자를 위한 제품을 만드는 이상 UX 디자인 역량 역시 빠지면 섭하다. 제품을 어떻게 구현할 것인가에 대해서는 개발자와 끊임없이 이야기해야 하지만, 사용자에게 어떤 제품을 제공해야 하느냐에 대해서는 Product Designer와 UX 끊임 없는 커뮤니케이션이 필요하다. PM이 개발 지식이 뛰어나서 천재적인 프로그래밍 역량을 발휘했다 하더라도, 까리한 데이터 분석을 통해 아무도 모르던 제품의 문제점을 발견했다 하더라도, 그것이 사용자 입장에서의 니즈와 맞지 않다면 안 하느니만 못한 경우가 많다. 때문에 PM은 UX에 대한 이해도와 경험, 역량을 가지고 있다는 것은 PM으로써 매우 큰 강점이 있다는 것과 같다.



조금 더 확장시켜보자.


마케팅 역량은 어떠한가? 제품을 만들어서 어떻게 전달할지를 모르는 것보다는 아는 것이 훨씬 도움이 된다.

전략 수립 역량은 어떠한가? 제품 로드맵을 세울 때 어느 방향으로 가야 할지는 알아야 한다. 물론 필요하다.

회계 역량은 어떠한가? 제품의 비용 구조를 모르는 PM이 어떻게 장기적인 비전을 세운다는 말인가? 당연히 필요하다.


하다못해 세일즈 역량은? 고객이 어떻게 우리 제품을 구매할 것인지를 파악하고 실현시키는 것은 매우 중요하다. 이것도 필요하다.

법무, 개인정보와 같은 컴플라이언스 역량? 제품을 아무리 잘 만들고 잘 팔아도 이것이 법적 이슈가 생기면 출시조차 할 수 없다. 이것 역시 중요하다.



여기까지 이야기하면 대부분 독자들이 눈치를 챘을 것이다. PM의 역량에 도움이 되지 않는 경험이나 분야 따위는 없다.





3. PM의 역량은 다항식이다

지금까지 이야기한 것을 보면 PM 역량이 중요하지 않은 것은 없어 보인다. 이것을 어떻게 해석해야 할까.


PM의 역량은 다항식과 같다.

식으로 표현하자면 다음과 같다.

해당 제품에서의 PM의 역량 = aX+ bY + cZ …


변수(X, Y, Z …)는 특정 필드의 역량을 의미한다.. 예컨대 개발, 데이터 분석, UX와 같은 분야들을 의미한다.


계수(a, b, c …)는 그 역량이 얼마나 효율적으로 활용되는지를 의미한다. 예를 들어 개발, 데이터 분석, UX와 같은 제품 역량은 다른 역량들보다는 대개 그 활용도가 더 높은 경향이 있다. 계수는 PM이 어떤 제품을 다루느냐에 따라 달라질 수 있다. 예컨대 리걸테크 제품을 만드는 PM이라면 법무 역량의 계수가 높을 것이고, 기술 기반 플랫폼을 만드는 PM이라면 개발 지식의 계수가 다른 역량보다 훨씬 높을 것이다..


따라서 PM들이 후배들에게 ‘OOO 경험이 PM 업무에 도움이 될까요?’와 같은 질문에 대해서 ‘도움이 안된다’고 성큼 답변하기 어려운 이유도 이와 같다. 어느 정도 업무 경력이 있는 PM이라면 그 OOO 경험이 어떤 식으로든 본인 업무에 도움이 되었던 경험이 한 번이라도 있을 것이기 때문이다. 저 ‘OOO 경험이 도움이 될까요?’의 OOO을 데이터 분석, 개발, UX, 마케팅, 법무 등등 그 어떤 요소를 집어 넣어도 마찬가지다.


PM의 역량이 다항식과 같다는 사실을 이해해보면 앞 꼭지에서 ‘PM에게는 모든 경험이 다 도움이 된다‘라는 필자의 답변이 어느 정도 이해가 될 것이다. 이것은 Generalist의 기본 속성이기 때문이고, PM은 generalist에 해당하기 때문이기도 하다.




모든 역량이 중요하다고 해서 모든 역량을 전문가 수준으로 개발할 필요는 없다. 애초에 그 정도로 역량을 끌어올리는 것은 가능하지도 않을 뿐더러 비효율적이다.


PM이 개발 지식을 가지고 있는 것은 좋지만, 개발자만큼의 지식을 요구하는 것은 아니다. 적어도 담당 제품이 개발적으로 어떤 구조를 가지고 있으며, 어떤 개발적인 이슈가 있는지에 대해 개발자와의 기본적인 커뮤니케이션이 가능한 수준 정도면 된다. 데이터 분석이나 UX도 마찬가지다. PM은 스스로 무언가를 만들지 않는다. 대신, PM을 도와주는 전문가인 개발자, 데이터 분석가, 제품 디자이너와 같이 일한다. PM이 특정 분야의 전문성을 그들만큼이나 가져가는 것은 매우 어려울 뿐더러, 이렇게 되면 그 전문가들의 전문성을 방해하는 꼴이 된다. 간혹 PM이 그 분야에 대해 전문가보다 더 많이 아는 경우도 있기는 하지만(대개 시니어PM과 주니어 메이커 조합), 이 경우에도 PM은 그 전문가를 대체하는 쪽으로 역량을 발휘하지는 않는다.


요컨대 PM은 각 분야의 전문가인 메이커들과 함께 일하기 때문에, 각각의 역량을 전문가 수준만큼 끌어올릴 필요가 없다.(다시 말하지만 가능하지도 않다.) 대신 그 전문가들과의 기본적인 대화가 되는 수준의 역량 정도까지만 개발해도 충분하다.







4. 그럼에도 불구하고 중요한 것들: PM의 핵심 역량

위 꼭지의 [PM 역량 = 다항식]의 개념을 제대로 이해했다면 PM이 역량이 어떻게 구성되는지를 알 수 있을 것이다. 한 마디로 정리하자면 ‘모든 것들이 다 도움이 된다’라는 것이다. 좋은 소식은 당신이 하는 모든 경험이 PM의 역량 향상에 도움이 된다는 것이고, 나쁜 소식은 그래서 어떤 것을 집중적으로 개발해야 하는데?에 대한 답변이 되지는 않는다는 것이겠다.


모든 경험이 다 도움이 되는 것은 맞다. 그럼에도 불구하고 PM에게 가장 큰 도움이 되는 ‘핵심 역량(core competency)‘이라는 것도 존재한다. 이 핵심 역량은 PM이 어떤 필드에서 근무하는지와 관계 없이, PM 직무의 본질적인 역량에 가깝다. 다항식의 개념으로 돌아가자면, 다항식의 각 계수/변수와 관계 없이 PM의 전체 역량 자체를 끌어올리는 것과 같다. 그런 의미에서는 이러한 핵심 역량은 그 다른 어떤 요소들보다도 훨씬 더 중요하다.


해당 제품에서의 PM의 역량 = multiple(aX+ bY + cZ …)


다항식으로 표현하면 위와 같고, 이러한 핵심 역량은 multiple로 표현된다. 각 분야의 역량인 X, Y, Z .. 를 개발하는 것도 중요하지만, 모든 분야의 역량 자체를 향상시켜주는 핵심 역량과 같다. 이렇게 따지면 PM 입장에서는 X, Y, Z와 같은 개별 역량 이상으로 multiple에 속하는 핵심 역량을 개발하는 것이 중요하다고 말할 수 있겠다.



그렇다면 그 multiple에 해당하는 PM의 핵심 역량이란 도대체 무엇인가. 필자는 다음 3개가 중요하다고 본다.



1. 커뮤니케이션 역량

PM의 본질은 여러 직군들을 연결하는 커뮤니케이터다. PM 혼자서는 그 어떠한 가치도 창출할 수 없지만, 여러 직군들을 모였을 때 개별의 합보다 훨씬 더 큰 가치를 내도록 만들어주는 역할을 한다. 때문에 PM에게는 거짓말 한 톨 없이 그야말로 ‘모든’ 업무에 커뮤니케이션 역량이 필요하다. 문서를 만들 때도, 회의를 할 때도, 개발자와 대화를 할 때도, 슬랙 메시지를 보낼 때도, 이메일을 보낼 때도. 모든 것이 커뮤니케이션이다


본인의 역량이 아무리 뛰어나도 커뮤니케이션 역량이 떨어진다면 굉장히 나쁜 평판을 받게 된다. 아무리 개발 지식이 뛰어난 PM이라도 이것을 제대로 커뮤니케이션하지 못한다면 오히려 개발자들의 발목만 잡게 될 것이다. 이런 관점에서, PM 다항식에서 multiple이 꼭 1보다 큰 수라고 생각해서는 안 된다. PM의 커뮤니케이션 역량이 나쁘다면 본인의 전체 역량 자체를 깎아먹게 된다. 예컨대 커뮤니케이션에 약해서 다항식의 multiple이 0.5 정도의 느낌이라면, 각 분야의 역량이 아무리 뛰어나더라도 전체 역량 자체를 절반으로 깎아버린다.



2. 엄청난 지적 호기심과 빠른 러닝 커브

PM의 업무는 루틴하지 않다. 매일매일이 새로운 업무이고 새로운 환경이다. 필자도 PM 업무 중 가장 매력적인 요소가 바로 이렇게 매일이 새로운 환경이라 생각한다.(그러한 점에서 루틴하고 안정적인 업무를 선호하는 사람들은 평균적으로 PM 업무에 적합하지 않다)


매일이 새롭다는 것은 그 새로운 환경에 빠르게 적응해야 한다는 것이다. 새로운 이슈를 만났을 때 그 이슈가 어떤 이슈인지 빠르게 캐치해야 한다. 본인이 처음 보는 부류의 분야 혹은 이슈라면, 그것에 대해 공부하는 것을 재미있어해야 한다. 지적 호기심을 가지고 새로운 이슈에 필요한 지식을 습득하고, 본인의 것으로 만들어 이를 팀 전체가 알아보기 쉽도록 정리해야 한다. 즉 매일 새롭게 공부해야 하는 것이 PM 직무인만큼, 이러한 지적 호기심을 가지고 있는 사람이라면 매일이 즐겁고 그렇지 않다면 매일이 스트레스일 것이다. 그런 관점에서 빠른 러닝 커브도 가지고 있는 사람이면 큰 도움이 된다. 새로운 지식을 본인의 것으로 체화시키는 것이 중요하기 때문이다. 사실 지적 호기심을 가지고 있는 사람들은 대개 러닝 커브가 빠른 편이지만.


소위 ‘잘하는 PM’들이 매사 호기심이 넘치고, 새로운 이슈를 마주했을 때 스트레스를 받기보다는 눈이 초롱초롱해지는 연유는 이와 같다. 그들은 새로운 영역을 배우는 것을 두려워하지 않고 즐긴다. 오히려 새로운 것이 없이 매번 똑같은 업무에 갇여있을 때 스트레스를 받고 이직을 고민하게 되는 이유도 이와 같다.



3. 나무보다는 숲을 보는 능력

PM은 여러 직무와 협업하고, 여러 이슈들을 관리하다. 자연스럽게 특정 분야에 대한 전문성을 가지고 바라보는 것이 아닌 버드 뷰(bird-view: 새가 하늘에서 바라보듯 전체를 조망)에 입각한 관점이 훨씬 더 중요하다. PM은 부분에 대한 특정 뷰만 가지기 보다는 거시적인 관점에서 전체의 이슈들이 어떻게 조합되는지를 중요하게 생각해야 한다. 개발자는 개발 관점에서, 디자이너는 사용자 관점에서 이슈를 해석한다. 개발 관점에서만 제품이 개발되면 제품의 속도는 더 빨라질지언정 사용자와 멀어진다. 사용자 관점만 우선시하다보면 제품 개발의 난이도가 올라 실현 불가능한 제품이 나타난다. 즉 각 직무의 전문가들이 제시하는 견해들을 제품 전체의 관점으로 승화시키는 것이 PM의 핵심 역량 중 하나인 것이다.






경험이 많은 독자라면 여기까지 읽고 캐치할 수 있는 부분이 있다. 이것은 Product Manager 고유의 핵심 역량이라기보다는 Generalist의 핵심 역량이다. 꼭 IT 회사의 Product Manager가 아니라도, 일반 회사의 manager 직급이라면 동일하게 요구되는 부분이고, 그만큼 generalist들에게 중요하게 요구되는 역량이다.


’PM이 개발 역량을 공부해야 할까요?‘에 대한 질문은 PM이 generalist라는 점을 간과하는 질문이다. PM은 IT 회사의 IT 제품을 담당하는 generalist이기 때문에 개발 역량을 공부해야 하는 것은 어느 정도 필요하지만, 핵심 역량들이 부족하다면 그것부터 먼저 개발하고 경험을 보유해나가는 것이 훨씬 더 중요하다. 그렇게 되면 나머지 요소의 역량들은 원하지 않더라도 자연스럽게 그 직무의 전문가들과 일하며 습득하게 된다.


예를 들어보자. 핵심 역량을 충분히 보유한 PM이라면 개발자와 대화하면서 본인이 개발자와 대화하기에 충분한 개발 지식이 부족하다는 점을 ‘깨닫게’ 된다. 이들은 커뮤니케이션하기에 부족한 개발 지식을 메꾸기 위해 개발 서적을 펴는 것보다, 그 개발자와 대화하며 “아무래도 제가 당신과 대화하기에 개발 지식이 불충분한 것 같네요. 언제 한 번 시간 되실 때,제가 참고하면 좋을 우리 제품의 구조와 현재 어떤 개발 이슈들이 있는지들을 짧게 소개해주실 수 있을까요?”와 같은 형태로 그 지식을 채워나간다.




Product Manager는 분명 매력적인 직무이고, 전문성이 요구되는 것은 맞지만 그 전문성이 개발, 디자인, 데이터 분석과 같은 영역은 아니다. 오히려 PM은 PM만의 핵심 역량이 있고 그것이 훨씬 더 중요하다. 잊지 마라. PM은 Generalist다.





keyword
매거진의 이전글바텀 업(bottom-up) 의사결정의 환상 부수기