Product Manager와 기획자의 역할
'아이디어를 만들어 내는 것' 만으로 역할이 끝날까?
이글은 2013년도에 작성된 글을 브런치로 옮겨온 것입니다
Product Manager와 기획자는 '아이디어를 만들어내는 것'만으로 역할이 끝날까?
글을 쓴지 3년반이 지났다. 또한, IT전문 미디어 Platum에 올린글은 2013 Platum에서 가장인기 있던 글 Top10(순위는 미 제공)에까지 올랐었다. 블로그에도 올렸었다.
그럼 글을 쓴 이후 3년 반, 짧지않은 시간안 무슨일이 있었을까.
개인적으로는 여러 회사에서 다양한 업무를 했었다. Product Manager를 비롯해서, UX 기획, Business Development, Sales/Marketing등등.. 하지만 인원이 적은 회사 특성상 Product Manager 역할을 놓을수가 없어서 항상 겸업을 했었던것 같다. 이전에는 삼성에서 업무가 매우 세분화되어있었다면, 그 이후에 회사들은 전체 인원도 작았지만, 단위 사업당 인원 수는 매우 적어서 여러 역할을 할 수 밖에 없었던것 같다.
MBA졸업 후, 그동안에 S/W 쪽으로 전환을 하게되면서 모바일 서비스들을 담당했었다.개인용 클라우드 앱, 뮤직, 비디오 서비스, 카메라 앱, Payment 앱, 삼성, 엘지향 웨어러블 디바이스앱 각각, 고속버스, 콜택시앱, 포인트 서비스, AD Product.. 짧은 기간에 10여개의 정말 다양한 Product 들을 거쳤고, 그중에 망한것도, 나름 잘된것도 있었고, 작게는 3만 부터 십만단위, 백만, 300만 사용자(MAU 기준)까지 여러 프로젝트에 투입되어 30%~100%까지 다양하게 오너쉽을 가져갔었던것 같다. 나름 편하게 살려면 살 수 있는 회사들?에서, 뭔가 만들어지고, 발전되가는 모습을 좋아해서 혼자서 채찍질해가며, 욕도 먹어가며, 그렇게 시간은 흘러왔다. 다행히 성과는 좋았던것들도 있어서, Business 관련 업무를 맡은것 중에는 Product Renewal을 통해서 전체 플랫폼 매출대비 3%에서 40%까지 급격히 상승하게 만든 Product도 있으며(기존 매출의 10배이상 증가) 모 앱이 나오기 위해 H/W 구매를 미루고 있는 사용자들도 만난 신기한 경험도 하고, 마케팅 비용 0원으로 다운로드 50만까지 가보는 경험도 해보았다. (물론 그 중에는 망해서 소리 소문 없이 사라진 서비스도 당연히 있다)
많은 일들이 있었지만, 어쨋든 뭔가 더 잘만들어 보고 싶어서, 더 일을 하고 싶어 하는 열망으로 쭉 달려왔었던것 같고, 대학원 조기졸업을 하게되면서, 빨리 일해 보고 싶다고 했던 생각했던 부분을 일의 양 측면에서는 어느정도 만족 시킨게 아닌가 싶다.
그렇다면 Product Manager역할로 일하면서 느낀점은?
사실 이전에는 H/W를 다루었었기 때문에, 조금은 다른 경험들을 해볼 수 있었다. 그리고 한국에서는 IT서비스에서 많은 이야기거리가 되고 있는 '기획자'라는 역할과 Product Manager의 차이점. 외주와 직접개발등 다양한 부분들에 대해 조금은 겪어보게 된듯 하다. 아무래도 기본적인 Product Manager의 업무 속성에서는 비슷할 수 있지만, 산업/구조 특성상 다른 부분들이 꽤 존재하는 부분도 많았었다.
여러가지 토픽이 있을 수 있겠지만, 가장 먼저 해결해야되는 부분은 '기획자'와 'Product Manager'가 무엇이 다른가요? 라는 질문에 어떻게 대답해야할지에 대한 나름의 기준이 생겼다는것 정도가 될것 같다.
대한민국에서 IT S/W산업은 기존에 기업들이 디지털분야에 대해 니즈가 발생하면서 단기적인 시스템/서비스 구축을 위해 외주형태를 매우 많이 사용하게 되었다. 90년대 중반 이후 IT프로젝트들이 수없이 생겨나면서, 개발자와 더불어서, 디자이너가 필요해졌고, 기존 기업의 직원들(사업관련팀/관리팀/기타 타 전문직무 팀)의 요구사항들을 개발자와 디자이너가 구현할 수 있도록 커뮤니케이션 해주고, 밑그림을 그려주는 '기획자'라는 용어가 생겨났던듯 하다.
물론 이런 상황에서 그 기획자가 상위레벨의 전략이나 컨셉을 정하는건 불가능에 가깝고, 잘하면 제안정도 하고 컨펌받는 역할을 맡게 되었을 것이다. 그리고 그 전략/컨셉/방향이 결정되면, 디자이너가 구현하기 위한 스케치(Wireframe, User Interface)를 만드는것까지를 책임지는것이 일반적인 '기획자'가 하는 역할이 되게 되었다.
그러다보니, 위에 등장역할등은 아래와 같은 업무영역을 가지게 된다.
조직구조 및 R&R
1. 요구사항 발주자(원청 실무팀(사업/관리/기타)) : 전체적인 사업방향성 결정, 컨셉, 전략적 의사결정 부분
2. 기획자 : 원청업체/디자이너/개발자 커뮤니케이션 + 디자인 구현을 위한 일명 스케치(Wireframe, UI)
3. 디자이너 : 기획자가 가져온 UI를 GUI로 변환 (GUI Asset, Guide)
4. 개발자 : 기획자의 UI에 디자이너의 GUI를 입혀 웹/앱으로 개발
이슈
가. 위와 같은 조직 및 업무구조에서 볼때, 개발 방식은 아시다시피 Waterfall(폭포수 방법론?) 이고, 의사결정권한이 아래로 갈 수록 매우 적기 때문에, 아래로부터 위로의 피드백은 정말 심각한 이슈외에는 무시되고 불가능해진다.
나. 또한, 1번 요구사항 발주자과 2번의 기획자의 역할이 일부분 겹치고(의사결정, 컨셉, 커뮤니케이션), 2번 기획자와 디자이너의 역할이 일부 겹치게 된다(UI --> GUI, 사실 요즘은 UI 문서를 따로 제작하지 않고 UX를 담당하는 전체 디자이너가 모두 설계하는 경우도 많으니)
각자의 전문영역이 있는데 반해 '가'의 이슈로 인해 피드백 및 전문성 상실은 무시되고, 3번,4번으로 갈수록 더 잘 알고 있는 문제점들에 대해 입을 다물게 되고, 그로 인해 서비스들은 성공적으로 진행되기 쉽지 않게 된다. 또한 '나'이슈로 인해 원청, 기획자, 디자이너간에 R&R이 불명해지고, 전문성을 무시하면서 잘 모르면서도 소위 '훈수'를 두면서 품질자체를 떨어뜨리게 되는 경우도 빈번히 발생하게 된다. 아마 자체 개발하는 회사만 다녀보신분들은 대다수 이해못하거나, 무언가 이상한 조직/역할 구조라는것을 느낄것이다.
다시 원론으로 돌아와서, 그렇다면 '기획자'와 Product Manager는 뭐가 다르고, 어떻게 해야 저 구조의 문제점들을 해결할 수 있을까?
3년반 전에 썼던 글에 보면 Product Manager의 가장 큰 차이점은 세가지라고 생각되는데, 1, 의사결정권한의 확대, 2.해당 Product에 대한 확고하고 다양한 지식(이전 글 본문, 'PM의 다섯가지 요소'중 하나), 3. 다양한 부서와 협업의 중심이 되는것 이 그것이다.
1.의사결정권한의 확대
Wikipedia에 Product Manager에 대한 정의를 보면 Product Manager는 'often called the product 'CEO'라고 할만큼 단위 Product에서는 나름 높은 권한을 가지고 있어야 한다. 세부설명에서도 사업적, 기술적, 기타 스케쥴링등Project manage 및 전체적인 사항들에 모두 관여할만한 권한과 역할을 기대하고 있다.
2. 해당 Product에 대한 지식
또한, 원활한 개발자와 디자이너와 커뮤니케이션을 위해서는 대화법 및 R&R, 기타 Project Management 스킬뿐만 아니라, Product 에 관련된 분야에 대해 지식이 필요하다. 사업/서비스적인 도메인 지식은 당연할 뿐만 아니라, 개발자/디자이너와 소통을 위한 전문지식 또한 일정부분을 알고 있어야 한다.
물론 개발자의 코드의 문법까지 알아야 할 필요는 없고, 디자인의 컬러값까지 외우고 있어야할 필요는 없지만, 모바일 서비스 기준으로는 무언가 만들고 싶은 기능이 있을때, 개발자에게 내용을 정확히 전달하고, 필요시 기본적인 개발문서를 찾아보면서 같이 의논해줄 필요는 있다. 어느 OS에서는 해당 기능이 되는지, 안되는지, 만드는 앱은 어느정도 수준이상의 OS나 device를 지원해야되는지 정도는 최소한을 알 필요가 있다. 알아야할 모든 기술적인 지식들은 그 구현 가능여부 뿐만 아니라, 사업적인 목표 달성을 위한 효율성 측면에서의 선택을 위해 알아야 할 부분이다.
디자인 부분도 마찬가지라서 가이드는 어떻게 생성되는지, 왜 안드로이드에서는 PX이 아니라 dp값을 사용하는지, 나인패치가 무엇인지등 기본적인 지식을 알고 있다면, 개발자,디자이너와의 협업에 더욱 도움을 줄것이며, 프로젝트가 효율적으로 돌아가게 할 수 있을 것이다.
3. 다양한 부서와의 협업에 중심
Product 가 만들어지고, 이후에도 제 기능을 다하려면, 기술적인 부분 외에도 아래 그림 처럼 다양한 부서/역할과 협업이 필요하다.Partnership, revenue flow, Cost, Sales/Marketing/Resource등 여러 부분에 대한 지식을 가지고 커뮤니케이션이 가능해야 하고, 그 중심적인 역할을 원활하게 돌아갈 수 있도록 해야하는것이다. 요구사항 발주자가 아닌, Product Manager가 중심이 되어, 전문지식들을 관리하고 프로젝트를 운영하며, 이해관계자들을 조율하는 역할을 하는것 말이다.
꽤 긴글을 쓰다보니 복잡한 부분이 많았지만, 정리해보면 시사하는바는 다음과 같다.
만약 본인이 있는 조직이 1.의사결정권한의 확대까지 해주게 된다면 금상첨화지만, 불가능할 경우에는 2. 해당 Product 에 대한 지식이라도 먼저 습득해야할것 같다. 단순히 상상속에만 가능하고 실제 구현이 불가능하거나, 사실상 실현되기 어려운 상황을 무리하게 주장하지 않으려면, 필수적일 것이다. 지식기반의 커뮤니케이션이 원활해질 때, 개발/디자인의 성능도 올라갈 것이고, 전체 Product의 성공확률도 높아질 것이다.
조직 관리할 수 있는 권한이 있다면, 산업/카테고리마다 다르긴 하겠지만, 1번 요구사항 발주자의 권한을 축소하고(사업관리기획/마케팅의 전문 역할에 집중), 서비스 자체는 Product Manager가 세부적인 의사결정을 하게 하는것이 어떨까.
UI, 일명 쉽게 풀어서 화면의 밑그림인 스케치는 디자이너가 UX를 총괄할 수 있도록 하고 Product Manager는 '기획자'와는 다르게 모든 전문분야 담당자들과 커뮤니케이션하고 조율하는 역할을 하는것 말이다.
나 또한, 아직까지 회사에서 1.의사결정권한의 확대를 위해 개인적으로는 고군분투 하지만, 쉽지는 않다. Product Manager(Owner)제도를 실시하는 회사기는 하지만, 제대로 자리잡기까지는 시간이 걸리기에 아직 먼길일것이다. 그래도 단순 그림그리는 '기획'만 하거나, 요구사항 발주자 개념에서 '오더'만 하는것보다는 나으려면, Product Manager라고 생각하고 더 배우고 듣고, 이야기하고 실행하는것이 필요하지 않을까
** Project manager, Program manager와의 차이는 또 무엇이냐 묻는 분들이 많이 계신데, Wikipedia의 문서를 참조해볼 수 있을것 같다. 또한, 산업마다 회사마다 조금씩 용어의 차이가 있으므로 정확한 definition 보다는 의미론 적으로 받아들이면 좋지 않을까 싶다.
Product marketing manager: may perform all outbound marketing activities in the older sense of the term
Project manager : may perform all activities related to schedule and resource management
Program manager: may perform activities related to schedule, resource, and cross-functional execution
Product owner : a popular role in Agile development methodology, may perform all activities related to a self-encapsulated feature or feature set plan, development and releases.
Technical product manager: similar to product owner, but may perform all activities from technology perspective.
Product designer: closer to UX designer but more focus on entire function flows.
