PM(프로덕트 매니저)와 PO(프로덕트 오너)의 차이? 헷갈리지 않도록 딱 정리해 드립니다.
1. PM과 PO, 뭔가 비슷한 듯 다른 듯 알쏭달쏭합니다.
한국에서는 기업의 총수를 오너(owner)라고 불러서 그런지 PO(Product Owner)가 더 높은 사람인 것 같기도 합니다. 반면 해외 사람들 중 자신을 PM(Product Manager)으로 소개하는 사람은 있어도 PO로 소개하는 사람은 거의 보이지 않습니다.
2. 채용공고를 살펴 봐도 제각각입니다.
어떤 회사들은 PM만 채용하고, 어떤 회사들은 PO만 채용합니다. 어떤 회사는 PO와 PM을 모두 채용합니다. 두 용어가 혼재하고 있어서 취업준비생은 물론이고 현업에서 일하는 분들도 헷갈리는 경우가 많은 것 같습니다.
3. 어원을 거슬러 올라가 보면 이렇습니다.
제가 조사한 바에 따르면 이렇습니다. 일단 Product Owner라는 용어는 1990년대에 스크럼(Scrum)이라는 제품 개발 프레임워크와 함께 탄생했습니다.
4. 1990년대의 프로덕트 매니저(Product Manager, PM)
1990년대에도 Product Manager(PM) 직군은 있었는데, 이들의 역할은 지금과는 조금 달랐습니다. 이들은 대체로 마켓 리서치를 하고, 제품 계획을 세우고, 요구사항을 정의했습니다. PM은 그렇게 정의한 요구사항을 프로'젝'트 매니저(Project Manager)에게 전달했습니다. 그러면 프로젝트 매니저가 개발팀, 즉 디자이너와 엔지니어들과 소통하면서 제품을 만들어내는 실행을 담당했습니다.
그러니까 전략과 비전은 프로'덕'트 매니저가, 실행은 프로'젝'트 매니저가 하는 이분법적 역할 구분이 있었던 겁니다.
5. 스크럼 프로덕트 오너: 전략, 비전 + 실행까지 하는 사람
그렇게 전략은 프로'덕'트 매니저, 실행은 프로'젝'트 매니저로 역할을 구분해 놓았던 것을 스크럼에서는 프로덕트 오너(PO) 역할 하나로 합쳤습니다. 그렇게 한 이유는, 스크럼 개발 방법론이 긴밀한 협업을 중시했기 때문입니다. 제품 비전과 요구사항을 설정하는 프로덕트 매니저가 개발팀과 멀리 떨어져서 일하는 방식으로는 기민하게 제품을 만들기 어려우니까요.
6. SAFe에서 말하는 PO의 역할
그러다가 SAFe(Scaled Agile Framework, 확장형 애자일 프레임워크)라고 불리는 방법론이 등장하면서 혼선이 생기게 됩니다. 이건 대기업 등 큰 조직에서 제품을 개발하기 위한 프레임워크라고 하는데, 저도 대기업에서 일해 본 적은 없어서 구체적으로 어떤 건지는 잘 모릅니다.
어쨌든 이 SAFe에서는 다시 프로덕트 매니저(PM)와 프로덕트 오너(PO) 역할을 나눴습니다. PM은 개발조직 바깥쪽에 집중하는 사람입니다. 고객의 니즈나 비즈니스 부서들의 니즈를 파악하고, 그걸 토대로 제품의 비전이나 전략을 설정하는 역할을 합니다. PO는 개발조직 안쪽에 집중하는 사람입니다. 프로덕트 매니저가 세운 비전이나 전략을 토대로 프로덕트 백로그를 만들고, 디자이너 엔지니어들과 협업해서 제품을 만드는 일을 합니다.
7. Scrum PO: 전략+실행 다 하는 사람 / SAFe PO: 실행만 하는 사람
아주 커다란 기업에서 효율적으로 일하기 위해 이렇게 프로덕트 매니저와 프로덕트 오너 역할을 구분했다고 하는데, 어쨌든 이러면서 용어에 대한 혼선이 생겼습니다.
같은 PO라고 하더라도 스크럼의 PO는 비전, 전략, 실행을 모두 맡습니다. 개발조직 바깥에서 고객과 비즈니스 쪽 니즈를 파악하는 일도 하고, 개발조직 안에서 디자이너 엔지니어들과 협업해서 솔루션을 구체화하는 일까지 다 하는 역할인 거죠. 그에 반해 SAFe의 PO는 개발조직 안에서 실행만 하는 역할입니다. 같은 용어인데 전혀 다른 두 가지 역할을 가리키니, 혼선이 생길 수밖에 없었겠죠.
8. 해외의 앞서가는 테크기업들은 PM으로 용어 통일
제가 아는 한, 해외의 앞서가는 테크기업들에서 PO라는 잡 타이틀은 거의 쓰이지 않습니다. 업계에서 인정받는 프로덕트 피플 중 자기 자신을 PO로 소개하는 사람도 눈을 씻고 찾아봐도 찾기 어렵습니다. 각종 아티클, 강의 등에서도 PO라는 용어는 거의 쓰이지 않습니다.
일례로, 유명한 강의 플랫폼인 maven.com에서 'product owner'로 검색해 보면, 제목에 'product owner'가 들어간 강의는 1개만 나옵니다.
반면 'product manager'로 검색하면 (이 글을 쓰는 시점에) 105개 강의가 검색됩니다.
사실상 Product Manager로 용어가 통일이 된 셈이죠. Product Owner라는 용어는 스크럼이나 SAFe 같은 개발 프로젝트 관리 방법론을 설명하는 자료 외에서는 거의 찾아볼 수 없습니다.
9. 그런데 한국에서는...
그런데 반대로 한국에서는 프로덕트 매니저보다는 프로덕트 오너라는 용어가 더 널리 퍼졌습니다. 이건 토스와 쿠팡의 영향이 큰 것 같습니다. 토스와 쿠팡이 프로덕트 오너 직군을 만들고, 뛰어난 역량을 가진 사람들이 이 기업에 몰리다 보니 한국에서는 ‘프로덕트 오너 = 프로덕트에 대해 오너십을 가지고 전략을 설정하고 의사결정을 하는 사람’이라는 인식이 자리잡게 됐습니다. 그러다 보니 다른 많은 회사들이 PO라는 잡 타이틀을 도입하게 됐습니다. 기업의 총수를 '오너'라고 부르는 것 역시 이런 인식에 영향을 끼쳤다고 저는 생각합니다.
반대로 프로덕트 매니저는 ‘전략보다는 실행을 담당하는 사람’이라는 인식이 생겼습니다. SAFe에서는 프로덕트 매니저가 비전과 전략을 설정하고 프로덕트 오너는 실행을 담당하는 역할인데, 한국에서는 반대가 된 겁니다.
10. 한국 테크기업이라고 다 같지 않습니다.
그런데 한국 테크 기업이라고 해서 다 쿠팡이나 토스의 영향을 받은 건 아니라서, 해외와 같이 ‘PM = 비전, 전략, 실행을 모두 담당하는 역할’로 정의하는 회사들도 있습니다.
그러니까 스크럼이라는 방법론에서 얘기하는 PO의 역할 정의, SAFe라는 방법론에서 얘기하는 PO와 PM의 역할 정의, 실리콘 밸리 테크 기업들에서 갖고 있는 PM의 역할 정의, 한국에 이 직군이 수입되면서 생긴 역할 정의가 제각기 다른 겁니다. 혼선이 생길 수밖에 없죠.
11. 그러니까 PM인지, PO인지 용어에만 집착하면 안됩니다.
회사마다 PM의 역할, PO의 역할을 각기 다르게 정의하니까요. 중요한 건 'PM 채용공고인지, PO 채용공고인지' 여부가 아니라, 실제로 특정한 조직에서 그 직무를 가진 사람들이 어떤 역할을 하는지입니다.
12. 이름만 PM/PO, 실상은 (옛날식) 서비스 기획자
어떤 분들은 명함에 PM/PO 타이틀이 새겨져 있지만, 실상은 옛날식 서비스 기획자들과 동일한 일을 하고 있습니다. 이해관계자들로부터 요구사항을 수집하고, 그에 따라 화면설계서와 기능명세서를 만들고, 그걸 디자이너와 엔지니어에 전달하고, 프로젝트 관리를 하는 역할을 하죠.
이런 분들은 아무리 오래 일하더라도 문제 정의와 해결, 가설 수립과 검증, 데이터 활용 등 (요즘 PM/PO 채용공고에 단골로 나오는) 업무는 해보지 못하고 커리어를 마감합니다. 프로젝트가 하나 끝나고 나면 다음 프로젝트를 하기 바쁘기 때문에, 데이터와 유저/고객 피드백을 통해 제품을 개선하는 이터레이션(iteration)도 경험하지 못하구요. 아마 요즘 PM/PO를 지망하는 분들은 이렇게 일하고 싶지 않을 겁니다.
13. 빅네임 회사에서 일하는 분들도 마찬가지
사족이지만 저는 국내의 (취업준비생들이 선호하는) IT 대기업들에서 일하는 분들을 종종 만나 보았는데, 그들 중 많은 분들이 이런 식으로 일을 하고 있었습니다. 아마 '서비스 기획자' 직군의 이름을 PM/PO로 바꾸기만 한 것이겠죠. 꼭 큰 회사라고 해서 프로덕트 매니저로서 재미있게 일하기에 좋은 회사는 아니라는 얘기입니다.
14. 구직자 입장에서는?
구직자 입장에서, '나는 실리콘 밸리 프로덕트 매니저처럼 (혹은 토스나 쿠팡의 PO처럼) 일하고 싶지, 옛날식 서비스 기획자처럼 일하고 싶지 않다' 하고 생각하는 분들은 어떻게 해야 할까요?
15. 채용공고 꼼꼼히 읽기
기본적으로는 채용공고를 꼼꼼히 읽어봐야 합니다. 채용공고를 잘 들여다 보면 PM/PO에게 어떤 역할을 기대하는지 대강 알 수 있습니다. 만약 '이해관계자들의 요구사항을 충족'시킨다든지, '이해관계자들과 원활한 커뮤니케이션' 같은 문구들이 나온다면, 옛날식 서비스 기획자일 가능성이 있습니다. 특히 이게 채용공고의 앞부분에 나온다면 더더욱 그렇구요.
16. 조직 구조 보기 (디자인팀 따로, 개발팀 따로 있는 곳이라면...)
회사의 조직 구조를 보는 것도 도움이 됩니다. 만약 프로덕트 팀(PM/PO/기획자로만 이뤄진 팀), 디자이너 팀, 개발팀이 따로 따로 있는 회사라면, 이런 곳에서 일하는 분들은 잡 타이틀은 PM/PO지만 높은 확률로 옛날식 서비스 기획자처럼 일하고 있습니다.
그럴 수밖에 없는 이유가 있습니다. 기획팀, 디자인팀, 개발팀이 나뉜 회사들은 그때 그때 프로젝트가 있을 때마다 기획자가 디자이너와 개발자 '리소스'를 받아서 프로젝트에 돌입하는 식으로 일합니다. 프로젝트가 끝나면 이 '리소스'들은 흩어집니다. 데이터를 확인하고, 고객 피드백을 받아서 이터레이션(iteration)을 하는 것은 꿈도 못꾸죠.
반면 PM/PO, 엔지니어, 디자이너가 한 팀에서 일하는 (흔히 '스쿼드' 또는 '목적 조직'이라고 알려진) 조직 구조를 가진 회사에서는 현대적인 의미의 Product Management를 할 수 있는 확률이 높습니다. 한국에서는 '신식 문물'이라 할 수 있는 조직 구조를 택했다는 것 자체가 그 회사가 지향하는 바를 보여주니까요.
17. 제일 중요한 건 실제로 어떻게 일하는지 보는 것
하지만 채용 공고도, 공식적인 조직 구조도 100% 진실을 말하지는 않습니다. 채용 공고는 다른 회사의 것을 적당히 베껴서 미사여구를 늘어놓기만 한 경우도 많고, 공식적인 조직 구조 역시 유명무실한 경우가 많으니까요. 제일 중요한 건, 실제로 어떻게 일하는지 보는 것입니다.
이를 위해 구직자 입장에서 할 수 있는 최선은 면접에서 회사에 구체적으로 물어보는 것입니다. 가장 최근에 제품 조직이 무엇을 만들었는지, 그걸 왜 했는지, 어떤 가설을 가지고 시작했는지, 가설 검증 계획을 어떻게 세웠는지, 누가 어떻게 의사결정했는지, 기능을 만든 다음에 이터레이션은 어떻게 했는지, 데이터와 고객 피드백을 어떻게 활용했는지 등등 자세하게 질문하는 거죠. 채용 공고에서는 거짓말을 하기 쉽지만, 구체적인 사례를 가지고 파고들며 질문하면 거짓으로 답변하기 어렵습니다. 현대적인 Product Management를 하고 있는지, 아니면 주먹구구식으로 일하는지 알 수 있습니다.
안내: <시작하는 PM/PO들에게 알려주고 싶은 모든 것>
현대적인 Product Management 관련해서 더 많은 내용을 <시작하는 PM/PO들에게 알려주고 싶은 모든 것> 강의에서 만나실 수 있습니다. 가설 설정과 검증, 데이터 활용, 고객 피드백 활용과 이터레이션 같이 추상적으로 느껴지는 개념들을 차근차근, 손에 잡히도록 설명해 드립니다.
Member discussion