Product Owner 일의 무게중심을 찾아서
- PO가 집중해야 할 역할과 역량에 대해 고민하는 분
- 이제 막 서비스 기획자, PM, PO 커리어를 시작하는 분
- 조직 내에 합의되지 않은 PM-PO 직무 역할로 인해 혼란을 겪고 계신 분
약 4-5년 전부터 업계에서 PO라는 타이틀이 화두에 오르기 시작했다.
나 역시 그전까지는 서비스기획자-PM으로서 일하다가 4년여 전부터 PO라는 타이틀을 달고 일하기 시작했다. 시장과 조직이 무르익으며 요구되는 역량의 레이어가 복잡해지며 점점 더 역할이 세분화되기 시작한 것이다. 서비스기획자는 기획서를 치고, PM은 일정관리까지 하는 거 아니야?라는 이해가 더 이상 통용되지 않은 시점이 된 것이다.
그로부터 시간이 꽤 지난 지금은 많은 스타트업과 IT기업들이 Product Owner를 뽑고 있다. 이제는 PM과 PO가 무엇인지 묻는 질문이 많이 잦아들었다곤 하지만 공고의 내용들을 비교해 보면 서비스 기획자, PM, PO에서 각각 요구하는 역량이 무엇이 다른지 애매한 경우가 많다. 여전히 PO와 PM의 업무 구분은 '아는 사람만 아는' 지식이 아닐까 싶다.
국내에서는 대표적으로 토스가, 그리고 많은 해외 사례에서 PO와 PM의 차이점을 정의했다고 해도 내 동료, 내 대표님이 이것을 정확하게 이해하고 공감하여 나의 역할을 바라보고 있는지는 다른 문제다. 그렇기에 남들에게 설명하기에 앞서 내가 먼저 나의 해야 하는 일이 어디에 집중해야 하는 것인지 명료하게 이해하는 것이 중요하다.
이 글에서는 아래 사항들을 다루고, 각 역할 별 집중 성장시켜야 하는 역량에 대해서 생각한 바를 기록했다.
1. 제품을 만드는 이가 갖춰야 할 코어 역량
2. 코어 역량들에서 서비스기획자-PM-PO가 집중해야 하는 핵심
이 직무에서 요구하는 일은 결국 제품을 만들어 내는 일이다. 그래서 각 역할에서 힘을 줘야 하는 일을 꼽기에 앞서, 공통적으로 해야 하는 요소를 먼저 정의했다.
[요구사항 정의], [제품 매니징], [방향성 제시]
그리고 이것을 총체적으로 엮어내는 [커뮤니케이션]
다만 커뮤니케이션 역량은 서비스기획자-PM-PO에게 모두 동일하게 중요한 요소이기 때문에 각 역할의 차이점에 대해서 다루는 오늘 글에서는 이 역량을 별도로 언급하지 않도록 하겠다.
1) 요구사항 정의
고객의 문제점/니즈를 정확하게 이해하고 이를 구현할 수 있는 기능을 명료하게 기획하는 것.
문제없이 동작될 수 있 수 있도록 함. (정책정리, 개인정보보호법 준수 기타 등등)
소위 "짜임새 있는 서비스"를 만드는데 필요한 역량
필터를 어떤 형태로 구성하지?
이 페이지에서는 어떤 정보들을 넣을 것인가?
영향범위는 어디까지인가?
2) 제품 매니징
효율적으로 리소스를 분배하고 일정을 관리하는 것. 스펙의 우선순위 결정
다양한 이해관계자와 협업, 조직 내/외적으로 수집되는 니즈를 뾰족하게 하게 다듬음
다듬은 니즈를 적절한 순간에 실행할 수 있도록 계획
"교차로에서 교통정리를 잘" 할 수 있도록 하는 역량
우리가 당장 해야 하는 더 중요한 스펙은 무엇이지?
팀이 더 빠르게 더 효과적인 제품을 만들려면 어떻게 해야 하지?
어떤 실험들을 더 빠르게 해 볼 수 있을까?
3) 방향성 제시
더 큰 성장을 위한 북극성 제시
성과의 측정. 목표를 도달하기 위한 전략을 제시하고 과정을 점검.
프로젝트 우선순위 결정
우리 서비스가 볼륨을 키워야 하는 시기인가, 수익화에 집중해야 하는 시기인가?
이에 어떤 제품 로드맵이 필요한가?
북극성 지표에 변화가 필요한 시점인가?
그리고 정의한 이 일들에 대해 각 역할에서 가장 잘 해내야 하는 포인트가 다르게 나타난다.
1) 서비스 기획자 : 요구사항 정의
서비스 기획자의 주요 업무는 역시 '기획서를 작성하는 것'이다.
요구사항을 잘 정의하기 위해서는 문제가 무엇인지부터 명료화해야 한다. 문제를 명료하게 하려면 고객의 욕구, 제품/사업 전체의 방향성, 비전 등에 대해서 알아야 한다.
다른 역량들을 소홀히 해도 된다는 말은 아니다. 다만 이것을 이해하고 파악하여 꼼꼼히 엮어내 제품을 만들 수 있는 '기획서' 형태의 산출물을 도출하는 것이 이 역할에서 가장 기대하는 행동일 것이다.
서비스기획자를 오래 하신 분들의 포트폴리오를 보면 더없이 구조화되고 꼼꼼하여 마치 거미줄과 같은 기획서들을 만드는 데에 큰 장점이 있는 것을 볼 수 있었다.
2) PM : 제품/조직 매니징
여기서부터는 PO와 경계가 조금씩 모호해지기 시작하는 지점인데, 그럼에도 반드시 잘 해내야 하는 단 하나의 역량을 고르자면 "다양한 이해관계자의 의견을 조율해서, 효과적인 타이밍에 그 Task를 완료할 수 있도록 일정/리소스를 조율해 내는 것"이라고 할 수 있겠다. 조직 내/외적으로 들어오는 이슈들을 관리하고 적절한 타이밍에 해결될 수 있도록 이를 분배한다.
3) PO : 방향성 제시
PO는 더 이상 기획서를 꼼꼼하게 작성 잘하는 것으로는 '좋은 PO'로 인정받을 수 없다. 물론 잘한다면 좋은 역량이나, 기획서를 잘 쓰는 것이 더 이상 역할의 핵심 역량이 아니게 된 탓이다.
PO는 비즈니스 목표를 달성하는 제품을 우리가 만들고 있는지 끊임없이 묻고 답하는 역할이다. 가설을 던지고 검증하고 무너뜨린다. 출시한 제품이 성장에 어떻게 영향을 미쳤는지 점검하고, 우리 사업/제품이 스케일 업하기 위해 어떻게 해야 하는지 전략을 구상한다.
말로만 공허하게 할 순 없는 일이라 앞에서 언급한 두 역량이 단단한 기둥이 되어 그 위에 올라서야 비로소 의미를 가지는 역량이다.
cf. 해외 아티클들을 살펴보면 대부분 PM을 PO보다 더 거시적인 시야를 가진 역할로 정의하나 한국에서 통용되는 일반론은 그 반대인 듯하여 한국의 상황에 맞도록 글을 작성했다.
역할별로 집중해야 할 역량이 있다고 하면 나머지 부분들은 하지 않아도 될 것이라고 오해하기 쉽다.
그렇다면 PO는 기획서를 쓰지 않는가? 조직에 따라 다르겠지만 아마 대부분의 PO들이 여전히 어떠한 형태로든 기획서(혹은 요구사항 정의서)를 쓰고, 개발자/디자이너/QA가 잘 읽을 수 있는 Description을 달기 위해 애쓰고 있을 것이다.
서비스기획자는 일정을 관리하지 않는가? 나 역시 '기획자'라고 불리는 시절을 거쳤을 때 루틴한 회의들을 통해 일정들을 파악하고, 이해관계자들의 의견을 수집하는 시간을 가지며, 시간 내 완성도를 맞추는 제품을 만들어 내기 위해 타임라인 시트를 관리했다.
요컨대 일의 세 가지 요소는 분절적이지 않고 그라데이션의 형태를 취하고 있는 것이다.
좋은 제품을 만들기 위해서는 셋 모두를 신경 써야 한다. 하지만 모든 것에 똑같이 공평하게 시간과 노력을 투자하기에는 어려울뿐더러 이러한 방법이 효과적으로 일을 하는 것이라고 보기에도 어렵다.
종종 모든 것을 다 잘하기 위해서 이것저것 하다 보니 내가 오늘 하루 바쁘게는 보냈는데 무엇을 했는지는 전혀 기억나지 않는 날이 있다. 이렇게 길을 잃은 듯한 날 집중하기 위해 내 역할에서 가장 잘 해내야 하는 '무게중심'이 필요한 것이다. 나는 오늘 PO로써 필요한 일들을 잘 해냈는가?
각 역할에 대한 하이라이트 역량을 쓴 글의 끝맺음에서 하기엔 다소 민망한 이야기지만 사실 지난 커리어 여정에서 '이 타이틀이 무엇을 하는 업인지'를 규격화하는 것보다 더 중요한 것이 있다고 느꼈다.
내 조직, 내 역할, 혹은 내 커리어의 변화에 따라 무게중심을 둬야 하는 곳이 어디에 있는지 파악하고 그것에 맞춰 역량을 발전시키는 것이다. 이 편이 오히려 변화하는 상황에 더 빠르게 적응할 수 있도록, 더 크게 성장할 수 있도록 도왔던 것 같다.
어차피 시장과 조직은 유기체와 같아서 끊임없이 변화하고 새로운 변이종들이 나타난다. 나만해도 서비스 기획자로 첫 커리어를 시작할 때, 내가 Product Owner가 될 것이라고는 생각지도 못했다.
그러니 몇 년 뒤에도 여전히 PO라는 직무가 있을지도 잘 모르겠다. 아마 비슷하지만 또 다른 새로운 직무는 분명히 나타날 것이다.
이 일은 누구와 어떤 문화에서 일하느냐에 따라 매일 하는 일이 꽤 달라질 수 있다. 그러나 그 일의 최종 목표가 '시장에 가치를 제공하는, 비즈니스 아웃풋을 내는 좋은 제품을 만들기' 라는 것은 크게 변하지 않을 것이다. 그렇기에 '좋은 제품을 만드는 업'의 본질이 무엇인지 앞으로도 계속 고민하며 갖추지 못한 다음 역량들을 쌓아나간다면 어떤 상황이나 타이틀을 가지게 되더라도 지속가능한 '일잘러'가 될 수 있지 않을까.