스타트업에서 기획자, PM, PO란 용어가 혼용되어 사용되는 경우가 많다. 무엇이 같고 무엇이 다를까?
1. 기획자
예전에는 기획자란 용어만 있었다. '기획'하는 '사람'이란 뜻이다. 크게 네 가지 역할을 담당한다.
- 무엇을 만들어야 할 지에 대해서 생각하는 것. 특히 그것이 기존에 있는 제품과 어떻게 차별화되고 고객에게 어떤 가치를 만들어내는지에 대한 '관점'을 부여하는 것
- 기획서를 만드는 것. 상위기획서, 상세기획서가 있으며, 와이어프레임을 그리고 개발과 운영에 필요한 정책을 정리하는 것.
- 개발자, 디자이너, 세일즈, 마케팅 등 같이 일하는 동료들의 의견을 모으고, 일정을 조율하고, 각자가 자신의 일을 할 수 있도록 중심을 잡는 것
- 프로젝트 일정을 조율하고 의사결정이 필요할 때 경영진에게 보고하는 것
2. PM
Product manager 혹은 Project manager의 약자이다. 이 둘은 같은 의미로 쓰일 때도 있고, 회사마다 다른 의미로 쓰일 때도 있다. 일단 여기서는 Product manager의 의미로 사용될 때의 PM을 기준으로 설명해 보기로 한다.
먼저 질문.
기획자와 PM은 같은 것인가, 다른 것인가.
일단 여기서부터 혼선이 발생된다. 실제로 기획자와 PM을 같은 의미로 사용하는 경우도 많고, 완전히 다른 의미로 사용하는 경우도 많기 때문이다.
1) 기획자 = Product manager
기획자를 영어로 Product manager로 부르는 경우다. 영어로 명함을 찍을 때, 그리고 링크드인에서 자신의 직무를 영어로 쓸 때 '기획자'에 해당하는 정확한 영어 단어는 없다.
없다고요? 진짜요?
그렇다. 없다. '실리콘밸리에는 기획자라는 Role이 없다'라는 말을 들어본 적이 있을 것이다. 설령 어느 회사에 있다고 해도 일반적이지는 않는 것 같다. 페이스북에 다니면서 틈나는 대로 미국에 있는 동료들에게 물어봤었는데 한국에서 말하는 기획자와 그들이 말하는 PM이 하는 일은 매우 많이 달랐다.
기획자를 영어로 쓸 때 PM(product manager)로 칭하는 경우가 한국에서는 많으니, 제발 이런 것은 화내지 말고 그냥 좀 넘어가자.
2) 미국에서 사용되는 의미로서의 PM
실리콘밸리에서 '기획자'가 없다면 그들은 어떻게 일하는 것일까? 회사마다 다소간의 차이는 있지만 아래와 같이 일하는 경우가 많은 것 같다.
개발자, 디자이너, 데이터 분석가가 일한다. 기획자가 따로 있어서 기획서를 만들고 이 셋을 조율하는 것이 아니라, 처음부터 이렇게 셋이 바로 일을 한다. 기획자의 역할을 나누어 갖는 것이다. 실리콘밸리는 왜 이런 식으로 일할까?
저야 모르죠.
하지만 추측은 해볼 수 있다. 왜 그들은 기획자라는 포지션을 따로 두지 않는 것일까. 무엇 때문일까. 이 질문에 답하기 위해서는 한국의 기획자에게 요구되는 사항에 대해서 생각해볼 필요가 있다. 좋은 기획자가 되기 위해서는 어떤 역량이 필요한가?
시장의 니즈를 캐치하는 것. 어디에 집중할 것인가에 대한 차별화 포인트를 잡는 것. 이전에 없던 관점으로 시장을 바라보는 것. 그러한 내용을 개발과 디자인에게 전달하고 논의를 끌어내는 것. 이를 위해서는 해당 영역에 대한 이해가 필요하고 커뮤니케이션 스킬이 매우 뛰어날 것. 프로젝트가 제대로 진행되고 있는지 일정관리를 하고, 필요한 순간 경영진에게 보고하며 의사결정을 받아내고, 이를 바탕으로 다시 동료들이 일할 수 있도록 하는 것.
한 마디로 말하면 '슈퍼히어로'다.
그 결과는 어떻게 될까?
한국의 기획자 시스템의 장점과 단점은 매우 명확하다. 정말로 뛰어나 기획자가 있다면 실리콘밸리의 어떤 시스템 보다도 효율적으로 프로젝트가 진행된다. 그러나 반대로 기획자의 역량이 부족하다면 다수의 인원이 굉장히 비효율적으로 일하게 된다.
그렇기 때문에 네이버와 같은 회사는 2000년대 초반부터 '좋은 기획자, 역량있는 기획자'를 양성하는데 엄청난 공을 들였다. 좋은 기획자를 끌어모았고, 그 기획자들을 보며 주니어 기획자들의 실력이 늘어났다. '기획자 인큐베이팅 시스템'같은 것이 만들어졌던 것이다.
그런데 이 방식의 문제는 무엇인가?
좋은 기획자를 양성하는 것은 굉장히 어렵다. 그리고 기획자의 실력이 정말로 커지게 되면, 그래서 개발과 디자인과 원활하게 협업하고, 시장의 니즈를 읽고, 경영진에게도 당당하게 자신의 의견을 말할 수 있게 되면..,
그러면 보통 기획자를 그만두고 나가서 사업을 하게 된다.
결국 기획자는 양성하기도 어렵지만 유지하기도 어려운 포지션이다. 그렇기 때문에 실리콘밸리는 처음부터 기획자라는 포지션을 두지 않는 것이 아닐까 생각된다. 처음부터 개발과 디자인, 데이터 분석가가 같이 일하면서 같이 협업하고 일을 나누어 가진다. 이렇게 되면 한 가지 장점이 생기는데, 각자 자신이 만드는 제품에 좀더 주도성을 갖게 된다. 기획자가 기획한 것을 디자이너가 디자인하고 개발자가 작동하게 하는 것이 아니라, 제품 초기부터 어떤 제품을 만드는 것이 좋을 지, 그것이 잘 작동하는지를 확인하려면 어떤 데이터를 보는 것이 좋을지를 생각하기 때문이다.
잠깐, 그런데 개발, 디자인, 데이터분석가가 같이 일한다면 PM은 누가 하나요?
PM은 그 셋 중 하고 싶은 사람, 그 프로젝트를 가장 잘 이끌 수 있는 사람이 한다. 한국에서는 기획자가 기획의 Role을 맡는 경우가 많지만, 실리콘밸리에서는 누구나 PM이 될 수 있는 것이다.
여기서 한 가지 주의할 점!
나는 절대로 실리콘밸리 시스템이 한국의 시스템보다 더 우월하다고 생각하지 않는다. 두 시스템은 '다른' 것이다. 앞서도 말했지만 '정말로 실력있는 기획자'가 중심을 잡고 진행하는 프로젝트는 정말로 환상적으로 진행된다. 각자의 일이 명확하고, 모두가 자신의 일에 주인의식을 갖으면서도, 자신이 해야하는 업무에 집중하고, 경영진과의 커뮤니케이션도 좋다. 정말로 물 흐르듯 진행될 수 있는 것이다.
실리콘밸리에 비해서 한국은 자본과 기술, 그리고 시장사이즈, 언어 등 많은 면에서 엄청나게 불리한 조건으로 글로벌 회사들과 경쟁을 해야 한다. 이런 상황에서 그들과 똑같은 조건, 똑같은 시스템으로 승부하는 것만이 답은 아니다. 어렵지만 좋은 기획자를 양성하고 유지할 수 있다면, 그 안에서 굉장한 기회를 찾을 수 있다.
3. PO
Product owner의 약자이다. 토스를 서비스하는 비바 리퍼블리카의 이승건 대표가 한국에 가장 먼저 소개하고 발전시킨 개념이다. (이승건 대표 이전에도 PO 개념을 말한 사람이 있는지는 모르겠지만, 그 개념을 사람들에게 제대로 각인시킨 것은 이승건 대표가 처음이다)
PO와 PM의 차이는 무엇일까.
해당 프로젝트를 리딩한다는 점에서, 그리고 '상위 기획서, 상세기획서를 만드는 작업을 거의 하지 않는다'는 점에서, 다양한 직군의 사람들과 협업하며 사람들을 하나로 모으고 프로젝트를 리딩한다는 점에서 PO와 PM은 굉장히 공통점이 많아 보인다.
그러나 결정적인 차이가 있다. 그것은 바로 '의사결정권'이 누구에게 있는가 하는 것이다.
기획자나 PM은 스스로 결정하는 부분들도 있지만, 가장 핵심이 되는 부분에 대해서는 보고를 통해 '의사결정자'의 승인을 받는 프로세스를 거친다. 그러나 PO는 의사결정자의 의견을 수렴하기도 하지만 그것을 참고할 뿐 최종적인 결정은 자신의 책임 하에 진행한다. CEO나 최고경영진은 PO를 교체할 권리는 갖고 있으나, PO로부터 일일히 보고를 받고 승인을 하지 않고 PO가 직접 결정할 수 있도록 한다. PO를 '미니 CEO'라고 부르는 이유다.
그런데, 왜 이렇게 할까?
기존의 기획자, PM 방식은 의사결정이 상위에 있다보니 '속도감'을 살리기 쉽지 않았다. 보고에 보고에 보고를 거쳐본 사람들은 알 수 있을 것이다. 레이어 하나를 거칠 때마다 얼마나 일정이 지체되는지, 그리고 그 단계마다 누군가 한 마디씩 하면서 처음에 기획했던 제품의 날카로움이 어떻게 사라져버리는지. (이것은 내가 만들고자 했던 것이 아닌데...)
무엇보다 결정할 권한이 자신에게 있지 않기 때문에 해당 프로젝트에 대한 주도성도 낮아지게 된다. 정말로 책임감을 가지고 진행하기 보다는 '어차피 위에서 결정할 거니까' 대충 해서 들고가게 되는 것이다.
CEO나 최고 경영진 입장에서도 모든 것을 다 판단하기에는 그 세세한 영역을 본인이 다 직접 알기도, 질문을 통해 이해하기도 쉽지 않은 경우가 많다. 그렇기 때문에 각각의 프로젝트에 대한 권한을 PO에게 맡기되, 회사의 방향과 정보를 투명하게 공유함으로써 PO가 올바른 판단을 할 수 있도록 하는 것이다.
정리하면 이렇다.
- 기획자: 기획하고, 정리하고, 조율하고, 보고한다.
- PM: 기획서 부분이 줄어드는 대신, 협업과 일정관리, 그리고 보고역할이 더 중요해진다.
- PO: 자신의 책임 하에 결정한다. 기능조직 보다는 목적조직에 어울린다.
4. PO체제의 한계와 부작용
위와 같이만 적으면 PO가 또 만병통치약 같은 느낌을 줄 수 있기 때문에 이에 대한 생각도 아래와 같이 정리해본다.
1) 이름뿐인 PO가 많아졌다.
PO를 뽑은 후에 CEO가 여전히 주요한 의사결정을 하는 스타트업이 많다. 이것은 PO라고 부르기 어렵다. 그리고, 인원규모 상 PO를 굳이 둘 필요가 없는 경우에도 이름 뿐인 PO를 두는 경우도 많다. 이렇게 되다보니 기획자와 PM, PO의 개념이 계속해서 혼재되는 결과를 낳게 된다. PO인데 PO의 역할을 하지 못하는 경우가 많기 때문이다.
2) 누구나 PO가 되고 싶어한다. 그러한 역량이 없음에도 불구하고.
바야흐로 모두가 PO가 되고 싶어하는 세상이 온 것처럼 느껴진다. 자신의 뜻대로 개발, 디자인, 데이터, 사업, 마케팅을 움직일 수 있다는 것에 매료되는 사람들이 많기 때문이지 않을까 한다.
그런데 PO의 역할을 제대로 할 수 없는 사람이 PO를 하면 어떻게 될까?
무서운 일이 벌어진다.
PO가 되고 싶어하는 사람 중에, 자신이 PO의 역량을 갖추었는가에 대해서 진지하게 고민하는 경우가 얼마나 될까? 역량이 없는 사람이 다양한 직군의 사람들을 이끌면 그 프로젝트에 참여한 모든 사람들이 굉장히 힘들어진다. 그 모습을 보다못한 CEO가 아쉬운 점들을 지적하며 관여하기 시작하면 PO체제의 의미는 퇴색된다.
토스는 업계 최고의 역량을 가진 PO를 채용하는데 진심인 것처럼 생각된다. 연봉을 50% 이상 얹어 주고, 스톡옵션도 파격적으로 제공하면서 '진짜로 잘하는' 사람들을 찾는다. 또한 잘하는 PO의 모습을 보면서 다른 주니어 PO들이 성장할 수 있는 여건을 만들어 나가는 것처럼 생각된다. 네이버가 기획자 인큐베이팅 시스템을 만들었던 것처럼 토스는 잘 하는 PO를 끌어들이고, 양성할 수 있는 시스템을 만드려고 노력하는 것이다.
그런데 일반적인 스타트업은 어떠할까. 어떠한 역량을 갖고 있는 사람을 부르고 있는가. 조직 내부의 사람들을 성장시키기 위해 어떤 노력을 하고 있는가.
많은 스타트업에서 창업가, 혹은 CEO는 뛰어난 개인 역량을 갖고 있는 경우가 많다. 그러나 상대적으로 직장 경력이 적은 젊은 CEO의 경우, 시스템을 만들기 위해 필요한 사람을 끌어오고 그 사람들을 통해 기존의 사람들이 체계적으로 실력을 키울 수 있도록 하는 대신, 자신이 직접 업무를 지시하는 경우가 많다. 처음에는 잘 돌아간다. 그러나 사업이 어느 정도 커지고 도저히 혼자 할 수 없게 되는 상황이 되면 많은 것들이 삐걱거리게 되는 것이다.
PO가 좋아보인다고 누구나 PO체제를 도입할 수도 없고, 그럴 필요도 없다. 각자 자신의 상황에 맞는 선택을 하면 되는 것이다.
3) PO체계는 기능조직이 필요한 사업에는 어울리지 않는다.
좋은 PO를 보유한 회사들은 일반적으로 목적조직 형태의 조직구성을 가지고 있다. 프로젝트별로 개발, 디자인, 데이터, 사업, 마케팅 등의 기능을 넣어 자체적으로 Ownership을 가지고 의사결정을 한다.
이러한 목적조직은 '속도'에서 굉장한 강점을 가지게 된다. 각각의 조직이 신속하게 방향을 맞추고 다양한 시도를 하면서 그 안에서 발견한 인사이트를 해석하여 바로바로 다음 단계의 실행으로 옮긴다.
그러나 '어느 상황에서나 효율적인 조직체계'란 것은 없다. 그런게 있으면 다들 그것만 하겠지.
다양한 목적조직으로 분화된 조직은 '그 목적조직 간에 Align을 맞추는 것'의 난이도가 어마어마하게 올라간다. 서로간에 충돌도 많고, 같은 일을 여러 목적조직에서 하기도 하고, 전사 우선순위보다 각 조직의 우선순위가 더 높아지기도 한다. 조직 내의 협업도는 올라가지만 조직 간의 협업도는 떨어지게 되는 것이다. 각 조직의 PO가 자체적으로 의사결정을 하기 때문에 CEO라 하더라도 전사 우선순위를 강제하기도 쉽지 않게 된다. 한 마디로 다 따로따로 놀 수 있다.
더욱 문제가 되는 것은 목적조직은 '골조공사가 필요한 프로젝트'에 구조적으로 약할 수밖에 없다는 점이다.
높은 빌딩을 올리려면 일단 땅부터 파야한다. 속도를 높여 치고 나가는 것이 중요한 것이 아니라, 누군가 기반시설을 탄탄히 하고 그것으로부터 하나씩 체계를 갖추는 작업이 필요하다. 좌충우돌하면서 단서를 찾는 작업이 필요한 것이 아니라, '청사진'이 필요할 때에는 누군가 전체의 판을 보면서 어디서부터 구조를 쌓아야 되는지를 차분히 앉아 생각해야 한다.
기반을 다지는데는 시간이 필요하다. 그리고 그 작업이 정말로 어느 정도의 Impact을 가져올지 정확히 계산하기도 어렵다. 노력에 비해 결과를 바로바로 알 수 있는 것도, 측정할 수 있는 것도 아니다. 그럼에도 불구하고 그 작업이 필요한 과제가 있다. 빠르게 뛰어가는 것만이 능사가 아닌 것이다.
결국 리더는 자신의 상황에 맞는 조직체계를 갖추고, 그에 맞는 사람들을 불러들여야 한다.
경영에는 정답이 없기 때문이다.
