계속해서 의심이 늘어갈 때
내가 뭘 모르고 있지?
프로덕트 오너라는 직무
현재 다니고 있는 회사에서 프로덕트 오너로 일을 한 지도 벌써 7개월에 접어들었다. 이미 회고도 여러 차례 썼던 차라, 중복되는 내용이 많을 것 같아 하반기 회고는 패스할까 싶기도 했다. 이러다가는 브런치 채널 = 회고록이 될 것 같다는 걱정이 있었는데, 아니나 다를까 내 브런치를 구독하고 있는 주변 지인들 역시 '왜 요즘 주야장천 회고만 하냐'며 물어왔다. 그럴싸한 답변이 떠오르지 않아서 그저 어깨만 으쓱이고 말았는데, 그 말 그대로 언젠가부터 프로덕트 매니지먼트에 관한 방법론이나 제품의 UX/UI 분석, 역기획 등에 대한 이야기를 쓰기가 어려워졌다.
대외비라 공개된 채널에 다루기 어려운 내용들도 종종 있었지만, 외에는 어느 정도 블라인드 처리를 해서 써봄직하기도 했다. 그런데도 굳이 글의 내용으로 다루지 않았던 것은 첫째로, 게을러진 탓이다. 팀 업무에 부랴부랴 적응하다 보니 어느새 수습 기간이 끝나 있었고, 어떻게 하다 보니(?) 장기화 된 TF도 끝이 났으며, 이제 정신을 차리나 싶을 때 새로운 셀 조직의 PO로 배정되어 셀의 하반기 과업과 예상 일정을 정리하고 있었다. 이 모든 과정이 체감상 눈 깜빡할 사이에 지나갔다. 그러니 집에 와서 키보드를 두들기며 회고글이라도 쓰는 것이 그나마 최선이었다.
두 번째 이유로는, 정합한 정보를 왜곡 없이 전달할 수 있는 글을 쓸 자신이 없었기 때문이다. 신기하게도 이 일은 하면 할수록, 실험 또는 개선 후 보이는 결과에 대한 확신을 갖기가 어려워지는 것 같다. 피상적인 지표만 보고 잘못된 판단을 내리는 건 아닐까, 이 프로젝트에서 전환율을 보는 게 정말 유의미할까? 하는 고민이 꼬리의 꼬리를 무는데, 이 모든 사고의 흐름을 기승전결화해 글로 담아내는 건 꽤 어렵다는 생각이 들었다.
어떻게 일해야 하는지
예전에는 'Product Owner는 어떻게 일해야 하는가', 'PM과 PO의 차이는 무엇인가'와 같은 주제로 뜨거운 논쟁이 벌어질 때, 오가는 이야기들 속에서 나름대로의 정의를 내려보려고 애를 썼던 것 같다. 하지만 요즘에는 이런 이야기를 들어도 크게 감흥이 없어졌다. 직무마다의 R&R은 해외 사례나 또는 국내 소수의 선례를 참고하면 누구나 충분히 이해할 수 있다. 그러나 각종 서적이나 매체에서 정의하는 이상적인 PM 또는 PO로 일을 하기란 현실적으로 쉽지 않다. 심지어는 미니 CEO라는 별명 때문인지 PO를 마치 중간 관리자(인사나 평가 권한을 가진)의 역할로 오인하는 경우도 종종 있는 듯 싶다.
한 마디로 함께 협업하는 팀원 간의, 조직 내의 이해 일치가 선행되지 않으면 직무명은 큰 의미가 없다. 나만 하더라도, 각 회사에서 PM이라는 직무가 어떤 일을 하고 있는 사람인지 알 수가 없어서 범용적인 이야기를 할 때마저도 'PM 또는 PO 또는 서비스 기획자에게 도움이 되는'이라는 미사여구를 쓰게 되는 때가 종종 있다. 더 자세한 사정은(?) 도그냥님이 쓰신 아티클을 읽어보셔도 좋을 것 같다.
https://brunch.co.kr/@windydog/592
요즘 하고 있는 일, 앞으로는 어떻게 일하고 싶은지
1. 회사의 방향성과 목표를 이해하고, 프로덕트 팀이 어떤 고객 가치를 창출하고 전달할 수 있을지 고민하기
최근 신규 셀에 배정받으면서 셀의 존재 이유와 목표, 회사에 기여할 수 있는 방안들에 대한 고민을 새로이 시작했다. 각 셀마다의 역할을 워크샵에서 이야기 나눈 뒤, 이후 자연스럽게 먼저 시작한 일도 셀 플래닝이었다. 이 셀이 회사와 제품에 기여할 수 있는 부분이 무엇인지, 제품을 사용하고 있는 고객들에게 어떤 가치를 전달할 수 있을지, 그것을 잘 전달했는지는 어떻게 확인할 것인지에 대한 고민의 과정이 있었다.
2. 목적 조직의 이점을 최대한 가져가기. 프로덕트 팀이 함께 모여 유저 스토리를 작성하고 리뷰(보완)하는 시간 갖기. 납득되지 않는 지점에 대해서는 가감 없이 함께 논의하기.
개발자, 디자이너, PM/PO/기획자. 서로 다른 직군으로 구성된 프로덕트 팀의 가장 큰 이점은 한 직군의 시야에만 국한되지 않은 사용자 가치를 고려할 수 있는 점이라고 생각했다. (그게 워터폴 방식과의 가장 큰 차이라 생각했다.) 물론 진행하는 과업의 특성에 따라 유저 스토리를 잘 활용할 수 있는가는 별개의 문제다. 예를 들어, 사용자 가치를 창출하기보다는 기술적인 이관 작업이 주를 이루는 프로젝트에서는 확연한 장점을 살리기 어려울 수 있다. 그럼에도 불구하고 그 과정에서 발견되는 UX적인 불편점이나 부채들을 털고 갈 수 있는 것은 사실이다. 다만, 획기적인 가치는 제공하기 어려울 수 있다는 뜻으로 받아들여지면 좋을 것 같다.
반대로 이전 제품에는 없었던 새로운 가치를 제공하는 과업에서는 빛을 발할 수 있는 방식이다. 서로 다른 관점에서 함께 만들 가치를 논의하고, 협의해 나가는 과정이 지지부진해 보일 수는 있으나 장기적으로 봤을 때는 제품 개발 및 고도화 면에서 더 빠를 수 있다.
특히나 이번에 개인적으로 와닿았던 부분은 기획 의도나 개발 방식에 관해 납득되지 않는 지점이 발생하면 팀원들과 가감 없이 논의가 가능하다는 점이었다. (물론 그러면 안 되지만) 일에 쫓기다 보면 '좋은 게 좋은 거지'라는 생각에 디테일이 누락되거나 '왜 그렇게 해야 하는지' 깊게 생각하지 못할 때가 있다. 나 역시도 간혹 팀원들이 던지는 질문에 답을 못하는 경우도 생기고는 하는데, 그럴 때면 한 5초 정도 부끄럽다가도 이후엔 오히려 든든함을 느낀다.
이번에 함께 일하는 FE 개발자 분이 "핀리, 어차피 핵클 기능 플래그 쓸 텐데 왜 꼭 새 URL로 변경해야 해요?"라는 질문을 주셨을 때 제대로 된 답변을 못한 일이 있었다. 하필 그때 핵클 사용량 집계 방식에 대한 신규 업데이트가 있었다는 사실을 이미 접한 상태였기 때문에, 왜 그런 결정을 내렸었는지 더더욱 기억이 나지 않았고.. 나는 "그러게요? URL 하나로 분기 치면 되는데?"라고 답변을 해버렸다. ㅎㅎ.. 정신 차리자..
3. 빠르게 소통하고 투명하게 공유하기
요즘 드는 생각인데, 하고 있는 일만 와다다 공유하고 끝내는 데일리 스탠드업은 정말 지양해야 하는 방향이라는 생각이 들었다. 특히나 몰입할 시간이 부족한, 워킹데이가 적은 주차에는 더더욱 고민이 된다. 그럴 거면 서면으로 남기고 각자 확인하는 방식이 더 효율적이지 않을까? 그래서 되도록 특이 사항 위주로 공유하고, 프로덕트 팀 미팅이 있는 날에는 스탠드업은 생략하고 있다. 팀원 서로에 대한 신뢰 문제라고 생각해서, 팀 문화가 잘 자리 잡고 함께 일하는 방식이 몸에 익으면 큰 문제는 없다는 생각이다. 단, 이러한 신뢰는 빠른 소통과 투명한 공유를 전제로 해야 하는 것 같다. 이슈가 생겼을 때 즉각적으로 논의하고 대응할 수 있는 환경이 뒷받침된다면 (향후에는) 스탠드업을 생략해도 큰 문제가 없지 않을까..
4. 스프린트의 목표를 일치화 시키고, 팀의 벨로시티를 잘 측정하고 관리해서 목표를 달성하는 경험을 쌓아나가기
우선적으로 당장의 내게 필요한 역량은 한정된 리소스 내에서 최선의 기능 스펙을 산정하고, 일정을 수립하고, 프로덕트 팀이 납득할 수 있는 수준의 기획 의도와 설득력을 갖춰 구현 가능한 범주를 조율해 나가는 것으로 보인다. 이 조율과 합의점을 잘 찾아나가기 위해서.. 어쩌구
어떻게 보면 Project Manager에 가까운 역량이라고도 생각한다. Jira를 활용해 보고서를 뽑고, 팀 전체의 리소스를 관리하고, 범위 변경이나 달성하지 못한 스토리는 몇 개가 있었는지 이전 스프린트와 비교하고.. 우리 팀의 평균적인 벨로시티를 측정하는 데까지 소요되는 시간도 적지 않으며, 이를 관측하는 PM 입장에서도 사실 적지 않게 리소스가 들어가는, 번거로운 일일 수 있다. 그러면서도 한편으로 예전에 회고에서 썼던 문장이 잠깐 떠올라 위와 같이 셀프 인용해봤다. 프로젝트 매니징 자체가 PM, PO의 업무와 완전히 무관한가?라고 물으면 또 그렇지 않다고는 대답하기 어려울 것 같다.
5. 임팩트 있는 일을 먼저 하기, 찾아하기
이건 실제로 이렇게 하고 있다기보단 그렇게 하고 싶다에 가깝다. 어떤 PM/PO이든 임팩트 있는 일을 하고 싶은 건 다 같은 마음일 거다. 적은 리소스를 들여 최대 효율 뽑기. 엄청난 직관력을 보유한 사람이 아니라면 임팩트 있는 일을 하기 위해서 우선순위 높은 일을 잘 선정할 수 있는 변별력과 설득력이 있어야 하는데, 말처럼 쉽지 않은 일이라는 생각을 매일 한다. 리소스가 한정적인 상황에서는 '지금 해야 할 일'과 '지금 하면 안 될 일'을 구분할 필요성이 있다. 때로는 이해관계자끼리도 생각하는 우선순위가 다를 수 있어, 설득을 위해서는 합리적인 근거나 대안 제시가 필요하다. 그래서 다들 데이터 데이터 하는가 보다..
물론 가끔은 그냥 해야 할 일이 발견될 때도 있다. 만사 제쳐놓고, 이건 누가 보더라도 무조건 해야 하는 일. 그런 상황에서는 전후 데이터를 비교하고, 리서치를 하고 하는 것보다 바로 행동에 옮기는 편이 낫다고 생각한다. (쭈가 자주 강조하는 부분이기도 하다.)
수습 기간에 제안했었던 장바구니 notify badge 추가 건이 딱 그랬다. 이건 무조건 해야 돼! 하는 것.6. 어떤 신규 입사자가 오더라도 잘 적응할 수 있는 체계와 시스템 만들기
사실 어느 팀이든 고민하는 문제일 것 같은데, 어떤 신규 입사자가 팀에 합류하더라도 잘 적응할 수 있는 체계를 만들어 나가고 싶다. 그러기 위해선 상시적인 문서화가 바탕이 되어야 하는 부분이다. 셀 내에서 이루어지는 논의는 기본적으로 모두 컨플루언스에 남기고 있는데, 특히나 함께 일하는 개발자 분들과 디자이너 분이 문서화와 구조화에 특화되신 분들이라 얼떨결에 숟가락을 얹고 있다. 반성.. 해야지..
단순한 거라도 자주 잊어버리는 건 워크플로로 만들고, 최대한 자동화할 수 있는 부분은 자동화해서 쓰는 게 모두의 시간을 절약하는 길인 것 같다. 인프랩에는 칭찬용 새싹봇이라는 슬랙 앱이 있는데, 불편한지도 모른 채 관성적으로 겪고 있던 어려움을 해결해주는 사람에게 새싹을 마구마구 날리며 칭찬할 수 있는 봇이다.
7. 큰 문제를 작은 문제로 만들기
이건 어떤 직군에 있는 사람이든 누구에게나 공통적으로 필요한 역량인 듯싶은데, 바로 '큰 문제를 최대한 작게 만들어서 해결하기'다. 이전 티타임 때, 향로는 스타트업 PO는 '그래서'보다는 '그럼에도 불구하고'라는 표현을 더 자주 써야 하는 직군이라고 말씀하셨던 적이 있다.
"되게 큰 문제가 실제로는 어려운 문제와 쉬운 문제가 섞여서 더 커 보이는 경우가 많습니다."
그때 향로가 했던 피드백에 누구보다 공감했고, 잘 해내고 싶었다. 그래서 하반기에는 깊게 몰입해서 연습해 보고 싶다. 복잡해 보이는 문제에서 쉬운 문제를 변별해 내고, 어려운 문제만 어떻게든 해결할 수 있는 방안을 찾아내는 형태로.
8. 끈기 있게 일하기
7번과 연결되는 문제이기도 한데, 뒷심이 부족하면 안 되는 것 같다. 비단 개발 기간이 길게 소요되는 장기 프로젝트에만 해당하는 말이 아니라, A/B테스트 하나를 진행하더라도 끈기 있게 일하는 법을 계속해서 익혀나가야 하는 것 같다. 일의 시작점에서 첫 삽을 잘 뜰 수 있도록 하는 것은 당연히 중요하다. 하지만 장기전으로 가다 보면 체력적으로 힘에 부치는 순간들이 분명히 온다.
개발, QA, 운영, 법무, 마케팅 등 이해관계자들과 상시적으로 소통하고, 조율하고, 대비해야 할 부분들이 자연스럽게 발생하는데 정신없이 휩쓸리다보면 놓치는 지점이 생길 수 있다.
기절할 것 같았던 4월이슈를 미연에 방지할 수 있다면 그게 베스트겠지만, 사람이 하는 일이기 때문에 현실적으로 모든 이슈를 전방위적으로 예측하고 대비할 수는 없다. 그렇기 때문에 상대적으로 경험이 부족한 주니어라면 더더욱 맷집을 키우고(몸도, 마음도) 경험치를 먹는다는 생각으로 끈기 있게 배워나가는 수밖에 없는 것 같다.
A/B테스트를 예로 든 것은, 실험이 실패하더라도 '그냥 안 됐구나'하고 종료할 게 아니라 최소한 어떤 교훈은 건졌고, 그 경험을 바탕으로 어떤 액션이나 추가 실험을 진행하면 좋을지 고민해보는 자세가 몹시 중요하다고 느꼈기 때문이다. 이건 같이 일하고 있는 PO 분들을 보며 크게 배운 부분이기도 하다. 진행한 실험에 대한 최소한의 책임감이라고 해야 하나. 원하는 방향대로 실험이 흘러가지 않아 맥이 빠질 수는 있어도 실험 세팅부터 진행, 종료 시점까지 계속해서 팀의 리소스를 사용하고 있는 것이나 매한가지이기 때문에 마지막 결론 도출까지도 소홀해서는 안 된다는 것을 이제는 조금 알게 됐다. 덧붙여 실험 설계 단계에서 신중해야 한다는 것도.
의심이 무조건적으로 나쁘지만은 않다
의심에 갇혀 액션하지 못하면 그건 그것대로 문제가 되겠지만, 전혀 의심하지 않고 행동에 옮겨버리면 안 해도 될 실수를 하게 되는 상황이 더러 생기는 것 같다. 미리 두들겨 볼 수 있는 돌다리라면 두들겨보고 건너는 것이 좋지 않을까? 언제나 그렇듯 일단 나부터 잘하기.. 화이팅!
