우리 조직에 필요한 PO(Product Owner) 정의하기

Dahye Lee
원티드랩 기술 블로그
7 min readMay 12, 2022

이 아티클은 PO(Product Owner)가 무엇인지 답을 말하는 것이 아니라, 조직에 적합한 PO의 역할을 정의하는 과정에 대한 이야기입니다.

안녕하세요. 원티드랩 Product Owner 이다혜입니다.

PO라는 포지션이 생겨나면서 대체 그들이 뭘 하는 사람들인지 궁금증도 커지는 것 같습니다.

저는 2019년에 원티드랩(이하 원티드)에 PO로 조인했습니다. 마침 PO라는 포지션이 생기고, 팀도 꾸려지고 있었죠. 우리에게 가장 익숙한 ‘기획자’에서 시작되어 ‘PM(Product Manager)’, 그리고 ‘PO(Product Owner)’까지 타이틀이 진화한 것입니다. 타이틀이 바뀔 때마다 기대치도 달라졌지만, 그간 함께 일해온 동료들 머리 속에 PO는 여전히 기획자로 남아있기도 했습니다. 해석도 제각각이었습니다. 누구는 화면 기획에 더 집중해주기를, 또 누구는 전략가로서 거시적인 그림을 그려주기를 바랐습니다. 결국 원티드 PO는 기획자 & PM & PO를 모두 해내는 초인이자 늘 바쁜 사람, 미팅이 많은 사람, 과도한 책임을 지는 사람이 돼버렸죠… (옆자리 지니님의 얼굴 보기가 어찌나 힘들던지)

이것은 비단 개인의 번아웃 문제를 넘어서는데요, 기획자 또는 PM의 역할을 수행하는 데 들어가는 시간과 에너지가 그대로이니, 회사가 PO라는 역할을 만들 때 기대했던 진짜 업무를 해내기 위한 (또는 여기에 투자하는) 시간이 거의 없는 것이었습니다. 회사의 이상은 우리가 자주듣는 미니 CEO였지만, 그것을 따라갈 물리적 여유가 없으니 이상과 현실의 갭은 점점 커져만 갔습니다.

이런 상황에서 가장 큰 압박을 받는 것은 PO 자신이었기에 워크샵을 기획하게 되었습니다.

워크샵의 목적

PO의 역할을 정의하고, 그 역할에 집중할 수 있는 방안을 모색한다. (가설: 정의된 역할에 리소스를 집중시키면, 개개인의 역량이 성장할 것이다.)

사전 준비: 현 상태 진단

워크샵 전 PO들에게 과제를 주었습니다. 과제의 이름은 ‘To-do List 다시 쓰기’. 원티드 PO들의 현 상태를 솔직하게 바라보기 위한 진단의 과정이었습니다. To-do List 다시 쓰기 문서(구글 스프레드시트)를 나눠주고, 워크샵 전까지 작성하기로 했어요. 문서의 내용은 이렇습니다.

실제 작성했던 스프레드 시트
  • 내가 하고 있는 일 리스트업
  • 중요도: 각 업무에 대한 중요도 점수입니다. 중요도는 개인의 주관을 기반으로 스코어링 합니다. (A+, A, B, C)
  • 투입 시간: 한 달에 업무에 할애하는 시간을 입력합니다.
  • 현황 점검: 아래 네 항목 중 선택합니다.
    1. 방법 변화: 필요한 일이지만 충분히 효율적/효과적이지 않아 변화 필요
    2. 위임 가능: 다른 구성원에게 위임 가능
    3. 업무 공백: 필요한 일이지만 시간을 투입하지 못하고 있음
    4. 강화 필요: 필요한 일이지만 역량이 부족해 계발이 필요한 것
  • 코멘트: 위 현황 점검의 이유를 자유롭게 작성합니다.
  • 해결 방법: 해결 방법을 알거나 제시할 수 있다면 작성합니다.
  • 통계 (위 내용을 작성하면 각 중요도에 따라 몇 개의 일을 하고 있으며, 한 달에 몇 시간을 소요하고 있는지 자동 계산되도록 수식을 만들었습니다.)
  • 자가 진단: 작성 과정에서 느낀 점을 자유롭게 적습니다.

워크숍 당일: 우리 조직의 PO는?

‘To-do List 다시 쓰기’의 중요도를 기반으로 현재 진행 중인 업무들 중, PO의 일과 아닌 것을 구분합니다.

