Search
🍁

프로덕트 오너 - 김성한

published
2021/09/16
pinned
subtitle
고객이 열광하는 서비스는 어떻게 만들어지는가?
장르
비즈니스
기획
자기계발
author
김성한
이미지 출처: yes24

PM과 PO의 차이

나는 PM Product Manager, PO Product Owner라는 단어를 스타트업에 입사해 처음 들었고, 이 책을 보기 전까지도 두 직책의 차이를 알지 못했다. PO라는 말을 들었을 때 'PM이랑 비슷한 건가요?'라고 물었던 기억이 난다. 이전 직장에서는 PM이 팀을 이끌었고, 현 직장에서는 PO가 팀을 이끌고 있다. 지금 와서 PM과 PO가 맡은 역할을 생각해보니 엄연히 다른 것이었음을 실감한다.
간단히 말하면 PM은 이미 짜여진 계획 안에서 그 계획을 '실행하는 사람'이고, PO는 서비스 개발을 '계획하고 관리하는 사람'을 말한다. 팀이 PM 중심인지, PO 중심인지는 조직의 특성과도 연관되어 있다.
실리콘 밸리에서는 조직의 종류를 '위계 중심 조직'과 '역할 중심 조직'으로 나눈다. 위계 중심 조직은 경영진, 특정 부서 등 윗사람들에 의해 의사결정이 이루어지는 조직이고 역할 조직은 각 구성원에게 의사결정 권한이 있는 조직이다. 이전 직장은 경영진의 대부분의 의사결정 권한을 가진 위계 중심 회사에 가까웠는데 그래서인지 팀을 이끄는 직책의 이름이 PO가 아니라 PM이었던 것 같다.
반면 PO는 미니 CEO라고 불리우기도 한다. 그 이유는 서비스의 방향성, 출시 계획, 개발 원칙 등 서비스 개발에 대한 전반적인 계획을 PO가 책임지기 때문이다. 특정 인물들에게 서비스 개발에 대한 의사 결정 권한이 집중되어 있는 위계 중심 조직의 경우 PO는 본인의 역할을 제대로 수행하기 힘들다. PO가 제대로 일을 수행하려면 그만한 의사결정 권한과 책임을 위임해야 한다.

PO가 하는 일

권한과 책임을 위임받은 PO는 할 일이 많다. 어떤 기능을 개발할 지, 그리고 언제까지 출시할 지, 협력할만 한 단체나 기업 및 유관부서가 있는지 등을 고려하고, 또 주어진 시간 내 한정된 자원을 효과적으로 사용하기 위한 우선순위까지 정해야 한다. 책에도 나와있지만 어떤 날은 5분마다 통화를 할 정도로 커뮤니케이션이 잦다. 또 대화하면서 요청받은 요구사항, 해야할 일들을 빠짐없이 기록하고 필요한 것들만 필터링해야 한다.
PO가 하는 일을 보고 PO는 전쟁터의 전략가와 비슷하다는 생각이 들었다. 대학교 전공 강의 중에 '전략적 기획'이라는 강의가 있었다. 교수님이 '전략'의 정의가 무엇이냐고 물었을 때 당황스러웠던 기억이 난다. 자주 쓰는 단어지만 깊이 생각해본 적이 없기 때문이다. 계획하는 일? 전쟁에서 적을 이기기 위해 쓰이는 계획? 사람마다 정의는 다르겠지만 교수님이 말씀해주신 전략의 정의는 신선했다.
전략은 '포기하는 것'이다. 더 풀어서 설명하면, 전략이란 '목표를 이루기 위해 한정된 자원을 효율적으로 사용하고 그에 따라 필요없는 것을 포기하는 일'이라고 정의한다. PO는 목표를 정하고 목표를 이루기 위해 우선순위를 정한다. 그리고 목표를 이루는 일에 필요없는 일은 과감히 포기한다. 이상적으로 PO가 하는 일은 전략적이다.

PO가 없어진다면 을매나 무서울까

PO가 없는 팀은 무저갱으로 빠지기 쉽다. 이전 직장에서 맡았던 프로젝트에서 PO 역할을 하시던 분(PO는 아니었다)이 그만두시자 팀 전체가 무엇을 해야할지 어떻게 해야할지 혼란에 빠진 적이 있었다. 우리 나름대로 무엇을 할지 많이 고민해봤지만 갈피를 못잡아 방황했었다.
항해사가 있는 배와 선원들만 있는 배는 항로가 다르다는 사실을 인정할 수 밖에 없었다. 새로운 PM분이 오시자 방향성은 다시 잡히고 팀내 사기도 함께 올라갔다. 아무리 뛰어난 기획자나 메이커가 있어도 방향을 잡아줄 사람이 없다면 잘 굴러갈 수 없는 것 같다.

PO는 아니지만 PO를 읽은 이유

이 책은 PO가 무슨 일을 하고 얼마나 대단한 일을 하는지만 느끼려고 읽는 것은 아니다. PO가 아니더라도 기획자든 디자이너든 개발자든 서비스를 만든다면 PO의 관점으로 자신의 일을 해야한다. 이 책의 중간에서 데이터 과학자가 업무 시간 외에도 자신의 시간을 할애하여 서비스 데이터를 분석했지만 PO 입장에서는 실질적으로 액션을 끌어내는 데이터가 아니어서 아까운 리소스 낭비를 하게 되었다는 예시가 나온다.
내가 프로덕트 오너라면 나라는 자원을 어떻게 활용할까? 라는 질문을 자문해보면 자신이 어떤 일을 우선으로 할지, 어떻게 일해야할지 서비스에 도움이 되는지 생각해볼 수 있다. PO의 관점에서 바라보는 것은 우리 팀의 목표를 이루는 데 초점을 맞춘다는 것과 같은 의미이다.
메이커 관점에서 보면 이 책을 읽는 것은 단순히 PO의 일을 이해하는 데만 그치지 않고 어떻게 해야 PO가 인정할만 한, 서비스에 도움이 되는 일을 할 수 있을까 생각해볼 수 있는 계기가 된다. 하고 싶은 일이 있어 PO를 설득해야 할 일이 있어도 이 책을 읽는 게 도움이 될 것이다.
솔직히 말해서 책은 재밌지 않았지만(남들은 재밌다던데) PM과 PO의 차이, 그리고 PO가 무슨 일을 하는지, PO가 왜 그렇게 바쁜지 이해할 수 있게 됐다. 개발자로서는 기술력을 갖추는 것도 매우 중요하지만 기술력에만 초점을 맞추기보다는 내가 프로덕트 오너라는 생각으로 나 자신의 시간을 어디에 쏟을지 판단하는 데 도움이 될 것 같다.