프로덕트 매니저는 어떤 일을 하나?

출처: https://www.mindtheproduct.com/2011/10/what-exactly-is-a-product-manager/

언젠가 어느 정도 내 직무에 대해 정의가 가능해지면 꼭 이 글을 쓰고 싶다는 생각을 했었는데 좋은 기회가 되어 글을 쓴다. 사실 난 법학을 전공했고 전공 4년 내내 모두가 그렇듯 내 전공에 대한 회의감을 느끼기 바빴다. 나는 지독하게도 즐겁고 재밌는 것을 추구했고 '해야만 하는 일'을 '안 해도 되게' 합리화하고 핑계 대는 것에 능했다. 물론 이러한 내 능력(?)은 해야 하는 일인데 안 하고 싶어 죽겠는 일 투성이인 군대에 가게 되면서 변화하기 시작했다. 물론 이 귀차니즘이 완벽하게 사라지진 않았다. 애초에 마케팅과 경영 전반에 대한 관심이 많았던 나는 관련 분야의 업무를 수행할 수 있는 회사를 다니며 MBA를 병행했다. 그리고 이곳에서의 인연으로 결혼까지 하게 되면서 내 생각의 깊이가 크게 변화하기 시작했다.

 

내 원래의 성격이 하기 싫은 일을 억지로 하면 꼴등도 할 수 있는 성격이기에 즐겁게 할 수 있는 일을 찾아 헤매기 시작했고 어쩌다 보니 IT업계의 일들도 배우면서 내 본연의 업무도 할 수 있는 기회가 되는 곳에 취업하게 되었다. 그리고 창피하게도 무슨 일을 하게 될 지도 모르는 상태에서 무작정 배우면서 내 적성을 찾아가고자 했고 지금 일부의 관계자들의 말처럼 '기획자'라는 단어로 대변되는 일을 할 수 있다는 막연한 상상만 했다. 더 적절하게 표현하자면 'IT제품, 특히 온라인 서비스에 해당하는 것들을 제품으로 출시하기 위해 시장조사부터 전략 수립 및 제품 개발과 정책 수립까지 포함하는 일'을 배우고 할 수 있을 것이라고 기대했다. 물론 하나씩 배워야 하다 보니 콘텐츠 관리, 마케팅 등의 지금 당장 내가 할 수 있는 일들부터 하기 시작했고 내가 할 것이라고 기대되는 일들은 조금씩 어깨너머로 배워가며 접근하기 시작했다.

 

지금 그 당시를 회상해보니 아무래도 지방에서 근무하다보니 경쟁도 지역 경쟁이 더 빈도가 높았고 트렌드도 조금 뒤처지곤 하지 않았나 싶다. 2014년이면 모바일 서비스들이 우후죽순 생겨나고 망하기도 했는데 우리 회사에는 앱 개발자가 0명이거나 병행하는 개발자 한 명이 퇴사를 반복하는 일이 비일비재했다. 우리도 우리 서비스를 만들어 SI성 일들에서 벗어나고자 했던 대표님의 의지에 따라 모바일 개발자를 포함해 새로운 서비스에 능한 인재를 채용하고자 했다. 물론 이마저도 녹록지 않다 보니 외주를 주게 되었고 그 모바일 서비스의 기획자 및 Project Manager를 내가 맡게 되었다. 아무래도 이렇다 보니 서비스 설계부터 개발 전반은 외주 업체에서 관리했고 나는 시장조사를 비롯한 서비스 기획에 집중해왔다. 이 업체와 일하면서 나는 그들의 일하는 방식과 경험을 최대한 흡수하려고 노력했다. 아무래도 외주업체에서 문제를 제기하면 내가 정책 정의를 해야 하는 경우들이 많았는데 어떤 한 문제에 대해 고민이 많자 같이 일하던 시니어 개발자가 '넌 기본이 없어서 그래' 라며 혀를 내두르는 덕분에 서비스 기획자보다는 이 글에서 언급하고자 하는 프로덕트 매니저로 발전하게 되었다. 

 

이때부터 나는 시장에서 공급이 적은 iOS 앱 개발을 해보고자 Objective-C를 공부하기 시작했다. 사실 내가 아이폰을 쓰고 있었고 모바일 서비스에 관심이 더 높았기에 가능했던 것 같다. Mac OS를 사용해야만 했던 초기 투입 비용을 낮춰보려고 해킨토시도 설치해보고 돈을 모아 저렴한 맥북 에어로 공부를 해가며 사이드 프로젝트로 앱 런칭을 세 번 정도 해보니 내가 기획하고 설계하고 개발하며 어떤 문제가 생길 수 있는지 그리고 정책 정의를 어떤 방식으로 해야 하는지 가늠할 수 있게 되었다. 물론 사이드 프로젝트를 위해 디자인과 설계도 혼자 다 해야만 했으니 Product를 만들기 위한 전주기를 세 번이나 체험한 것이다. 물론 지금도 앱 개발은 놓지 않고 있고 최근에는 RxSwift를 활용하여 부분적으로 MVVM 패턴을 공부하고 있다. 

