토스/쿠팡 식 PO조직이 실패할수밖에 없는 이유
목적 조직과 기능 조직
토스는 PO를 중심으로 한 목적 조직이 스타트업에서 유행이다.
기능 조직 : [PO팀장/PO팀], [개발팀장/개발팀]와 같이 각 기능별로 팀이며, 기능 필요 시 PO팀, 개발팀, 디자인팀 각각 작업자를 할당 받아 운영되는 조직으로 1개의 기능에 대한 스폐셜리스트를 요구하기보다는 다양한 업무를 처리하기 위해 다양한 도메인에 대한 이해도를 요구한다.
목적 조직 : [PO, 개발자, 디자인]과 같이 각기 다른 부서가 1개의 팀으로 운영되며, [상품], [결제], [광고]와 같이 각 1개의 목적만을 위해 만들어진 팀으로 1개의 기능에 대한 스폐셜함을 요구한다. 기능조직 처럼 1명의 개인에게 다양한 도메인에 대한 이해도를 요구하지않는다.
하지만 토스/쿠팡 처럼 목적조직으로 성공했다고 하는곳은 찾기가 어렵다.
그 이유는 간단하다.
대부분의 토스/쿠팡과 같이 PO중심의 목적 조직을 운영하겠다고 선언하는 곳은 대부분 의사결정권자가 모든것을 팔로업하지 못하기에 다른 사람에게 권한을 부여함으로서, 의사결정을 빠르게 하고자 조직을 구성하기 때문이다.
토스와 쿠팡의 공통점은 3가지가 있다.
1) 탑 다운 위주의 회사로 워라벨이 극악이다.
2) PO는 엄청나게 똑똑하고 검증된 인재야하며 제너럴한 스폐셜리스트여야한다.
3) 개발자들이 기본적인 커뮤니케이션 역량이 있어야하며 스스로 기획의 영역까지 같이 참여해야한다.
다른 스타트업들은 3가지의 조건에 충족하지못하면서 토스/쿠팡처럼 하려고하기에 많이 실패한다.
그 이유는 각 항목별로 아래와 같다.
1) 탑 다운 위주의 회사로 워라벨이 극악이다.
- 탑 다운이 심하고, 워라벨이 극악이다. 라는것이 그렇다면 토스와 쿠팡은 조직장인 PO가 구성원들을 탑다운으로 밀어붙이며 야근을 시키는 것일까? 아니다. 목적조직임에도 목적조직의 장인 PO보다 팔로업이 빠르고 더 많은 사항들을 확인하여 많은 요구사항을 내려주는 "부지런한 리더"가 항상 존재하기 때문에다. "야근을 많이 시킨다 = 부지런하다"를 말하는것이 아니라, 목적조직이 느슨하게 운영되고 도태되지 않도록 끊임없이 미션을 준다는것이다. 그들에게 미션을 달성할수있는 수치와 미션을 달성할 수 있는 요소들을 끊임없이 제안하고 확인하기에 탑다운이 심하며 워라벨이 심해지는 것이다.
하지만 다른 스타트업들의 경우 목적조직을 "내가 다 못챙기니까..."에서 시작을 한다. 그렇기에 애초에 "내가 못챙겨서 각 전문가들에게 맡긴다"에서 시작한 목적조직은 실패할 수 밖에 없다.
2) PO는 엄청나게 똑똑하고 검증된 인재야하며 제너럴한 스폐셜리스트여야한다.
- 목적조직에서의 PO는 상위 조직자와 협의하는 커뮤니케이션 스킬, 구성원들을 이끌어가는 스킬, 지표를 끊임없이 확인 하는 스킬 등 PO는 적어도 2개 ~ 3개이상의 서비스를 경험하거나 최대한 올바른 의사결정을 하는 사람이어야한다. 그렇기에 토스/쿠팡에서는 PO들은 "서비스 기획자"의 경험만 있는것이 아니라 과거 PM이라 불리던 "프로젝트 매니저" 총 2가지의 포지션을 완벽하게 수행 할 수 있는 사람들이다.
하지만 한국의 스타트업은 그냥 "서비스 기획자"들을 "PO"라며 과거 "서비스 기획자"와 "PM" 2가지로 존재했던 직무를 1개의 직무로 인건비를 줄이기 위해 "PO"라는 이름으로 강제 전직 시켜버렸다.
그렇기에 "기획"까지는 문제없이 진행되나 사람들다루는 스킬인 "PM"으로써의 스킬이 전혀 없는 사람들이 "PO"가 되어버렸다.
그렇기에 "서비스 기획자가" 주도하는 목적 조직은 정리가 되지 않고 효율적인 업무가 되지 않는다.
협업이란것을 "PM"을 통해 항상 해오던 "서비스 기획자"들은 타팀과의 협업도, 본인 외 부서에 대한 서비스에 대한 이해도 하려고 하지않는경우들이 발생한다. 그 과정에 "서비스 기획자"출신들의 "PO"들이 매니징을 학습하는 과정인 1~2년동안 서비스는 각 기능별로 따로 움직이며 1개의 서비스에서 다른 서비스를 운영하는 느낌의 이상한 서비스로 변질되게 된다.
3) 개발자들이 기본적인 커뮤니케이션 역량이 있어야하며 스스로 기획의 영역까지 같이 참여해야한다.
- 2번에 언급한것 처럼 "서비스 기획자"가 "PM"의 업무를 같이하며 "PO"라는 직무가 되자, 과거 처럼 "서비스 기획자"가 "개발자"들의 모든 사항에 대해 기획을 해주지 못하게 되었다. 개발자는 "PO"의 인사이트에 따라 어떻게 개발할지, API는 어떻게 구성해야할지 스스로 고민해야하며 기획까지 어느정도 참여하게되었다. 하지만 2번에서의 케이스와 같다. "서비스 기획자"가 모든것을 기획해주던것에 익숙한 "개발자"들은 변화 과정에서 적응하지 못한다. 그렇기에 "PO"와 "개발자"간의 합이 맞지 않게되고 개발 기간은 늘어나게 된다.
그렇기에 토스/쿠팡 식 PO조직이 실패할수밖에 없는 이유라고 생각한다.
나름의 방법은 찾아 목적 조직이 필요한 경우에만 목적 조직을 구성하거나, 기능조직 안에 일부 영역만 목적 조직을 운영하는 방식으로 방법을 찾아나가고있으며 정답은 없기에 항상 고민을 할 수 밖에 없는 사항이다.
