프로덕트 매니저와 프로덕트 오너는 무엇이 다른가요?
PM과 PO가 무엇이 어떻게 왜 다른지를 차근 차근 설명해 드립니다.
정확한 이해를 위해 필요한 두가지
비트겐슈타인은 “내가 사용하는 언어의 한계가 내가 사는 세상의 한계를 규정한다”라고 합니다.
칵테일파티처럼 여러사람의 목소리와 잡음이 많은 상황에서도 자신이 듣고자 하는 이야기는 선택적으로 잘 들을 수 있다는 ‘칵테일파티 효과’ 라는 심리적 현상도 있습니다.
사람들을 만나고 대화를 나누는 도중에 새로운 단어나 표현법을 접했을 때 그것을 다루는 첫 해석은 내가 이미 가진 지식베이스에 내 관심도를 합친 결과로 순간 입력이 됩니다. 그리고 입력된 상태에서 추후에 전문가의 설명, 매체나 책을 통하여 그 정의에 대한 정확한 개념을 잡아가지만, 첫 입력된 값을 수정하는 것은 매우 큰 노력이 필요한 과정입니다. 그렇기에 처음 새로운 단어나 표현을 접할 때 그것에 매핑되는 정확한 개념을 갖는 것은 매우 생산 효율적입니다.
많은 기업에서 PM이란 말은 예전부터 매우 널리 사용되어 왔습니다. 대부분이 특정 프로젝트의 기간과 비용을 관리 운영하는 프로젝트 매니저라는 역할을 수행하는 분들을 통칭하여 사용해 왔죠. 그러다 보니 프로덕트 매니저 혹은 프로그램 매니저라는 직군이 모두 PM으로 소개되어질 때 많은 혼란과 오해가 있어 왔던 것이 사실입니다. 프로덕트 매니지먼트를 설명하는 것 역시 쉽지 않은데 그 모호성은 바로 프로덕트의 다양성에 기인합니다. 실제로 프로덕트 매니저의 역할과 책임은 회사마다 다릅니다. 어떤 회사에서 프로덕트 매니저로서 한 가지 책임이 있다면, 회사 및 산업 규모에 따라 다른 회사에서는 완전히 다른 책임을 맡게 될 수도 있습니다. 이런 많은 혼란 가운데서도 소프트웨어 산업에서는 시간이 지나며, 프로젝트, 프로그램, 프로덕트의 개념을 구분 설명하고 ( 저의 다른 글을 참조해 주시면 감사하겠습니다.) 교육되면서 이 PM 간의 구분이 점차 명확해지고 있습니다. 그 무렵 프로덕트 오너 PO라는 또 다른 직군명이 등장하며, 지금까지 이해되고 있던 프로덕트 매니저의 역할에 대한 이해와 충돌합니다.
오늘은 그 프로덕트 매니저와 프로덕트 오너가 어떻게 왜 다른가를 설명드릴까 합니다. 개념이 혼란을 가지셨던 분들은 오늘로 마무리를 하실 수 있도록 최대한 설명을 쉽고 체계적으로 해 볼까 합니다.
이것을 위해서는 어렵지 않은 큰 개념 두 가지를 이해하시면 완전 정복할 수 있고, 더 이상 혼란도 생기지 않습니다.
첫 번째는 프로덕트가 어떻게 설계되고 만들어지는지에 과정에 대한 큰 개괄적인 이해입니다.
두 번째는 그것을 만드는 조직의 구성을 이해하시면 됩니다.
소프트웨어 프로덕트는 어떻게 구체화되는가?
모든 소프트웨어 프로덕트/서비스는 다음과 같은 4단계를 거치면서 구체화됩니다. 첫 번째 미션과 두 번째 비전은 프로덕트를 처음 만드는가, 프로덕트 개선을 하는가에 따라서 미션이 먼저 올 수도 비전이 먼저 올 수도 있습니다.
1. 미션(Mission): 왜(Why?)에 관한 것을 답해주는 것입니다. 즉 이 프로덕트가 존재해야 하는 목적을 설명합니다. 그러다 보니 당연히 프로덕트 그룹의 리더십팀이나 그룹장에 의해서 설정이 됩니다.
2. 비전(Vision): 이 프로덕트를 사용할 때 고객이 어떤 혜택을 보겠는가를 기술하게 됩니다. 이 내용이 구체화되어야 제품 로드맵을 작성할 수 있습니다. 프로덕트 매니저의 역할입니다.
3. 전략(Strategy): 프로덕트 매니저가 가장 중점적으로 일을 해야 하는 과정입니다. 시장을 분석하고, 테마 기능별 우선순위를 정하고, 프로덕트 성공에 관한 지표를 설정하는 과정입니다.
4. 전술(Tactics): 실제 프로덕트를 만드는 과정에 해당합니다. 프로덕트를 완성하기 위한 백로그 아이템을 만들고, 기능별 릴리즈 플래닝을 세우고 진행합니다. 프로덕트 오너라는 직군이 존재한다면 이 과정을 담당합니다.
그림1. 소프트웨어 프로덕트를 구체화시켜가는 과정이 과정을 조금 다른 각도, 관점에서 보면 다음 그림 2과 같이 나타납니다. 순서대로 설명을 드려볼까 합니다.
그림 2. 기능테마 컴포넌트, 로드맵, 릴리즈플랜① 비즈니스의 목표과 프로덕트 비전이 나오고 프로덕트가 갖추어야 할 기능 테마(예: 소셜 미디어 연계, UX 개선-revamp, 서버 성능 개선, I18N-국제화 대응 등…)가 결정 나는 데 필요한 과정을 ‘컴포넌트’로 규정합니다.
② 컴포넌트를 모두 모아서 최종 결과를 만들어 내는 것은 실제 프로덕트를 어떤 방향으로 내 보낼 것인가라는 청사진 즉 ‘프로덕트 로드맵’이 됩니다.
③ 그 로드맵에서 규정된 한 시기의 묶음을 잡아 프로젝트나 릴리즈 이름을 붙여(예: 2021년 10월 릴리즈를 버전 2.0으로 한다.) 진행을 하죠. 모든 상황을 다 조사해서 할 수 있는 것들과 필요한 것들을 구분하면서 펼쳐놓으면 그중에서 함께 할 수 있는 것들을 묶을 수 있습니다. 그것을 프로젝트나 릴리즈라고 이름 붙여 프로덕트/서비스를 내는 과정입니다.
방대하고 여러 가지 축에서 오는 수많은 정보를 모아서 분류했다가 그 분류 중에 한 묶음만 딱 빼네는 그런 느낌을 받으시나요? 여기까지 이해를 하셨다면 오늘의 주제 PM와 PO의 구분은 고개 반을 넘었습니다.
프로덕트 그룹의 조직을 이해하자.
소프트웨어 전문 기업 조직이 어떻게 운영되는 지를 이해하는 것은 프로덕트가 어떻게 만들어지는지에 대해서 이해를 가장 빨리 할 수 있는 방법입니다. 물론 그 기업의 사이즈와 프로덕트 라인에 따라 다르겠지만, 제가 소개하는 아래 그림의 예는 일반적인 글로벌 소프트웨어 기업의 프로덕트 라이프 사이클을 전체적으로 책임지는 엔지니어링 그룹을 설명합니다.
그림 3 일반적인 엔지니어링 그룹 구조톰을 그룹장으로 CRM on Cloud라는 프로덕트를 만드는 엔지니어링 그룹입니다. 그림에서 보다시피, 개발팀, 딜리버리팀, 디자인팀 외에도 프로덕트매니지먼트팀, Go-to-Market팀등이 같은 급에서 업무를 하게 됩니다. 어디에도 프로덕트 오너 팀은 보이지 않네요. 답은 잠시 후에 드릴게요. 위에서 설명드린 프로덕트 구체화 과정을 다시 한번 되짚어 봅니다.
1. 프로덕트 미션은 그룹장인 톰을 중심으로 각 기능 별 팀장을 중심으로 하는 리더십팀을 통해 하이 레벨의 비즈니스 목표와 매우 러프한 수준의 우선순위가 만들어집니다.
2. 그 만들어진 결과물은 프로덕트 매니지먼트 팀에 다음 구체화 스텝으로 진행하라는 요청으로 전달되어 옵니다. 그럼 프로덕트 매니지먼트 팀은 어떻게 정보를 모으고 최종 결과물 로드맵을 만들어 내야 할까요?
3. 프로덕트 매니저들이 동원되는 시점이 됩니다. 그때부터 시장을 조사하고, (기존/잠재) 고객을 컨택하고, 경쟁자 제품을 조사하고, 애널리스트들과 회의를 하고, 또 가장 중요한 개발, 디자인, DevOps, QA 매니저들과 머리를 맞댑니다. 이런 일들을 하는 상황을 ‘프로덕트 디스커버리(Product Discovery)’라는 말을 사용하기도 합니다. 즉 디스커버리 과정이 필요해야 무엇을 딜리버리 할 수 있는지 알 수 있겠죠. 그리고 그 결과물이 프로덕트 스트레티지로 나오겠지요. 그 결과물에는 구체화된 우선순위, 타임라인, 성공 지표 등의 구체 사항이 정리된 위닝 플랜(winning plan)이 됩니다. 밑의 그림 4를 참고하세요.
4. 드디어 프로덕트 딜리버리를 책임지는 PO가 등장하는 시점이 됩니다. 그러나 여기에는 큰 조직과 작은 조직 간에 실행하는 방법이 조금 다를 수 있습니다. 작은 조직이라면, 두 번째, 세 번째를 담당했던 프로덕트 매니저 PM이 직접 백로그를 만들고, 기능과 릴리즈 플래닝을 작성하여 각 개발, 디자인, QA리더들과 함께 작업을 해 나가는 실제 스크럼 프로세스가 진행이 됩니다. 하지만 조금 큰 사이즈의 프로덕트라면 기능의 분류나 백로그를 만드는 일은 훨씬 더 구체화되는 과정이 더 필요할 겁니다. 전문 지식을 갖춘 프로덕트 전문가도 필요하고요. 프로덕트 디스커버리 단계를 지나 프로덕트 딜리버리를 위해 엔지니어링 그룹에서 개발, 디자인, 데브옵스 등 기능별로 실행(execution)이 될 때 그것을 진두지휘하는 역할을 PO라고 주로 합니다.
5. 위에서 설명드린 엔지니어링 팀 조직도에서 PO가 별도 조직으로 되어 있지 않은 까닭은 PO는 주로 기능(functional) 조직에 속하고 있기 때문입니다. 대부분의 PO는 개발이나 디자인팀에 속해서 맡은 기능이나 프로덕트의 릴리즈를 책임지게 됩니다. 같은 이유로 프로젝트 매니저나 스크럼 마스터 역시 별도의 조직이 아닌 주로 개발 조직에 속해서 특정 프로덕트의 특정 버전, 릴리즈의 타임라인을 관리하는 역할을 수행합니다.
그림 4. 프로덕트 디스커버리와 프로덕트 딜리버리여기까지 설명을 드리면 프로덕트 매니저 PM과 프로덕트 오너 PO의 차이점을 조금은 명확하게 이해하는데 도움이 되지 않았을까 기대를 해 봅니다.
핵심 마무리
오늘은 PM과 PO의 차이를 설명드리기 위해, 큰 틀에서 먼저, 소프트웨어 프로덕트/서비스가 어떻게 만들어지는지에 대한 설명으로 시작을 했고, 그것을 구현해내는 엔지니어링 조직에 대해서도 설명을 드렸습니다. PM과 PO의 정확한 구분은 기업마다, 그것을 사용하는 조직마다 조금씩 다를 수 있습니다. 즉 프로덕트 매니저와 프로덕트 오너는 해당 조직에서 그 역할을 가장 잘 표현하기 위해서 선택적 사용이 가능한 것일 뿐 어떤 고형화, 정형화된 개념을 주입하는 것은 더욱 혼란을 만들 수 있습니다.
그래도 오늘 말씀드린 프로덕트 매니저 PM과 프로덕트 오너 PO의 일반적인 역할 차이에 대해서 정리해 보겠습니다.
프로덕트 매니저 PM
전체적인 프로덕트 ‘디스커버리’를 책임지는 역할을 합니다. 올바른 문제에 집중하고 가장 가치 있는 아이디어를 구현하도록 합니다. 아이디어의 우선순위를 정하고, 제품 비전과 전략을 지침으로 사용하며, 어떤 아이디어가 가장 빨리 도달할 수 있는지를 ‘발견(Discovery)’하는 데 초점을 맞춥니다. 데이터 분석, 사용자 연구, 실험 등과 같은 방법을 사용하여 어떤 아이디어가 프로덕트에 귀중한 시간을 할애할 가치가 있는지 알아냅니다. 프로덕트 매니저는 제품 기능의 더 넓은 측면 (제품의 탄생, 유지 보수, EoS (End of Service), 고객에게 지속 가능한 가치 전달)에 대한 책임이 있고, 미래 가치 발견과 딜리버리 사이의 균형을 유지합니다. (전체적인 로드맵, 프로덕트 스트래티지, 프로덕트 플래닝, 우선 순위라는 말을 자주 접하게 됩니다.)
프로덕트 오너 PO
프로덕트나 특정 기능의 ‘딜리버리’를 책임집니다. 아이디어의 가치가 고객에게 최대한 빨리 전달되도록 합니다. 논의되고 결정된 결과에 대한 구현에 책임이 있습니다. 아이디어를 구현할 수 있는 에픽/유저 스토리를 만들고, 개발 과정을 각 기능팀과 함께 진행합니다. 프로덕트 매니저가 따로 존재하는 조직의 경우에는 프로덕트 매니저 또는 다른 비즈니스 라인 오너와 긴밀하게 협업합니다. (프로덕트 백로그, 스크럼, 유저 스토리라는 말을 빈번하게 접하게 됩니다.)
제 설명을 통해 여러분들이 갖고 계셨던 PM과 PO에 대한 의문점이 해소되었으면 좋겠습니다. 늘 노력하고 최선을 다하시는 여러분들을 진심으로 응원합니다. 고맙습니다.