---

아직 누군가에게 '나 이거 만든 사람이야' 라고 소개할 만큼 대단한 서비스가 없다 보니 제품을 개발하면서도 조금씩 회의감이 들기 시작했다. 물론 이런 고민이 생길 때마다 회사는 내게 '직함 또는 직위', '팀빌딩' 등의 회사가 지금 당장 단기적으로 처방할 수 있는 당근을 제시했다. 물론 그때마다 난 거기서 내가 새로운 경험을 할 수 있는 긍정적인 측면을 보려고 노력했다. 자연스럽게 팀장이 되자 난 내 뜻에 맞고 성향도 비슷한 사람을 최소로 선정하여 R&D를 시작할 수 있었다. 물론 팀이 만들어지기까지 시장조사부터 사업 기획까지 혼자 다 해내야 했고 정부 과제를 타오고 나서야 가능했다. 당연히 Cash Cow에 영향을 주지 않아야 눈치를 덜 볼 수 있기에 인건비도 많이 아껴내어 기업 부담금이 아깝지 않게 했다. 정작 제품은 내가 좋아하는 서비스도 아니었고 내가 공부한 모바일도 아닌 SW설루션이다. 물론 회사의 비즈니스 기반과 연계되어 잘 팔려나가는 제품이기에 처음 이 제품을 기획했던 2015년부터 지금까지 잘 유지되고 있다. 그리고 여지없이 내가 원래 하고 싶어 했던 일들에 대한 회의감과 잠시 뒤로 미뤄왔던 불만들이 폭증하기 시작했고 이직을 준비하며 나 자신에 대한 갈등이 시작되었다.

 

Product Manager(제품 관리자)라는 말을 처음 알게 된 것은 부끄럽게도 5개월도 채 안된 것 같다. 그 동안은 전략 기획자라고만 불려 왔다. 우연히 읽게 된 '인스파이어드'라는 책에서 처음 프로덕트 매니저를 접했을 때 그리고 책에서 언급되는 프로덕트 매니저의 설움과 불편한 진실들은 내 불만을 이 저자가 상담이라도 해주는 것처럼 깊은 감명을 받게 되었다. 사실상 제품에 대해서는 처음부터 끝까지 모두 관여해야 하는 내 상황이 나를 미니 CEO로 만들기 시작했고 우리 팀은 회사 안의 다른 회사처럼 여겨지기 시작했다. 비록 회사 안에 종속되어 움직이는 조직이지만 조직 장인 내 마음대로 회사의 구조와는 다른 Multi-Functional한 조직 구조를 만들었고 Agile을 도입한다거나 영어 호칭을 쓰고 수평적으로 만든다거나 했다. 물론 이건 나를 포함한 우리 조직의 이야기이고 나를 포함한 회사 전체는 여전히 Top-Down, Waterfall이다. 물론 조직의 모든 문화는 조직이 함께 결정하고 함께 조성한다는 것을 시작으로 모든 업무도 개인들이 즐겁게 기여할 수 있는 일들을 알아서 배정한다. 즉, 우리는 누군가에 의해 R&R을 정의하기보다는 스스로 Problem에 대해 자신이 할 수 있는 역할을 찾고 함께 Opportunity를 발굴하고 스스로 업무를 배정하는 독특한 문화(또는 업무 패턴)를 가지고 있다. 이를 시작으로 나는 개인들의 아주 사적인 문제들부터 업무에 대한 문제까지 모두 관리하고 정의하게 되는데 서비스 기획자로 이직을 준비할 때 가장 많이 듣던 '너무 General 하신 것 아니냐?'가 지금 내 직무에서는 '당연한 것'이었다. 

 

http://www.yes24.com/Product/goods/67512293

인스파이어드

