brunch

You can make anything
by writing

C.S.Lewis

by 레오군 Apr 18. 2020

[Book] 프로덕트 오너

지금은 데이터 분석 업무를 주로 진행하고 있지만, 나는 대부분의 커리어를 Product Manager 로 일해왔다. (흔히 '기획자'라고 부르는 그 포지션...) PM은 굉장히 재미있고 보람있는 직군이긴 하지만, 동시에 굉장히 피곤하고 스트레스를 많이 받는 포지션이라고 생각한다. 사실 데이터 분석 직군으로 전향(?) 하고 나서, 직군을 바꿨는데 어떤지 묻는 질문을 종종 받는데, 사실 그때마다 내 대답은 한결같다.

"PM 안해서 너무 좋다... 진짜 삶의 질이 달라졌어."

~~오늘도 고생하고 계신 IT 서비스의 PO와 PM 여러분 존경합니다.~~

PO과 PM을 굳이 구분하는 회사도 있긴 하지만, 기본적으로 PO/PM에게 기대하는 바는 비슷하다고 생각한다. Product의 mini-CEO. 제품에 대한 로드맵과 개발우선순위를 정하고, 협업부서의 담당자들간 업무를 조율하고, 프로덕션 과정에서 발생하는 이슈에 대한 의사결정을 하고, 정해진 일정으로 제품이 시장에 나갈 수 있도록 관리하고, 릴리즈되는 제품의 최종 품질을 책임지는 사람. (아 이렇게 써놓고 보니 뽀대나긴 한다)

하지만 PO/PM로 일하면서 마주하는 현실은 교과서에 나오는 텍스트와는 좀 거리가 있다. 그냥 개발과 디자인을 제외한 모든 잡무를 다 챙겨야 하고, 주어지지 않은 권력을 휘둘러야 하고 (너무 세게 휘둘러도 욕먹고, 너무 약하게 휘둘러도 욕먹음), 이슈를 하나 해결하고 돌아서면 새로운 이슈 2개가 기다린다. 이렇게 열심히 일하고 있는데도 잊을만 하면 한번씩 나오는 기획자 무용론에 시달려야 하며, 잘못한 건 사람들이 귀신같이 지적하지만 잘한 걸로 칭찬받기는 쉽지 않다. ㅎㅎ

개인적인 경험에 비추어보면 '업무가 많고 바쁘다...'는 어떻게든 해결할 수 있는 문제인데, 스스로 느끼는 '성장'에 대한 피드백이 너무 모호하다는 게 훨씬 더 큰 문제였다. 연차가 쌓이긴 하는데 그에 따라서 내가 가진 스킬셋도 쌓이긴 하는지, 그냥 고인물이 되어서 히스토리를 많이 아는 게 PO의 실력인건지 헷갈리기 시작하고, 과연 10년차 PO인 나는 5년차 PO보다 2배 더 잘한다고 할 수 있을까? 후배 PO에게 어떤 걸 알려줄 수 있지? 좋은 PO가 되려면 뭘 공부해야 하지? SQL을 공부하고, 개발을 공부하면 업무상 도움이 되는 게 맞긴 하지만, 그렇다고 SQL이 PO가 가져야 할 스킬의 정수라고 할 수 있을까? PO의 성장 로드맵 같은 거 없나??? 이런 생각들이 끊이지 않았던 것 같다.

그런 의미에서, 이 책은 일단 존재만으로도 조금은 반가운 책이다. (아 물론 이제 나는 더이상 PO가 아니지만 ㅎㅎ) 주니어 개발자나 주니어 디자이너를 위한 책은 차고 넘치는데, PO를 꿈꾸는 주니어들을 위한 책은 굉장히 드물다고 생각하는데, 이 책은 정확히 그 지점을 타겟팅하고 있다. 특히 Product Owner 라는 직군이 잘 정의되어 있는 쿠팡에서의 업무 경험에 대한 이야기는, PO를 목표로 하는 많은 사람들에게 꽤 흥미로운 지점으로 다가간다. 특히 일반적으로 PO에게 기대되는 soft skill에 대한 부분이 잘 정리가 되어 있는 편이다. 다만, 예시로 든 사례들이 다소 모호하다는 부분은 아쉽다. 물론 회사에서 경험한 대부분의 일들이 대외비라서, 공개되는 책에 쓰기엔 쉽지 않았겠다 싶지만.

아쉬운 점을 꼽자면, 상대적으로 soft skill에 해당하는 내용은 전반적으로 책에 잘 설명이 되어있는 반면 PO에게 필요한 hard skill에 대한 설명이 부족하다는 점이다. 사실 고객의 목소리를 주의깊게 듣고, 데이터 기반으로 의사결정하고, 개발자/디자이너와 효율적으로 커뮤니케이션 해야 한다는 건 어찌보면 굉장히 당연한 부분인데, 막상 일을 해보면 이런 것들을 구체적으로 어떻게 해야하는지 배우는 게 굉장히 어렵기 때문이다.(물론 회사의 여건이나 프로덕트의 성격에 따라 다를 수 있기 때문에 모든 상황에 맞는 정답은 없겠지만, 경험해 본 '하나의 답'만 잘 정리되어 있어도 충분히 도움이 된다고 생각) 가령, 일정 관리를 위한 칸반 보드는 어떤 서비스를 써서 어떤 식으로 관리했는지. knowledge base로 주로 사용하는 wiki는 어떤 식으로 활용했는지, jira 등의 이슈 관리 시스템은 어떻게 설정해서 어떤 규칙에 따라서 티켓을 주고 받았는지 등등... 이 책의 기획 범위가 아닐 것 같긴 한데, 사실 나는 이런 부분을 잘 설명해준 책이 있었으면 하는 생각을 굉장히 어려 번 했다. (써놓고 보니 그냥 confluence 사용 경험담이 듣고 싶었던건가 ㄷㄷㄷ)

덧붙이자면, 직업병 같긴 하지만 AB테스트랑 p값을 설명한 부분은 조금 아쉽다. 물론 통계적 유의도나 p값에 대한 설명을 쉽게 하는 것 자체가 불가능에 가깝긴 하지만, 이 책은 쉬운 비유와 틀린 설명 사이를 아슬아슬하게 오간 느낌...

그럼에도 불구하고 이 책은 개인적인 '추천'의 범주에 들어간다.

대기업에 소속되어 프로덕트를 만들 때마다 가졌던 큰 불만은, 내가 사용자를 등지고 의사결정권자를 바라보면서 일을 하는 것 같다는 생각이 끊임없이 든다는 점이었다. 하지만 막상 스타트업에서 일해보니... 나는 여전히 사용자를 등지고 있고, 그냥 내가 하고 싶은 걸 하고 있는 건 아닌가 하는 생각이 드는 경우가 종종 있다. 그런 의미에서, 이 책을 읽으면서 반성이 되는 부분이 분명히 있었다. ㅎㅎ 이 책 전체를 관통하는 사용자 중심, 목표 지향, 데이터 활용, 프로덕트에 대한 책임감과 ownership에 대한 이야기는 IT 서비스를 만들고 있는 사람들이 스스로를 되돌아보기에 좋은 주제라고 생각한다. 이 업계에 발을 걸치고 있다면, 한 번 쯤은 읽어볼만한 책.