프로덕트 오너 vs 프로덕트 매니저
Warning.
100% K-반도 패치된 관점으로 작성된 글입니다.
0.
프로덕트 관련 채용 공고를 검색하다보면 이름이 엇비슷한 포지션들을 많이 발견할 수 있습니다.
대표적으로 이런 것들이죠.
프로덕트 오너, 프로덕트 매니저, 프로젝트 매니저, 서비스기획자.
뭐가 같고, 뭐가 다를까요. 그간 많이 궁금하셨죠?
네, 사실 저도 8년간 답을 찾고있던 질문입니다. 여러분이나 저나 똑같습니다.
다만 이렇게 글을 쓰고자 글쓰기 버튼을 눌렀으니 손가락을 째려보며 제가 아는 범위 내에서, 'k-한국 패치'를 심하게 받은 내용으로 적어보겠습니다.
논쟁의 여지가 분명한 항목이며, 사람마다 뷰가 다르기 때문에 제 개인적인 관점이 상당히 많이 가미되었다는 것을 분명하게 미리 말씀드립니다. 그렇기 때문에 비난은 비난하겠습니다.
1.
프로덕트 오너(Produt Owner)와 프로덕트 매니저(Product Manager)를 비교하겠습니다.
'세종대왕의 얼을 기억하며 가나다순입니다' 라고 쓰려는 찰나 '서비스기획자'가 생각나네요.
필터 정렬 기능이 오류났으니 이제 저도 모르겠습니다.
아무튼 기본적으로 두 포지션 모두, 태생적인 철학은 같습니다.
Product에 대한 오너쉽을 바탕으로, 담당하는 Product의 생애주기를 관리하고 지속 개선하면서 성장을 시키는 것이 목적입니다.
쉽게 말해서 담당 Product 전략 짜고, 서비스 기획하고, 출시하는 것입니다.
로켓 배송, 새벽배송, 라이브커머스 만들어야한다! 하면 신규 서비스 출시 하고,
고객들이 '이것도 넣어주세요~' 했을 때 진짜 필요한 기능이다 싶으면 서비스 개발 결정하고,
'이 버튼 개선하면 효과 좋을 것 같은데?' 생각 들면 화면 개선해서 서비스 효율 늘리고
뭐 그런 것들 있잖습니까?
2.
다만 두 포지션에 대해 차이를 기어이 찾아내보자면 서비스 개발 프로세스를 바라보는 관점과, 구성원과의 역학 관계입니다.
전통적으로 한국의 대기업은 수직적인 구조가 강했습니다. 업무는 탑다운으로 내려왔고, 그 내용을 기획자(PM) 가 받아서 모든 기획을 마치고 나서 개발자와 디자이너에게 오더(지시)하는 구조였습니다.
속된말로 '까라면 까'였었죠. 개발자가 자주듣던 소리는 '쟤들은 하는데 너는 왜 못해?' 였습니다. 자연스럽게 탑레벨 - PM - 디자이너/개발자 간 수직적인 구조가 생성되어버립니다.
이렇게 수직적인 구조로 프로젝트가 진행되는 것을, 워터플 프로젝트 방법론이라고 부릅니다.
워터풀 프로세스를 한 번 따라가볼까요?
우선 기획자(PO, PM)은 출시할 서비스에 대한 모든 기획을 진행합니다.
기획이 100% 완료 되면, 기획서는 디자이너에게 넘어갑니다.
기획서를 바탕으로 디자이너가 모든 디자인을 완료하면 그 산출물이 개발자에게 넘어갑니다.
이 상태에서 모든 개발이 완벽하게 끝나면 아주 멋있는 엔딩이겠죠.
그러나 실상은 그렇게 녹녹하지 않습니다.
기획이 진행되는동안, 디자인이 진행되는 동안, 개발이 진행되는 동안 트렌드는 바뀌고, 내부 의사결정에 의해 서비스 방향성이나 상세 기능이 바뀌어버리는 것입니다.
그럼 어떻게 해야할까요?
네 처음부터 모든 기획을 다시합니다.
기획을 다하면 디자인을 하고 디자인이 다 되면 개발이되고,,,, 산고의 시간을 거쳐 어찌어찌 개발자가 도망가기전에 서비스가 출시되는 것입니다.
수없이 기획과 디자인을 바꾸어가며 서비스를 출시하니 두 가지 문제점이 보입니다.
바로 고객의 무시와 인력비용입니다.
애초에 이 서비스는 고객에게 인기를 쓸만한 서비스가 아니었습니다. 그런데도 이 서비스를 출시하는 동안 수많은 비용이 발생한것이죠. 우리는 모든 기능, 구상한 서비스의 완전체를 만들기 위해 오랜 시간을 소비하며 갈렸는데, 정작 시장에선 서비스에 대한 관심이 하나도 없었던 것입니다.
"망한거죠."
이처럼 워터풀은 기획에 있어서 의사결정이 아주 빠르다는 것이 장점이지만, 단점도 아주 명확합니다.
수직적인 구조를 유지해야하며, 서비스 스펙의 100% 전체를 개발하여 출시하기 때문에 서비스에 대한 시장의 관심과 성공 정도를 판단할 수가 없다는 것입니다.
3.
인간은 학습하고 경험을 통해 배우는 존재입니다.
워터풀의 장단점, 워터풀 무용론, 새로운 영웅의 등장!!!!을 시장에서 원하고있었고
이 쯔음해서 드디어 시장에 새로운 '히어로'가 등장합니다.
100% 스펙 다 개발하고 시장에 내놓았는데 시장 선택을 못받을 수도 있으니, 애초에 모든 기능을 다 넣어서 개발하지말고 '출시 할 수 있는 최소한의 기능만 넣은 서비스'를 출시하자! 는 개념입니다.
여러분들이 귀동냥으로 닳고 닳게 들었던 'MVP(Minamal Viable Product, 최소기능 제품)'가 탄생했습니다.
커머스 앱을 만들어본다고 가정해볼까요?
커머스앱을 출시하고싶으면 우리의 뇌에 있는, 뇌내망상 하고있는 부가적인 기능 다 빼고, 커머스를 가능하게 하는 최소한의 기능만 넣어서 시장에 출시해보는 것입니다.
최소기능을 넣으니 개발기간이 짧아지고, 빠르게 출시하고, 고객 피드백을 반영하여 빠르게 기능을 업데이트 할 수 있으니 가볍고, 날렵합니다. 물론 시장 실패를 받더라도 투입 비용이 적기 때문에 빠른 포기도 가능합니다.
즉, 100% 완벽한 제품을 만들어 출시하는 것보다 리스크가 아주 적은 것입니다.
엄청나지 않습니까? 상대 적진으로 돌격할 때 만렙 공대장을 앞장세우는 것이 아니라, 정찰별 한번 돌리는겁니다. 내가 이길 수 있을지 없을지.
'왜 맨날 검은색 티셔츠만 입냐는' 질문을 받은 마크 주커버그의 페이스북이 그렇습니다.
페이스북의 초창기는 '담벼락' 밖에 없었으며, 인스타그램의 첫 제품은 '사진 올리기' 기능밖에 없었습니다. 페이스북의 MVP 버전은 담벼락이었던거죠. 물론 당시 주커버그가 MVP를 고려해서 최소한의 제품을 시장에 먼저 내놓은 것은 아니었을겁니다. 단지 빠르게 개발할 수 있었으니까 그렇겠지만 그 마인드 자체가 이미 MVP였다고 생각됩니다.
그러나 지금은 어떤가요? 페이스북은 고객들에게 홀리스틱한 시장 선택을 받았고, 이 서비스가 고객에게 사랑 받는다는 것을 확인했으니 수많은 추가 기능이 더해지며 지금의 페이스북과 인스타그램이 된 것입니다.
4.
최소기능제품과 떨어질래야 떨어질 수 없는 IT영역 단어들이 몇 가지 있습니다.
애자일 프로세스, 린 스타트업, 그리고 프로덕트 오너입니다.
모두 같은 맥락을 공유하는 단어입니다.
이런 맥락말이죠.
'움직이게만 만들었으면, 일단 출시하고보자.'
길게 좀 늘여보면 이렇지 않을까요?
'우리가 만든 서비스가 시장에서 선택받을지 외면을 받을지 모르니 첫 출시에 모든 서비스를 다 넣어서 개발기간 길게 갖고 가지말고, 최소한으로 제품 스펙을 만들어 빠르게 출시하고 고객 피드백 받고 또 일부 기능 추가해서 빠르게 출시하고 고객 피드백 받으며 개선해나아가자!'
서비스의 모든 스펙을 다~ 기획/디자인/개발해서 수식적인 구조로 프로젝트를 진행하는 것이 워터플 방법론이라면, 짧게 짧게 기민하게 끊어서 서비스를 출시하는 것이 바로 '애자일 프로세스'입니다.
그리고 애자일 프로세스에서 프로덕트를 담당하는 사람을 '프로덕트 오너(Product Owner)'라고 부릅니다.
(k-반도 패치 이후엔 많은 것이 변했지만,,,)
5.
이제는 왜 제가 글의 처음에, 프로덕트 매니저와 프로덕트 오너의 기본 철학은 같다고 말씀드렸는지 이해 하셨을 것입니다.
단지 프로덕트를 바라보는 관점과 구성원과의 관계, 그리고 개발 프로세스가 다를 뿐입니다.
이로인해 똑같은 네카라쿠배 토당야직크 인데 어떤 회사에서는 프로덕트 매니저라 부르고, 어떤 회사에서는 프로덕트 오너라 부릅니다. 물론 어느 회사는 '서비스기획자'라고 부르고 말이죠.
(실제 업무가 다른 곳도 존재합니다 물론)
그러나 대기업이든 스타트업이든 두 포지션 모두 '프로덕트'의 성장을 목표로 하고있다!' 다는 것은 다르지 않습니다.
그렇다면 이제 이런 질문을 하시는 분들이 등장할 것입니다.
나는 PM이 맞아요? 아니면 PO가 맞아요?
저도 잘 모르겠습니다.
한국에선 프로턱트 관련된 포지션 명에 대한 명확한 구분이 없고, 회사마다 동일 업무를 다른 포지션으로 부르기도하고 다른 업무를 같은 포지션으로 부르기도하기 때문입니다. 포지션을 구하는 구직자 관점에선 '포지션명' 보다는 '주요 수행 업무'를 보시는 것을 추천드립니다.
오늘은 프로덕트 오너와 프로덕트 매니저의 차이를 프로덕트 개발 방법론 관점에서 알아보았습니다. 다음엔 어떤 내용이 이어질지 두근두근 기대해주시며, 오늘은 이만. 끝.
