Product Manager 직무에 대한 고찰
Backlog Manager 와의 차별점
PM (Product Manager) 직무는 참 흥미롭다. IT 직군으로 한정짓더라도, 각 서비스마다 PM 직무를 설명하는 Description은 천차만별이다. 또 어떤 회사는 PM 이 아닌 PO (Product Owner) 직무를 두기도 한다. (대표적으로 토스가 그러하다.) 하여 'PO와 PM 은 대체 어떤 차이가 있는 것인가' 에 대한 담론은 또다른 흥미거리이다. 관련해서는 다음 번에 다뤄보기로 하고, 오늘은 PM 직무에 대해 이야기 해보려 한다. 딜라이트룸에 조인한지 만 3주가 지났다. 'Product 자체의 우수함'이 매출과 성장의 동력인 조직에서 정의하는 PM 은 그간 내가 알고 지내온 PM 의 정의와 사뭇 달랐다. 아니 많이 달랐다. 지금까지 내가 바라보았던 PM 직무에 대한 관점은 어찌보면 다른 관점이었을 수도 있고, 틀린 관점이었을 수도 있겠다. 비즈니스보다도, 제품(Product) 자체가 우선인 조직에서의 PM 직무는 어떻게 남다른지 알아보자.
업계의 많은 이들은 물론이거니와, 나 조차도 PM 직무에 필수적으로 요구되는 역량이 무엇이냐는 질문을 받으면, 한치의 망설임도 없이 '커뮤니케이션 역량'을 꼽곤 한다. 틀린 말도 아닌 것이, 사업 본부와 제품 본부 사이에서 의견을 조율하고, 제품 본부 내에서 여러 개발자들과 디자이너들을 이끌고 단일의 목표를 성취해야 되기 때문에 커뮤니케이션 역량이 없이는 PM 직무를 수행할 수 없는 것은 사실이다. 다만 그것이 충분 조건이냐 하면 그것은 틀린 말이었다. 지금까지 나를 비롯하여 많은 이들은 Backlog Manager 와 Product Manager 를 혼동하고 있었던 것이다.
제품 본부는 으레 스프린트(Sprint)라는 주기(Cycle)에 기반하여 협업 프로세스를 돌린다. 일종의 컨베이어 벨트를 돌리는 셈인데, 흔히 파이프라인이라고 부르기도 한다. 이 때 파이프라인에 어떤 개발 작업을 올릴 것인가를 고민하고 결정하는 것이 PM 의 역할 중 하나이고, 그 후보들을 Backlog 라고 일컫는다. ('뒤에 쌓여있는 일더미' 라는 의미) Backlog Manager 로서의 PM 은, Backlog들을 주기적으로 검열하여 당장 필요없는 것들을 삭제하고, 각각의 예상되는 임팩트와 개발 공수를 산정하여 어느 스프린트에 넣으면 좋을지 결정한다. 그리고는 담당 작업자(개발자 또는 디자이너)들과 커뮤니케이션하며 목표로 하는 타임라인에 맞춰 딜리버한다. Backlog Manager 가 우선 순위 산정을 얼마나 정확하게 하였느냐, 해당 과제에 대해 작업자들과 얼마나 잘 싱크(Sync)하였나, 진행 과정에서 핑퐁을 얼마나 지체없이 정확히 하였느냐에 따라 제품 팀의 퍼포먼스가 크게 달라지기 때문에 어찌보면 커뮤니케이션 역량이 전부인 것처럼 느끼는 것도 무리는 아닐 수 있겠다. 허나 지금까지 이야기한 것들은 PM 의 여러 역할 중 하나인 Backlog Managing에 국한된 이야기이다. Product Manager 는 Backlog Manager 를 넘어서는(beyond) 역량을 수행해야 하는 직무라는 사실을 뒤늦게 깨달았다.
자, 간략하게 Product Manager 와 Backlog Manager의 차이를 정리해보고, 왜 많은 조직들이 Product Manager 직무를 채용하면서 Backlog manager의 역할을 요구하는지도 함께 고찰해보자.
Backlog Manager
1. 백로그의 출처 : 이미 수많은 백로그들이 수동적으로 주어지는 형태. 타 부서에 의존적으로 행동
사업부서로부터 쏟아지는 요청 - "다음 달까지 출시되어야 해요." "이거 좀 우선적으로 처리해주세요." 나름 비판적 수용을 위한 '우선 순위 판별' 프로세스가 있기도 하지만 보통은 가장 강하게 푸쉬받는 과제를 먼저 진행하기 일쑤임. 사내 SI (System Integration) 업체로 전락할 위험에 처하기도 함.
경영진으로부터 하달되는 산지직송 요청 - "최우선 순위로 놓고 진행할 것". IT 대기업에서나 있을 법한 상황인 것 같지만 놀랍게도 스타트업 중에도 제법 빈번함.
항상 Backlog Manager 의 눈앞에는 일들이 산적해있기에 주어지는 것들만 문제없이 쳐내도 대단한 것이 된다. 그리하여 아래와 같은 역량이 요구된다.
2. 핵심 역량 : 쏟아지는 일들을 우선순위를 정하여 기한 내에 완수하는 능력
빠른 머리 - 주어지는 일들을 상위 레벨에서 어느 맥락에 놓여있는지 파악하고(Why), 굵직한 태스크 단위로 쪼개어 플래닝할 수 있는 빠른 머리
빠른 손과 발 - 효과적인 커뮤니케이션을 위한 시청각 자료 제작하고, 지난 작업들의 용이한 유지보수를 위한 문서를 진행하며, 세련된 커뮤니케이션을 주저없이 할 수 있는 빠른 손과 발
위 역량을 갖춘 사람 하나 찾기도 어려운 것이 현실이다. 위와 같은 역량을 바탕으로 쏟아지는 일들을 수행하다 보면, 업무를 수행함에 있어 주된 사고의 출발점은 아래와 같아진다.
3. 사고의 출발점 : 해야 할일(What과 How)에 대한 사고 위주
솔루션에 대한 집착 : 주어진 문제를 '어떻게' 해결할까. '어떤' 일을 해야 할까 등 솔루션(해야 할일)에 대한 접근이 일반적
효율적, 창의적 접근 - 남들보다 뛰어난 역량이라 함은 대개 문제 해결에 있어 얼마나 효율적으로 일을 처리했느냐, 얼마나 Think Out of Box 하여 창의적으로 해결하였느냐 를 기준으로 판단함
위와 같은 특질들은 보통의 조직에서 Product Manager 의 특질로 대체되는 내용들이기도 하다. 하지만 정확히는 Backlog Manager 의 특질이다. 이를 넘어서는 Product Manager 들의 특질은 아래와 같다.
Product Manager
1. 백로그의 출처 : 벌어지는 현상들을 능동적으로 살피고, 문제 여부를 판단하고 나아가 문제의 원인이 무엇인지 주체적으로 살핌
현상에 대한 모니터링 : 인입되는 VoC (Voice of Customer), 숫자로 집계되는 제품의 데이터 등을 통해 제품의 현재 상태를 살핌
문제 파악 : 모니터링을 통해 파악된 이상 현상이 문제인지 아닌지 판별함
원인 파악 : 벌어진 현상과 문제의 원인을 구별하여, 보다 깊게 '왜(Why)' 이 현상이 벌어졌는지 파헤침
이같은 경우에도 PM 들의 눈앞에는 항상 할일이 산적하기 마련이다. 다만 그것이 타 부서로부터 주어진게 아니라 PM 스스로 발굴해야 한다는 점과, 문제 원인 진단이 제대로 되었느냐에 따라 해결책과 그 임팩트가 크게 달라진다는 점에서 PM 에게 요구되는 역량이 달라진다.
2. 핵심 역량 : 현상 속에서 문제(=기회) 본질을 포착하는 통찰력과, 문제를 정의하는 능력
본질을 보는 통찰력 : 남들은 그냥 지나치는 것을 캐치하는 능력. 문제라고 생각지도 못하는 부분을 발견하는 능력.
적당히 그리고 깊게 디깅(Digging) 하는 사고 능력 : 이것이 왜 문제일까, 무엇이 원인인 걸까. 애매하지 않고 명료하게 원인을 규명하는 능력.
'토끼와 거북이' 동화에서 토끼는 졌다. 진 이유가 무엇일까? '잤기 때문에' 라는 사고는 현상을 있는 그대로 받아들인 사고이다. 왜 잤을까? 한번 더 파보면, '자만했기 때문에'라는 답이 나온다. '잤기 때문에' 에서 사고가 그치면 '해야 할일'은 '토끼에게 커피 사주기', '토끼에게 전날 일찍 자라고 해주기' 등이 되어버린다. 그런다고 토끼가 시합 때 안 잘까? 설령 안 자더라도 누워서 쉬다가 또 이기지 못할 것이다. '자만했기 때문에' 까지 사고가 이어지면, '토끼에게 거북이 실력이 매우 대단하다고 일러주기', '토끼에게 겸손의 덕목을 일러주기' 등이 '해야 할일'로 이어진다. 자만하지 않게끔 조치가 된다면, 전날 밤을 새고 왔다 하더라도 중간에 쉴 일은 절대 없을 것이다. 그런데 여기서 한번 더 디깅하여, 토끼가 왜 자만했을지 사고하면 '토끼 유년기 인성 교육 시스템이 불완전해서'까지 이어질 수도 있고, 이는 옳지 않은 문제 원인 진단이 되어버린다. 토끼 한 마리의 자만심을, 토끼 세계 전체의 교육 시스템 문제로 정의하게 되는 순간 불필요한 리소스 낭비로 이어진다. 그렇기 때문에 적당히 깊게 디깅하는 능력이 중요한 것이다.
3. 사고의 출발점 : 해야 할 일(What과 How) 보다는 왜(Why)에 대한 사고 위주
얼마나 문제에 대한 정의를 뾰족하게 하였는가 : 위에서 언급한 역량을 바탕으로, 벌어진 현상 속에서 문제의 본질을 충분히 명료하게 뽑아내었는지. 아직 애매한 부분이 있거나 지나치게 확대 해석하진 않았는지. 꼼꼼히 묻고 또 묻는 것이 일반적. 대체로 해결책은 위 '토끼와 거북이'의 사례처럼 문제에 대한 정의가 되면 자연스레 도출됨. 그렇게 때문에 해결책에 대한 논의 보다도 문제 정의에 대한 시간을 더 크게 투자함.
문제 본질의 임팩트가 얼마나 되는가 : 뾰족해진 문제들이 해결되었을 때의 잠재적 임팩트에 대한 계산. 해결책의 참신함 보다는 문제 본질의 잠재적 임팩트를 고려.
분명 PM 은 Backlog Manager 로서의 역할을 겸하기 때문에, Backlog Manager 로서의 특질인 - 주어지는 백로그들을 빠른 머리와 손과 발로 처리하고, 참신하고 효율적인 해결책을 마련하는 역량을 요구 받을 수 있다. 헌데 위에서 언급한 Product Manager 로서의 보다 본질적인 특질인 - 능동적으로 문제 현상으로부터 문제 원인을 찾아내어 정의하고, 가장 임팩트 있을 문제들을 선별하는 역량을 요구하는 기업은 많지 않다.
왜 그럴까 ? 이 또한 하나의 '현상'이라 치면, 왜? 라는 질문을 통해 문제 본질을 간단히 살펴볼 수 있겠다.
1. [돈의 출처] 제품이 사업의 수단일 뿐, 사업의 본질이 아님
많은 경우에 제품은 돈을 버는 비즈니스의 수단일 뿐, 제품 자체가 황금 알을 낳는 거위가 아니다. 여행사 앱, 커머스 앱, 숙박 앱 - 대부분의 돈은 사업 제휴와 물건 판매 등에서 발생한다. 이미 돈을 버는 매출 모델이 존재하고, 그 후에 여러 채널 중 하나로서 앱을 만든 것이다. 순수히 제품의 퀄리티 만으로 돈을 버는 앱은 많지 않다. 꼽아봐도 유튜브, 인스타그램 정도이다. 한국에서는 당근마켓, 콴다, 뱅크샐러드 등이 제품의 퀄리티를 선도하고 있지만 매출 모델의 안착은 아직인 상황이다. IT 제품이 일상에서 필수재로 자리잡아 가고 있는 요즘의 트렌드를 보면 향후 5년 안에는 제품이 사업의 본질로 자리할 수 있지 않을까 기대해본다만, 지금 당장은 아무래도 드물 수밖에 없다.
2. [제품은 후순위] 제품이 넓고 복잡해짐
수단으로서 취급되다보니, 각종 사업 부서의 요청을 무분별하게 받아들이게 되고, 그 결과 제품의 복잡도가 기하급수적으로 증대된다. 제품의 새로운 기능은 고사하고, 있는 기능들을 덜어내야 할 판이다. 순수 채팅 기능만을 고수하던 카카오톡도 어느새 광고가 붙고, 컨텐트 피드가 붙고, 스토어가 붙었다. 이같이 복잡한 제품 상에서 벌어지는 수많은 현상 속에서 문제 여부를 판단하는 거 자체가 무리이다. 살펴봐야 할 제품의 지표가 너무 다양하고, 인입되는 VoC도 하루 수천건이다. 대부분 IT 제품본부 소속 인원들의 근속년수를 고려하면 그 복잡도를 모두 이해하고 있는 사람이 두 명 이상 존재하기 힘들고, 제품의 넓이 대비 상대적으로 부족한 수의 PM을 고용하는 것이 일반적이다. 제품의 범주를 쪼개어 여러 PM 이 함께 관리하는 순간, 어디선가 발생한 문제에 대한 원인 진단이 개인별로 정확히 될리도 만무하다.
3. [문화] 기업식 마인드
'오늘 하루동안 다들 뭐했니?'라고 상사가 물었을 때, '무엇이 진짜 문제인지 고민만 했어요.' 라고 대답할 수 있는 조직이 얼마나 될까? 세상의 유명한 PM 들은 문제 정의에 75% 시간을 쓰고, 저절로 도출된 해결책을 수행하는 데에 나머지 25%를 쓴다고 한다. 그 고수들이 몸담을 수 있는 조직 자체가 많지 않다. 나무 10,000 그루를 베는 미션을 무딘 도끼와 함께 부여받았다고 해보자. 대부분의 조직은 하루에 몇 그루씩 벨지 산정하여 바로 액션으로 옮긴다. 훌륭한 PM 들은 도끼 날을 날카롭게 가는 데에 충분한 시간을 쓰려 할 것이다. 이 때 그들이 이틀 넘게 도끼 날만 갈고 있는 것을 가만히 냅둘 조직이 없는게 문제인 것이다.
이외에도 여러 현실적인 이유들로 인해 사실상 문제의 본질을 고민할 수 있는 여건을 갖추는 것은 어렵다. 당장의 매출이 급한 상황에서는 최소한의 합리적인 사고로 의사 결정을 짓고 액션으로 옮기는 것이 효율적이니까. 각 조직은 조직의 상황에 맞게 직무 구성을 짜는 것이고, 그저 Product Manager 의 본질적인 역할을 수행하기에 적합한 상황에 놓인 조직이 많지 않을 뿐이다.
딜라이트룸은 '알라미' 라는 미션형 알람 앱으로 매일 200만 명 이상의 유저들의 잠을 확실히 깨워주고, 아침 습관을 만들게까지 도와준다. 별다른 비즈니스 없이, 오로지 우수한 제품성 하나로 충성 유저들을 확보했고, 그들에게 광고를 노출하거나 구독료를 받으면서 빼어난 매출액을 벌어들이고 있다. 제품 자체가 사업의 본질이다보니 여느 조직과 다르게, 위에서 언급한 Product Manager 로서의 특질을 강하게 요구한다. 해야 할일을 논하기 전에, 문제 현상과 원인을 구분하는 시간을 더 갖고 Why 에 대해 고민하는 시간을 더 갖는다. 데이터 자체에 집착하기 보다는 이를 현상으로 삼아 그 이면에 자리하는 문제 본질을 정교화 하는 데에 힘쓰고, 각각이 끼칠 임팩트에 대해 논한다.
이는 그간 Backlog Manager 로서 충실히 PM 직무를 수행해온 나로 하여금 큰 울림을 주었다. 나 자신의 강한 무기로서 갈고 닦아온 커뮤니케이션 역량만으로는 뛰어난 PM을 위한 충분 조건이 되지 못한다는 것, Good to Great 이 되기 위해서는 현상과 문제를 분별할 수 있는 식견과, 본질을 꿰뚫어 볼 수 있는 통찰력을 갖춰야 한다는 것, 갈 길이 멀었다는 것.
그저 Business-Oriented 가 아닌 Product-Oriented Product 의 PM 을 해보고 싶었을 뿐인데, 완전히 다른 정의의 PM 을 경험하고 있다. 제품의 본질을 고민할 수 있는 환경이 굉장히 드문 기회라는 것을 알기에, 착실히 식견을 쌓아 올려 근시일 내에 큰 임팩트를 낼 수 있는 문제를 포착해내고 싶다. 충분한 문제 정의 끝에 자연스레 도출된 실험을 설계 및 진행하고 예상했던 결과물을 뽑아내면 얼마나 뿌듯할까. 그 일련의 경험을 하루 빨리 글로 담아낼 수 있는 날이 오길 바라며, 문제 본질을 보지 못하는 PM 의 뼈를 때리는 글귀로 이번 글을 마무리 한다.
서승환씨는 그렇게 생각해도 되지만, PM 서승환씨는 그러면 안되어요
