데이터 분석가 하다가 프로덕트 오너 하니깐 어떤가요?
Intro
최근에 라이너에서 제품 팀이 일하는 구조가 많이 변했습니다.
이번 분기부터 제품 팀은 목표 별로 인원을 할당하고 일하기 시작했는데요, LINER 제품을 Highlighter, Search & Discovery, 그리고 Community 이렇게 세가지 목표라는 축으로 나눴습니다. 각 목표 구성인원에는 오너, 디자이너, 그로스 해커, 데이터 분석가, 데이터 엔지니어, 추천 엔지니어, 그리고 프론트 엔지니어 분들로 구성이 되어있습니다.
새로운 제품 스프린트 구조를 킥오프하면서 저는 Search & Discovery 오너를 맡아 기존에 하던 프로덕트 분석 업무와 프로덕트 오너 역할을 겸직하게 되었습니다.
**Search & Discovery 는 유저들이 필요로 하는 정보를 찾을 수 있도록 검색과 탐색과정을 돕는 라이너 기능들을 의미합니다. 주로 데스크톱 & 모바일 익스텐션 영역에 포진되어 있습니다.
애초에 구상하던 커리어 트랙이 DA (Data Analyst) → DS (Data Scientist) → PO (Product Owner) 였기에 감사한 마음으로 최선을 다해 임하고 있습니다. 많은 데이터 분석가들이 지향하듯, 인사이트를 도출해 공유하는 것에서 더 나아가 이제는 인사이트를 직접 적용하면서 문제를 풀어나가고 있습니다. 제가 평소에 사용하는 제품을 직접 개선하고 만들어가는 과정은 정말 재밌고 신나는 것 같습니다.
새로운 구조에서 일한지는 이제 한달 반 정도 지났고 그 사이에 크루(crew) 분들과 함께 아래 사진들처럼 벌써 임팩트 나고 재밌는 제품도 몇가지 출시했습니다.
새로운 롤이라 당연히 어려움도 있었고, 이런저런 제품 그리고 운영 상의 배움도 있습니다. 임팩트를 내고 결과로 보여줘야하는 포지션이기 때문에 건강한 스트레스(?)도 새롭게 경험하고 있습니다.
요즘 많이 듣는 질문이 제목처럼 “DA (Data Analyst)하다가 PO (Product Owner) 하니 어때?” 입니다.
LINER Search & Discovery 에서 출시한 제품들에 대한 자세한 이야기는 다음 글에서 풀어내도록 하고, 오늘은 데이터 분석가 업무 때와 비교되면서 인상깊었던 프로덕트 오너의 역할들 몇가지를 공유해보도록 하겠습니다.
데이터 분석가 분들 중에서 다음 커리어 스텝으로 프로덕트 오너를 옵션 중 하나로 고려하고 계신 분들께 도움이 되기를 바랍니다.
Yessss 여전히 분석은 많이 해야합니다.
일단 분석을 놓게 되지는 않았습니다.
오히려 제품일정에 맞춰 필요한 인사이트들을 도출하기 위해 분석을 더 많이 그리고 빠르게 해야하는 것 같습니다. (분석하는 것을 좋아하기에 참 다행이다)
데이터 분석가 일때의 분석경험과 비슷한 부분은 분석의 목적이었습니다.
PO(프로덕트 오너) 가 된 다음에도 문제를 정의하기 위한 분석, 우선순위를 파악하기 위한 분석, 그리고 성과분석 등은 여전히 하고 있습니다.
유저행동보다는 제품기능과 제품지형을 주로 분석한다는 차이가 생긴 것 말고는 큰 차이가 없는 것처럼 느껴졌습니다.
**이건 물론 제가 데이터 분석가 백그라운드를 갖고 있어 그런 걸 수도 있습니다. 사업개발 백그라운드 혹은 제품 디자이너 백그라운드를 지닌 분들의 방식은 다를 수도 있습니다. PO를 하고 계신 다른 분들 중 디자이너 백그라운드를 지닌 분들은 저보다 UX(유저경험)에 대해서 훨씬 세부화된 전략을 짜고 고민을 하고 계신 것을 보기도 했습니다.
다만, 인사이트를 도출한 이후 제품액션 까지의 분석 퍼널축소가 데이터 분석가 일때의 분석경험과 가장 큰 차이로 다가오고 있습니다.
커피챗을 통해 데이터 분석가의 분석결과가 액션으로 활용되지 않는 것에 있어 애로사항이 있으신 데이터 분석가들을 종종 만나뵌적이 있습니다. (주로 이직을 고민하고 계신 분들의 공통적으로 이야기해주시는 페인 포인트입니다) 많은 데이터 분석가들이 왜 PO 로 커리어 전환을 생각하고 계신지 요즘 내심 이해가 되기도 합니다.
LINER 에서는 조직문화를 빌딩할 때 애초에 데이터 기반으로 일하는 것을 주축으로도 삼았기에 저한테 개인적으로 큰 페인 포인트는 아니었습니다.
그래도 데이터 분석가로 일할 때 분석 인사이트를 공유하기에 앞서 액셔너블한 것인지 끊임없이 의심하고 소통 했었습니다. C-레벨 그리고 PO 와 같은 다른 의사 결정권자들한테 액셔너블한 분석결과를 전달하기 위해서 회사 안밖 상황을 이해하고자 하고 끊임없이 소통했습니다.
PO 로 일할 때는 다양한 맥락 속에서 적은 시간 안에 당장 필요한 제품전략들을 위해서 분석을 해야 한다고 느껴집니다. 제가 더 좋은 의사결정을 내릴 수 있도록 의사결정에 근거가 되는 인사이트들을 찾기 위한 분석을 진행하니 액셔너블한지 고민하는 시간이 훨씬 줄었습니다. 다만 아쉽게도 누구나 참고하고 활용할 수 있는 유저 이해분석을 하는 시간이 절대적으로 줄어들었습니다. 지금은 당장의 제품액션에 필요한 데이터를 분석하는 탑다운 식으로 제품 데이터를 분석하고 있습니다.
리소스 운영 101 : Understading the Engineers & Business
PO는 책임은 있지만 권한은 없다는 이야기를 들은 적이 있습니다. 이 내용을 알고 있는 상태에서 PO 역할을 받았음에도 불구하고, 책임범위의 다양성과 책임의 무게는 만만치 않음을 배우고 있습니다.
**”PO는 책임은 있지만 권한은 없다”라는 내용은 굉장히 저명한 김성한 님의 “조직을 성공으로 이끄는 프로덕트 오너” 에서 접한 이야기입니다.
제품 전략을 세울 때 저는 비즈니스 상황을 최우선으로 고려합니다.
우리가 이번 분기에 집중하고자 하는 전사적 목표는 무엇인지, 증명해야하는 KPI는 어떤 것인지, 그리고 다음 분기 혹은 2022년 안에 하고자 하는 것은 어떤 것인지 말이죠. 회사가 가고자 하는 방향성을 밀고 나아갈 수 있도록 하기 위해서는 어떤 기능들이 출시되어 어떤 문제들을 해결해주는 제품으로 라이너가 성장해야하는지 판단합니다. 이러한 판단 기준을 갖고 큰 틀의 제품 전략을 구상하게 됩니다.
하지만 우리는 제한된 리소스로 일을 하는 사람으로서 비즈니스 상황만을 고려해 완벽한 제품만을 출시할 수는 없습니다. 같이 일하는 분들, 특히 엔지니어들의 동기부여 상실 혹은 번아웃을 마주하고 싶지 안다면 말이죠. 비즈니스 상황을 고려해서 큰 틀의 제품 전략이 나왔다면 크루들의 리소스 상황을 고려해서 우선순위 조정도 하고 제품 전략을 프로젝트 단위로 쪼갭니다.
데이터 분석만 할 때 엔지니어들과는 데이터 로그가 주요 소통지점이었습니다. PO가 된 이후에는 엔지니어들과 프로젝트의 개발스펙, 일정산정, 중간중간의 일정조율, 그리고 QA (기능 & 데이터) 에 대해서 소통합니다.
엔지니어들과 소통하는 시간이 더욱 많아지면서 조금 더 엔지니어의 데일리 업무상황을 이해할 수 있게 되었습니다.
프로젝트 일정과 결과물에 대한 책임은 PO 가 지지만, 일정과 결과물에 대한 압박은 엔지니어들이 가장 많이 받게 됩니다. 구조적으로 이를 아무리 잘 해결하려 하고 일정에 관해 조직을 설득하더라도 하더라도 압박을 완벽히 해소하는 것은 어렵습니다.
개발산정이 잘 이뤄졌다는 가정 하에, 엔지니어 분들은 기능완성 까지 필요하다고 사전에 소통한 시간속에서 퀄리티가 보장된 기능을 완성할 책임이 있기 때문입니다. 유저들과 제일 맞닿아있는 지점에서 일하고 있는 엔지니어들은 기한까지 되게 해야한다는 부담이 어느정도 있습니다.
PO 가 엔지니어들의 압박을 조금이나마 덜어드리기 위해서 할 수 있는 부분은 기획에서 나온 태스크들을 우선순위로 쪼개는 것입니다. 우선순위에서 낮은 태스크는 1차 배포에서는 제외를 시켜서 일정을 맞춘다던지 식의 리소스 조율을 하는 것이 큰 도움이 된다는 것을 배우고 있습니다.
한번의 프로젝트 배포가 무거워질 수록, QA 단계에서 놓쳐지게 되는 사항들도 (기능버그, 데이터 품질 등등) 많아지고 프로젝트에 소모하는 시간도 길어지니 참여한 팀원들의 어깨도 무거워지게 됩니다. 최소기능제품으로도(MVP — Minimum Viable Product) 가설검증을 할 수 있는 기능들은 가볍고 빠르게 가고 완성도가 높아야하는 기능이라면 중간중간 여러번의 배포로 태스크를 쪼갤 수 있는지 보는 것이 도움이 됩니다.
제품의 단계에 맞게 리소스를 운영하는 것 또한 PO의 책임에 속합니다.
빈틈없이 미팅 준비하기
미팅은 의사결정의 자리인 경우가 많습니다. 따라서 신뢰 기반의 자리가 되어야합니다.
미팅에 참여하는 사람들은 미팅의 자리에서 최고의 의사결정이 도출될 수 있도록 최대한 정확한 정보들을 전달하고 적극적으로 논의에 임할 필요가 있습니다. 그리고 최선을 다해 토론한 후에는 “개인적으로 동의하지 않더라도, 이미 결정된 사항에 대해서는 최선을 다해야한다. 그럴 수 없다면 더 이상 한배에 탈 수 없다” (pg.60) 고 저는 믿습니다.
** “빌 캠벨, 실리콘밸리의 위대한 코치”에서 나온 내용입니다.*
DA 때도 많은 미팅들에 참여하기는 했지만, PO 가 된 이후로는 프로젝트의 일정산정, 진행상황, 배움, 그리고 성과에 이야기를 하기 위해서 필수적으로 참여해야하는 미팅들이 추가적으로 생겼습니다.
제가 DA 였을 때와 PO 일 때 미팅에 참여해서 하는 이야기의 가장 큰 차이는 더 이상 제 자신의 이야기만 하고자 미팅에 참석하는 것이 아니라는 부분입니다. 미팅에 참여해서 일정산정의 근거를 이야기하고 진척상황에서 겪는 어려움들을 이야기할 때, 제 이야기는 Search & Discovery 에 포함되어 있는 크루분들 모두를 대변하게 됩니다.
그렇기 때문에, 전사미팅에 참여하기에 앞서 현재 진행되고 있는 Search & Discovery 프로젝트들의 어려움, 배움, 성과들을 완벽히 파악해야합니다. 왜 개발 상의 딜레이가 있었는지, QA 가 생각보다 오래걸리는지, 기획이 바뀌게 되었는지 등의 이유를 명확히 설명하지 못한다면 저 자신의 신뢰를 깎아먹는 것을 넘어, Search & Discovery 크루 분들이 같은 이야기를 조직에 반복해서 해야하고 일 몰입도를 방해하는 상황을 유발할 수도 있음을 항상 명심하려 합니다.
Outro
Search & Discovery 크루 분들과 계속해서 즐겁게 프로덕트 메이킹 할 수 있도록 다양한 방면으로 노력하고 있습니다.
그렇게 하기 위해서 전보다 더 분석하고, 리소스 운영에 있어 고민하고, 미팅 준비들도 미리미리 하고 있습니다.
성과 공유 시점에도 우리가 만든 제품의 효용을 다방면으로 소통하려고 노력합니다. 단순히 프로젝트의 결과물이 KPI 목표치를 달성했다 달성하지 못했다를 넘어서, 프로젝트 마다 어떤 가치있는 개개인 배움이 있었는지 그리고 목표 KPI 외에도 어떤 지표적인 가치가 창출되었는지도 전보다 더 일찍이 분석해 놓으려 하고 있습니다.
질문이 들어왔을 때 준비하려 하면 너무 늦은 겁니다.
이렇게 이야기 하고만 끝내면 PO 가 어렵고 힘든 것처럼만 보일 수도 있겠지만, 저는 즐겁게 일하고 있습니다.
좋은 PO 를 넘어 궁극적으로 임팩트 내는 PO가 되고자 하기에 더 고민하고 더 빨라지려고 하는 것 뿐이라고 생각합니다. 다양한 방면으로 자극받으면서 크루분들과 나아가고 있습니다.
PO 로 커리어 전환을 생각하고 계신 DA 분들에게 어느정도 도움이 되는 내용이었기를 바랍니다.
다음 글에서는 LINER Search & Discovery 에서 만든 재밌는 제품들 가져와보도록 하겠습니다.
감사합니다!