PO들의 생각은 거의 비슷했습니다. 디테일한 부분은 생각이 조금씩 다르긴 했으나 개인이 기대하는 커리어 패스에 따라 차이가 생기는 부분이라 제외하고, 의견이 일치되는 부분만 정리해보니 우리가 생각하는 PO는 아래와 같았습니다.

  • PO의 이상향 (=PO의 일이라고 생각하는 것)
    #전략가: 제품의 전략, 방향성, 우선순위 등 큰 그림을 그린다. 로드맵을 설정한다.
    #데이터분석: 지표를 설정 및 분석하고, 임팩트를 예상하여 개선안을 결정한다.
    #커뮤니케이션: 스쿼드 내외부의 커뮤니케이션 간극을 좁힌다.
  • 되고자 하는 모습은 아니지만 현재 수행하고 있는 것들 (=PO의 일이 아니라고 생각하는 것)
    #QA: TC 작성, dev QA, 배포 후 모니터링
    #스크럼마스터: 회고, 스프린트 관리, Jira 이슈 관리
    #번역: 다국어 관리

워크숍 당일: 진단

‘To-do List 다시 쓰기’의 투입 시간을 기반으로 합니다.

PO의 일이라고 생각하는 것(이하 PO의 이상향)과 아니라고 생각하는 것(이하 기타 업무)으로 업무를 구분하고, 각각에 투입되고 있는 시간을 비교해봤습니다. 사람마다 상황은 달랐지만, 최악의 경우 업무 시간의 41%만 PO의 이상향에 쓰고 있기도 했습니다. 수치로 계산을 해보니 적잖이 놀라웠습니다.

우리가 계속 성장하기 위해서는 핵심 역할에 집중하고, 그다음 단계를 세우고 도전하는 과정이 필요한데, 도전은 커녕 현재 닥친 일 조차도 처리할 시간이 없어 허우적거리고 있었던 것입니다 😢

워크숍 당일: 해결

‘To-do List 다시 쓰기’의 현황 점검을 기반으로 합니다.

시간을 효율적으로 쓰기 위해서는 당연한 이야기지만, PO의 이상향에 쓰는 시간을 늘리고, 기타 업무에 쓰는 시간을 줄여야 합니다.

위임이 가능한 것은 위임하고, 방법을 변화할 수 있는 것은 효율화시킵니다. 이를 통해 발생하는 잉여 시간을 업무 공백과 강화 필요 항목에 사용하는 것이죠!

  1. 위임 가능: 업무를 지금처럼 진행하되 다른 사람에게 위임하거나, 자동화합니다.
    – 위임은 하기 싫은 일을 떠넘기는 게 아니에요. 더 잘할 수 있는 사람, 또는 그 역할을 하기로 한 사람이 있는지 확인하고 R&R을 재조정하는 것입니다.
    – 반복 업무는 자동화도 가능합니다. PO가 스쿼드(목적조직)에 반복적인 공지와 안내를 보내야 하는 일이 꽤 있었는데, 슬랙 워크플로우를 사용하여 간단하게 해결할 수 있었습니다.
  2. 방법 변화: 위임이나 자동화가 어렵다면, 공수를 최소화하여 실행할 수 있는지 방법을 모색해 보는 것입니다. 예를 들어 기획서 업데이트가 있었는데요, PO 역할 정의를 통해 기능 단위의 기획서를 잘 쓰는 것보다는 큰 그림을 그리는 것에 집중해야 한다고 의견을 모았습니다. 기획 업무의 일부는 프로덕트 디자이너와 협의하여 업무 분담이 가능했지만, 상위 정책 등 프로덕트 디자이너가 정의하기 어려운 영역도 꽤 있었습니다. 하여 PO가 담당하되, 헤비한 기획서의 형식이 아닌 Jira 이슈에 최소한의 정보를 적어두는 것으로 공수를 최소화하기로 했습니다.

마무리

이 워크숍을 통해 얻은 것을 정리해보자면,

  1. 원티드 PO의 R&R을 명확하게 정의했습니다.
  2. 정의된 R&R을 모든 PO들이 이해할 수 있었습니다. 앞으로의 커리어 목표가 정해졌다고 보면 됩니다.
  3. R&R에 포함되지 않는 업무를 효율화할 수 있는 방안을 결정했습니다.

R&R 정의라는 게 어찌 보면 시시할지도, 이게 뭐 그리 대수인가 싶을 수 있습니다. 워크샵을 하기 전 저도 조금은 그랬어요. 하지만 실제로 해보면 각자 머릿속에 얼마나 다른 그림이 있는지 알게 됩니다. 누구는 쉽다고 생각하는 것을 수행하느라 어려움을 겪고 있는 팀원들을 발견하고 도울 수도 있습니다.

워크샵은 의외로(?) 만족스러웠고, 이후 1:1로 진행하는 평가 면담에서 ‘뭘 해야 하는지 명확해졌다.’와 같은 피드백들을 들을 수 있었습니다.

이제 남은 것은 실천입니다. PO들은 각자의 스쿼드로 돌아가 액션 아이템을 도입하면 됩니다. 커리어 목표 또한 정해졌으니 이를 달성하기 위해 무엇을 할지 고민할 수 있습니다. 이제 막 PO 조직을 꾸리거나, 저희처럼 역할에 대한 고민이 있으시다면 적극 도입해보시기를 추천드립니다.

--

--