PM과 PO는 무슨 차이일까요?
'프로덕트 매니지먼트'를 읽고
이번 글은 <프로덕트 매니지먼트>라는 책의 내용을 다루고 있습니다.
요즘 들어 '프로덕트 매니저'라는 직무에 흥미가 생겨서 가능한 많은 PM 관련 서적을 읽고 있다. 그중에서 <프로덕트 매니지먼트>라는 책을 읽으면서 개인적으로 이 책이 가장 심도 있는 인사이트를 제공하는 서적인 것 같다는 생각이 들었다. 그래서 주변 지인들에게 꾸준히 이 책을 추천하고 있다. 혹시 이 글을 읽고 있는 분들 중에 프로덕트 매니저로의 진로를 고민하고 있다면, 꼭 이 책을 읽어보길 추천하고 싶다. (이 책과 함께 <성장하는 PM을 위한 프로덕트 매니저 가이드>라는 책도 추천한다.)
00.
이 글을 쓰는 이유
IT 업계에서는 하나의 프로덕트를 만들기 위해 무수히 많은 직무가 존재한다. 프로덕트 매니저, 프로젝트 매니저, 프로그램 매니저 (PM이라는 약어를 가진 직무만 세 가지가 존재한다.) 이외에도 프로덕트 오너, 프로덕트 디자이너, UX 디자이너 등 나열하는 것이 불가할 정도로 다양한 직무가 있다. 하지만, 이러한 직무들은 회사마다 존재 여부가 다를 수 있으며, 어떤 경우에는 한 사람이 2가지 직무를 동시에 수행하게 될 수도 있다. 이처럼, 조직마다 정의하고 있는 직무의 역할이 서로 다르기에, 관련 내용을 정리하는 것이 적절한지에 대한 고민을 하기도 했지만, 이 책에서 직무의 역할을 매우 명확하게 정의해 주고 있으며, 직무 전환을 고민하고 있는 나에게도 직무 관련 내용을 정리해 보는 것이 좋을 것 같다고 생각하여 글 작성을 시작해 보려고 한다. 이번 글에서는 프로덕트 매니저, 프로젝트 매니저, 프로그램 매니저, 프로덕트 오너, 총 4가지 직무를 서로 비교하며 다뤄볼 예정이다.
01.
프로덕트 매니저 vs 프로젝트 매니저
우선, 프로덕트 매니저와 프로젝트 매니저의 차이에 대해 알아보자. 이미 많은 사람들이 이 두 직무의 차이를 어느 정도 이해하고 있을 것으로 예상하고 있다. 결국 두 직무 모두 어떤 것을 매니징(관리)하는 것인데, 매니징을 하는 대상이 서로 다르다고 이해하면 될 것 같다. 프로덕트 매니저는 '제품'을 관리한다. 제품이 고객에게 지속적으로 좋은 가치를 제공할 수 있도록 고민하며, 제품의 목적과 가치에 대해 고민하고 결정하는 역할을 수행한다. 반면에 프로젝트 매니저는 '프로젝트'를 관리한다. 프로젝트의 시작과 끝이 원활하게 흘러가도록 고민하며, 프로젝트에 투입될 리소스(시간, 인력, 비용)를 고민하고 결정하는 역할을 한다. 아래에 두 직무가 해야 할 구체적인 사항을 정리해 두었다.
(1) 프로덕트 매니저
한마디로 프로덕트의 성공과 실패를 책임지는 사람
- 제품의 비전과 전략 수립
- 전반적인 제품 로드맵 작성
- 고객 요청 수렴
- 큰 틀에서 우선순위 고민 후 결정
- 비즈니스의 성공을 측정할 수 있는 지표 설정
- 경쟁 제품 분석
(2) 프로젝트 매니저
한마디로 프로젝트의 시작과 종료를 책임지는 사람
- 프로젝트 타임라인 관리 (WBS)
- 프로젝트 리소스(시간, 인원, 비용) 관리
- 리소스를 언제 어떻게 효과적으로 투입할지 고민
- 그 외 다양한 관리 (위험 관리, 자원 관리 등)
프로덕트 매니저와 프로젝트 매니저에 대한 글을 읽으면서 아래와 같은 생각을 했을 것 같다.
"그러면 프로덕트 매니저랑 프로덕트 오너의 차이가 뭐지?", "프로덕트 매니저의 역할이 내가 생각하고 있던 프로덕트 오너인데?"
나 역시 이 책을 읽기 전까지 그렇게 생각했었다. 물론, 또 말하지만, 직무의 역할은 회사마다 차이가 있기 때문에 절대적인 정답은 없다. 하지만, 아래의 그림을 보면 프로덕트 매니저와 프로덕트 오너의 차이를 이해하는 데 도움이 될 것이다.
02.
프로덕트 매니저 vs 프로덕트 오너
프로덕트 디스커버리와 프로덕트 딜리버리그림을 보면 알 수 있듯이, 프로덕트 매니저는 프로덕트 오너보다 상위의 전략을 수립하는 역할을 한다. 프로덕트 매니저는 프로덕트 디스커버리(문제 발견)를 담당하며, 최대한 여러 관점의 아이디어와 데이터를 수집하고, 프로덕트 미션과 비전에 부합하는 아이디어를 선택하는 데 집중한다. 그리고 선택된 아이디어에 우선순위를 부여한다. 이후, 프로덕트 오너는 부여된 우선순위를 바탕으로 타임라인에 맞춰 프로덕트를 고객에게 딜러버리(전달)하는 역할을 수행한다. 간단히 말해, 프로덕트 매니저는 문제를 발견하고 아이디어를 선별하는 데 중점을 두고, 프로덕트 오너는 이러한 아이디어를 구현하고 고객에게 전달하는 데 주력한다. 더 나아가, 프로덕트 오너는 아이디어를 구체화하여 에픽과 사용자 스토리를 작성하며, 프로덕트 개발에 적극적으로 참여한다.
프로덕트 매니저와 프로덕트 오너의 역할 구분은 '프로덕트 구체화 과정'에서도 확인할 수 있다.
소프트웨어 프로덕트 구체화 과정프로덕트 구체화 과정은 미션, 비전, 전략, 전술 총 네 단계로 이루어져 있다. 이번 기회에 이 네 단계를 금융 서비스 '토스'를 예시로 사용하여 정리해 보려고 한다. (단순한 예시일 뿐이다.)
(1) 1단계인 미션은 프로덕트 리더십 그룹, 일명 그룹장들이 담당한다. 이 단계에서는 프로덕트가 고객에게 필요한 이유, 즉 '왜'에 집중해서 정의하는 작업을 진행한다. '토스'의 미션은 '기존의 복잡하고 불편했던 금융 서비스를 더 간편하고 사용자 친화적으로 개선하여 문제를 해결하기 위함'일 것이다.
(2) 그다음으로 2단계인 비전은 프로덕트 매니저가 맡게 된다. 비전 단계에서는 고객들이 우리 제품이 고객에게 어떤 모습으로 비쳤으면 좋을지 고민하고 설정하는 단계를 의미한다. '토스'의 비전은 모바일을 통해 간편하고 편리한 금융 거래를 통해 더 나은 미래 만들기'일 것이다. 이 단계에서 프로덕트 매니저는 동시에 제품의 로드맵을 수립해야 한다.
(3) 3단계인 전략 또한, 프로덕트 매니저가 맡게 된다. 비전 단계에서 정의한 제품의 목표를 달성하기 위해 어떤 전략을 펼칠지 수립하는 단계이다. '토스'는 사용자들이 간편하게 이용할 수 있는 디지털 금융 서비스를 제공하기 위해 결제, 송금, 대출 등 다양한 금융 상품을 빠르게 처리할 수 있는 전략을 수립할 것이다. 더불어 사용자 경험을 향상시키기 위해 직관적인 디자인을 제공하는 것도 전략의 일부로 포함할 것이다. 뿐만 아니라, 금융 시장에서의 입지를 위해 기존 금융 기업들(예 : 카카오뱅크, 국민은행, 하나은행 등)을 분석할 것이고, 가장 핵심이 되는 가치를 고객들에게 우선적으로 제공할 수 있도록 기능별 우선순위를 설정할 것이다. 초창기 '토스'를 떠올려 보면, '토스'는 '간편하고 신속한 송금'에 집중했던 것으로 기억한다. 이 단계에서는 또한 비즈니스의 성공을 측정할 수 있는 구체적인 지표도 설정할 것이다.
(4) 마지막으로 4단계인 전술은 프로덕트 오너의 역할이다. 수립한 전략을 기반으로 아이디어를 실제로 구현하고 고객에게 가치를 빠르게 전달하는 역할을 하는 단계이다. '토스'는 사용자들이 간편하게 이용할 수 있도록 뎁스를 최소화하고, 복잡한 금융 정보를 쉽게 이해할 수 있도록 단계별로 정보를 제공할 것이다. 또한, 사용성을 높이기 위해 가독성 좋은 폰트를 활용하거나, 어려운 용어를 사용자가 쉽게 이해할 수 있도록 UX Writing을 고민할 것이다.
toss를 예로 든다면?03.
또 다른 PM, 프로그램 매니저
프로덕트 매니저와 프로젝트 매니저 외에도 또 다른 PM이 존재한다. 바로 프로그램 매니저이다. 나도 이 직무에 대해서는 이 책을 통해 처음 들어보게 되었는데, 아마도 한국에서는 많이 알려지지 않은 직군인 것 같다. 그도 그럴 것이, 프로그램 매니저는 공통으로 탑재돼 동작하는 기능을 관리하는 책임자이다. '공통으로 탑재돼 동작하는 기능'은 마이크로소프트의 제품을 통해 쉽게 이해할 수 있을 것이다. 많은 사람이 사용하고 있는 워드, 엑셀, 파워포인트에는 공통으로 탑재된 기능들이 존재한다. Ctrl+S를 누르면 파일이 저장되고, Ctrl+C와 Ctrl+V를 누르면 항목이 복사, 붙여넣기가 된다. 이렇게 다수의 제품에서 공통으로 사용하고 있는 기능들을 관리하는 역할이 바로 프로그램 매니저의 역할이다. 비슷한 맥락으로, 여러 제품을 보유한 회사에서 동일한 결제 시스템을 사용하게 될 텐데, 이도 유사한 예가 될 수 있다.
(왼쪽부터) Word, Excel, PowerPoint이 글은 <프로덕트 매니지먼트>라는 책의 내용을 다루고 있다.
