[12월] 김성한 - 프로덕트 오너
Prologue
요즘 나는 프로덕트 매니저가 되기 위한 빌드 업을 하고 있는 중이다. 그래서 프로덕트 매니저가 읽으면 좋을만한 책들을 찾아보았고 여러 가지 필독도서들 중 유일하게 작가가 한국인이었던 이 책을 읽게 되었다. 쿠팡의 현직 프로덕트 오너 '김성한'님이 집필한 책이고 본인이 쿠팡, 코빗 등 국내 굴지의 IT 회사에서 프로덕트 오너로 근무하면서 겪었던 실제 사례와 경험을 통해 얻었던 인사이트가 주 내용이다.
사수 없이 프로덕트 매니징을 하고 있는 나는 참고 사례가 많이 필요하다. 마치 개화기 때 조선이 서양의 신식 문물을 도입하듯 지금 굴지의 기업들에서 활용되고 있는 모든 고급 기술들을 다 흡수해서 내가 맡은 프로젝트에 도입해야만 했다. 그래서 이 책이 너무나 기대되었고 하루빨리 읽고 싶었다.
Main
'책임은 있지만 권한은 없는 PO'
CEO는 인사 권한을 갖고 있기 때문에 직원들에게 대놓고 업무 지시를 할 수 있다. 하지만 미니 CEO라 불리는 PO는 인사 권한이 없어 팀원들에게 지시를 할 수 없다. 그렇기 때문에 자신의 실력을 끊임없이 증명하면서 다른 이들의 존중을 받아야만 조직을 이끌 수 있다. 진행사항에 대해 늘 구체적이고 논리적인 설명으로 설득해야 하고, 책임감 있는 모습을 보여줌으로써 일하는 동료들에게 존중받는 사람이 되어야 한다.
글쓴이는 오히려 PO가 권한이 없는 편이 더 건강한 관계를 유지할 수 있다고 한다. 일방적인 지시가 아닌 더 효율적으로 협업하기 위한 방법을 찾으려고 할 테니 말이다.
또한 PO는 겸손해야 한다. 문제가 발생하면 PO에게 질문과 눈길이 쏠리지만, 성공을 거두면 PO는 함께 이룬 동료들에게 공을 돌린다. 그들이 직접 두 손으로 만든 서비스이기 때문이다.
부여된 책임감은 많지만 권한은 없는 리더, 그것이 Product Owner다.
'PO가 문서로 소통하는 방법'
PO는 늘 누군가(운영, 마케팅, 경영진)에게 요청을 받아서 누군가(디자이너, 개발자, 데이터 분석가)에게 다시 요청을 하는 직업이다. 하루에도 수많은 요구사항들을 접하기 때문에 명확한 의사소통은 필수다. 특히 PO는 문서로 말하는 포지션이기 때문에 쿠팡 같은 대기업의 PO는 어떻게 요구사항을 전달하는지 궁금했다.
저자는 새로운 기능을 만들어야 할 때 투페이저 또는 쓰리페이저 문서를 별도로 작성한다고 한다. 그 문서에는 아래와 같은 정보가 주로 포함된다.
1. 목적
2~3문장 이내로 이 문서의 목적과 어떤 내용을 다룰지 명확하게 밝힌다. 이 문서를 읽기 위해 굳이 시간을 할애해야 하는지 스스로 판단할 수 있도록 하기 위함이다.
2. 배경 정보
2-3문단에서 반장 정도로 왜 이 기능이 필요한지에 대해 설명한다. 이 문서에 접근한 모두가 이 섹션을 읽으면 일련의 진행 상황, 풀고자 하는 문제, 앞으로의 방향성에 대해 이해할 수 있어야 한다.
3. 고객을 위해 하는 일
고객이 해당 기능을 왜 고용할지에 대해 짤고 명확하게 목록 형태로 작성하며 1번부터 중요도에 따라 나열한다.
ex) "어떤 음식을 주문할지 정확하게 알고 들어온 고객은 실시간 배송 정보를 눈으로 확인하기 위해 이 새로운 지도 기능을 고용한다."
4. 원칙
개발 과정에서 결정을 내릴 때 잣대로 삼을 원칙을 작성하며, 6개 이내로 1번부터 중요도에 따라 나열한다.
ex) "고객은 음식 배달 현황을 파악하는 걸 가장 중요하게 생각한다. 배달 현황을 파악하는 데 도움이 안되는 지도 기능은 철저하게 배제한다."
5. 목표
새로운 기능을 통해 어떤 목표를 달성할지 설명한다. 목표는 2-3개로 한정하고 수치화할 수 있어야 한다.
6. 주요 지표
목표에 사용되는 지표를 포함하여 기능이 제대로 된 목적을 수행하고 있는지 나타낼 수 있는 지표를 3-4개 정도 선정한다.
7. 개발 계획
개발 계획을 작성하며 고도화 정도에 따라 1-3단계로 나누기도 한다. 개발 완료 예정 시간과 상태를 표기한다. 문제가 없을 시 그린, 완료 시점까지 못 끝낼 거 같다면 옐로우, 개발 완료 가능성이 거의 없을 경우 레드로 표기한다.
8. 자주 묻는 질문
개발팀 또는 유관 부서에서 나올법한 질문을 예측하고 미리 답변을 적어놓는다. 똑같은 질문을 여러 번 받아서 생기는 비효율적인 시간을 없애기 위함이다.
PO가 해서는 안되는 일
저자는 책에서 PO가 해서는 안되는 일에 대해 설명한다. 결론부터 말하자면 PO는 자신이 최고의 결과물을 낼 수 없는 업무를 하지 말라고 한다. 예를 들어 개발이라던가 국내의 서비스 기획자들이 도맡아 하는 사용자 경험 설계 등이 그것이다. 개발의 전문가가 아닌 사람이 개발을 하거나 UX 디자인 전문가가 아닌 사람이 UX를 설계하면 그 과정에서 문제가 생기기 마련이고 결국 고객에게도 최고의 서비스를 제공할 수 없기 때문이다.
이런 문제를 방지하기 위해선 PO가 무슨 일을 해야 하는 사람인지 본인 스스로가 명확히 알고 있어야 한다. PO는 프로덕트의 방향성에 대해 고민하고 우선순위를 정해 조직이 나아갈 방향에 대해 결정을 내리는 사람이다. 이를 위해 VOC 파악, 데이터 분석, 정책 수립, 회의 주재 등 해야 할 일이 많다.
아직 PO라는 직무가 보편화되어 있지 않아 여러 조직에서 기대하는 PO의 업무가 다를 수 있다. 그렇기에 PO 스스로 본인의 R&R을 명확히 인지하고, 다른 이들도 이해할 수 있게 설명할 줄 알아야 한다. PO가 다른 업무에 정신 팔려 있는 동안, 더 중요한 결정을 내리지 못해서는 안된다. 아래는 PO의 책임 업무에 대해 저자가 정리한 표이니 참고하자.
| 책임 업무 | 개발 매니저 | TPM | PO | |
| 1 | 유관 부서 회의 | 필요 시 참석 | 주기적으로 참석 | 항상 참석 및 주도 |
| 2 | 로드맵, OKR, 기타 문서 | 검토 및 첨언 | 검토 및 첨언 | 작성 및 수정 |
| 3 | 우선순위 설정 | 검토 및 첨언 | 검토 및 첨언 | 설정 및 설명 |
| 4 | 유관 부서 소통 | 필요 시 기여 | 주기적으로 기여 | 주기적으로 기여 |
| 5 | 기술 이슈 | 해결 및 기록 | 주시 및 대응 | 주시 및 대응 |
| 6 | 스크럼 회의 | 주도 및 참여 | 주기적 참석 기대 | 참석 및 설명 |
| 7 | 스프린트 계획 | 주도 및 업무 할당 | 주기적으로 참여 | 주도 및 설명 |
| 8 | 데이터 및 수치화 | 필요 시 검토 | 충분한 이해 보유 | 설정, 생성, 설명 |
| 9 | 개발 완료 공지 | 필요 시 검토 | PO 검토하에 작성 | 필요 시 작성 |
| 10 | 마이너한 이슈 | 야간 담당자 할당 | 가능하면 대응 | 가능하면 대응 |
Epliogue
이 책을 읽고 나서 오히려 든 생각이 "내가 이 일을 할 수 있을까?"였다. 지표 설정, 데이터 분석, 요구사항 정리, 스프린트 리딩, 유저 테스트 등 책임져야 할 업무도 많고 여러 이해관계자들을 설득하고 이해시키고 소통해야 한다. 정말 개발, 디자인 빼고 모든 일을 하는 건데 개발도 알아야 하고 디자인도 알아야 하고 데이터도 볼 줄 알아야 하고 사업적인 관점도 뛰어나야 한다는 게 과연 가능한 일일까? 하는 생각이 들었다.
하지만 반대로 누구나 쉽게 할 수 없는 일이기에 도전해 볼 만한 가치가 있다고 생각한다. 그리고 여러 구성원들을 조직화하여 운영되는 체계를 만드는 것이 습관이고, 변태같이 디테일에 집착하고, 사람들과 소통하는 걸 즐거워하는 나에게 딱 맞는 직무가 아닐까 싶다. "내가 할 수 있을까?"와 "나이기에 잘할 수 있지 않을까?"란 두 생각이 교차하는 데나는 늘 긍정적이고자 노력하는 사람이니까 후자에 무게를 싣고자 한다.
오늘도 이 책 한 권이 나에게 용기를 주었다. 나는 할 수 있다!(할 수 있겠지??)