지금 나는 매일 5시에 출근하여 커피 한잔과 함께 이전의 업무들을 살펴보고 있다. 6시가 되면 가까운 헬스장으로 가서 1시간 가량 운동하고 복귀하여 본격적으로 내 업무를 시작한다. 우리는 유연근무제를 도입 중이지만 9시에는 데일리 스크럼을 하는데 20분 정도면 마치지만 내 목표는 스크럼 전까지 하루 내 업무 일정을 마무리하는 것을 목표로 하고 있다. 즉 7시 30분부터 1시간 30분 동안 8시간짜리 업무를 모두 하는 것이다. 그리고 스크럼이 끝나면 혹시 모르는 상황들에 대비하며 각 섹터에서 일어나는 회의에 되도록 많이 참석한다. 때때로 마케팅을 위해 고객을 만나거나 인터뷰를 진행하기도 하며, UI/UX 디자인을 위한 Iteration에 참여하기도 한다. 그리고 개발자들과 정책 회의를 한다거나 코드 리뷰를 하기도 하는데 나는 개발자들에겐 CTO와도 같은 역할을 해야 하는 상황이라 새로운 이슈나 DevOps를 위한 이야기들을 나누기도 한다. 물론 앞서 언급했듯 Top-Down이기에 보고를 위한 시간들도 있다. 보통 이런 식이면 일주일이 금세 지나가는데 운이 좋게도 시간에 여유가 생기면 지금은 공석인 마케터를 대신해 브랜드 마케팅을 진행한다거나 기술 블로그에 글을 작성한다거나 하는 일들을 하고 있다. 되도록 벤치마킹을 하고 트렌드를 잡기 위해 Table Research를 많이 한다.

 

그리고 이렇게 마음을 다 잡고 업무를 하다보니 또 한 권의 책이 눈에 들어왔는데 실리콘밸리의 팀장들이라는 책이었다. 이 책에서는 프로덕트 매니저로서의 고민보다는 조직의 리더로서, HR을 해야 하는 관리자로서, 한 사람의 선배로서 겪어야만 했던 내적 갈등에 대한 해답이 제시되고 있다. 인스파이어드와 마찬가지로 난 이 책을 보며 위로를 받기도 했지만 반대로 이 책에서 가장 강조하는 Radical Candor(지독한 솔직함)은 비단 팀장들 뿐만 아니라 모두가 우리의 제품을 위해서는 필요하다고 여겨졌다. 그래서 우리는 스프린트 리뷰를 통해 진행하며 생겼던 모든 업무들에 대해 비판하는 자리를 만들고 있고 당연히 스프린트 회고도 만들어 서로에 대해 비판하고 솔직하게 자신들의 감정을 공유하고 있다. 물론 이 모든 것들의 기준은 이 사람들이 더 나은 사람들이 되는 것이고 더 멋진 동료가 되어 내가 속한 조직이 더 멋있어지길 바래서이다.

 

http://www.yes24.com/Product/Goods/74259979?Acode=101

실리콘밸리의 팀장들

---

사실 이곳 저곳의 Product Manager들이 하는 일들이 상당히 다양하다. 내가 만나본 Product Manager들의 업무를 살펴보면 (부득이하게 티가 너무 나는 듯해서 익명으로 표기한다.) 스타트업 A사의 Product Manager는 비즈니스에 조금 더 집중하고 있었으며 제품보다는 경영에 특화된 사람이었다. 또 IT 대기업 B사의 Product Manager는 사실상 Project Manager에 가깝기도 했다. SI업체에 계신 분들은 대부분 Project Manager이면서 사업 수완이 좋으신 분들이 많았다. 또 C사나 D사의 경우에는 Product Manager라기보다는 Prduct Owner라는 표현을 쓰기도 했다. 이 호칭에 대해 일부 헷갈려하는 사람들이 많던데 알고 보니 같은 업무이지만 Manager는 관리직의 냄새가 풍긴다고 하여 Owner라고 사용 중인 듯한 뉘앙스였다. 그리고 자세히 바라보면 이들은 서비스 기획이나 UI/UX 설계에 포커스가 맞추어진 느낌이었다. 이 글의 맨 처음을 장식한 그림처럼 디자인, 기술, 비즈니스의 교집합에만 해당하는 것도 아니다. 각자 자신의 흥미와 역량에 따라 어느 곳으로든지 조금씩 더 치우치는 경향을 보인다. 

 

사실 요즘의 조직들의 분위기나 지금의 내 생각 같아서는 저런 직함과 Role에 연연할 필요없다고 생각한다. 내가 하고자 하는 일과 나를 영원히 따라다닐 지금 내가 맡고 있는 제품에 Ownership을 갖고 '어떻게 하면 더 멋진 Product를 만들까?'라는 생각과 행동이 중요하다고 본다. 물론 Product Manager에 대해 정의를 하고자 했던 처음의 의도대로 이 직함을 가진 사람들의 직무를 정의하자면 이것저것 다 하는 잡부이면서 이것저것 다 결정할 수 있고 이것저것 모든 공백을 어느 정도 수준에서 메꿔주는 유일무이한 사람이다. (사실 어떤 도서에서는 산업의 경계도 없는 사람들이자 억대 연봉을 받을 수도 있는 사람들이라고 하던데 그건 아직 잘 모르겠다.)