서비스기획자에서 PO로 전업하며 느낀 차이점
6년차 서비스기획자, PO로 일을 시작하다.
PO로 일을 시작한 지 한 달 반이 되었고, 조금씩 일하는 방식이 보이기 시작한다.
기존에 기획자로 일하던 방식과는 비슷한 듯 다르다. 결국 피쳐를 개발하다 보니 궁극적으로 개발을 하기 위해 필요한 것들을 정의한다는 점이 같지만 아래 세 가지 포인트가 크게 다르다.
|첫째, 화면설계서의 유무
기획자와 PO의 가장 큰 차이로 가장 흔히 꼽히는 것이 화면설계서의 유무다. 기획자로 일하며 기획을 하기 위해서 가장 중요한 것은 화면설계서였다. 화면설계서에서는 1. 정책을 얼마나 꼼꼼히 잘 짜 넣느냐, 2. 얼마나 구멍 없는 기획을 하느냐가 기획자의 자질을 판단할 만큼 중요했다. 기획자에게 화면설계서는 무기였다. 어떤 질문이 들어왔을 때 "그거 화면설계서 어디에 있어요"라고 말을 했을 때의 쾌감을 아는 기획자가 많을 거라 믿는다. 내가 미리 판단하고 정책을 다 준비했어. 라는 표현을 통해 내가 얼마나 능력 있는 기획자인지를 알 수 있었다. 반대로 말하면 기존의 구조를 잘 파악하고 있지 못하면 바보가 되는 구조였다. 기존의 화면설계서를 뒤지고 뒤져 찾아낼 수밖에 없었고 개발에 물어보았을 때도 "그 정도는 기획에서 알고 있어야 하는 거 아니야?"라는 대답/태도를 만나기 일쑤였다.
화면설계서에는 정책 뿐만 아니라 말 그대로 화면을 설계한 화면이 있었다. 정책, 알고리즘, 각 화면의 구성, 심지어 버튼위치까지 다 화면설계서에 그려넣어야 했다. 이를 보고 디자이너는 디자인을 하고 개발자는 개발을 했다. 그러다보니 디자인 자체도 화면설계서와 동일하게 나오기 일쑤였고 디자이너의 역할이 작아질 수밖에 없는 구조였다. 기획자의 역할 또한 프로세스 정의와 스펙정의에 가장 많은 리소스가 쓰였다. 내 경험 상 왜 이 프로젝트를 해야 하는가는 상부에 보고할 때가 아니면 중요하지 않았고 대부분 위에서 해야 할 일이 꽂혀 내려오는 경우가 많았다. 더더욱 '왜'해야 하는 가에 대한 이유가 크게 의미 있지 않았다.
반면 PO는 화면설계서가 없다. 그 대신 1-pager라는 간단한 문서가 있다. 이 1-pager에서 가장 중요한 것은 Problem statement다. 즉, 1. 고객의 Jobs to be done이 무엇인지를 발견하고 2. 이에 대한 해결책을 세우는 것이 가장 중요하다. (Milkshake threory로 유명한 jobs to be done은 꼭 읽어보길 바란다). 고객이 어떤 문제를 가지고 있고 이에 대한 어떤 해결을 한다는 것에 근거가 명확해야 한다. '왜' 해야 하는 지에 대해 끊임 없이 설득해야 하고 그래서 Data Analyst와의 협업이 필수다. Data가 있어야만 유저가 어떤 문제를 느끼고 이게 어떻게 숫자로 보여지는 지를 증명할 수 있다. PO가 'why'에 집중하는 대신 화면과 프로세스 정의는 UX 디자이너가 진행한다. 물론 가장 중요한 핵심 기능은 1-pager에 정의되지만 간단한 줄글로 적으며 이를 디자이너가 디자인 파일에 옮겨 그리며 코멘트를 적는다. PO 체계에서의 디자이너 롤은 내가 기획자로서 상상했던 것 이상으로 넓었다. 디자이너와 함께 분석도 하고 아이디어도 짠다. 의미 있는 데이터가 나오면 꼭 디자이너에게 공유해서 이 데이터를 고려한 디자인 결과가 나오게 하는 것도 중요한 일이다.
|둘째, 성공척도
기획자의 경우 성공여부는 내 프로젝트를 주어진 기간 내에 주어진 리소스로 얼마나 정확하게 끝마쳤는지가 중요했다. CTR(click through rate)이나 목표한 성과를 측정하긴 했지만 프로젝트가 끝나고 나서 한 번 정도 측정하고 끝이었다. 즉 프로젝트를 얼마나 계획에서 벗어나지 않게 리소스대로 사용했느냐가 성공여부를 판단하는 척도가 되었다. 최근 점점 더 프로젝트를 시작하기 전에 성과를 예측하여 진행여부를 결정하려는 움직임이 있지만, 내 경험 상 한 번 프로젝트를 진행하기로 결정한 이상은 얼마나 결과가 좋은 지는 크게 의미 있지 않았다.
반면 PO는 프로젝트는 아무래도 좋았다. 끝마치지 못해도, 리소스가 많이 들어도 상관 없다. 나에게 주어진 지표를 높였냐가 유일하게 의미 있는 성공지표다. 지표를 높이기 위해서 나는 이런 저런 고객문제를 발견하고 문제가 타당한 지 밝혀서 내 지표를 높일 수 있을 때만 진행한다. 지표를 높일 수 없다면 아무리 예쁜 화면이 만들어진대도 리소스낭비일 뿐이다. 그러다보니 내 프로젝트를 진행하기 위해 리소스를 끌어오고 요청하고 설득시키는 일 또한 중요하다. 누가 나에게 프로젝트를 내려주는 것이 아니라 내가 밀고 나가는 것이기 때문이다.
|셋째 MVP
위와 같은 성과측정방식은 MVP(애자일)와 워터폴 업무방식으로 이어진다.
서비스기획자의 프로젝트 기준으로 성과를 측정하는 방식은 한 번에 큰 덩어리의 프로젝트를 기획하고 많은 개발인원이 오랜 기간에 거쳐 한 개의 프로젝트를 배포하는 방식이다. 덩어리가 크고 한 번 릴리즈할 때 완벽한 모습의 결과를 모든 디바이스에 한 번에 적용한다. 대부분 상부와 유관부서에서 안건을 받아 어떤 프로젝트를 진행할 지 결정하고 추진한다. 상부에서 찍어내려서 프로젝트를 진행하면 추진력은 좋지만 결과를 알기도 전에 많은 리소스를 이미 투입해 버리기에 리소스 관리 측면에서 위험부담이 크다.
반면 PO의 목표는 메트릭을 높이는 것이기 때문에 프로젝트가 메트릭을 높이는 지를 면밀히 주시한다. 최소한의 리소스를 써서 MVP(Minimal Variant Product)만을 먼저 릴리즈한다. 만약 처음부터 기능을 추가하면 "이거 MVP 맞나요?" 라는 답을 듣는다. 먼저 고객문제에 대한 가설이 유효한 지를 확인하는 테스트가 필수다. 최소한의 기능으로 최소한의 디바이스에 배포한 후 A/B테스트를 하며 가설이 정말 성과가 있는 지 지켜본다. A/B테스트를 통해 개선된 피쳐가 현재보다 성과가 난다는 것이 판단되면, 다른 피쳐도 추가해서 살펴보고 이후 디바이스 범위를 늘린다. 안드로이드에 반영된 것이 iOS에 반영되지 않기도 하고 모바일에는 반영된 것이 PC에는 반영되지 않기도 한다.
이런 차이로 인해 기획자였던 내가 PO로서 일하면서 가장 크게 적응이 필요한 곳은 두 가지다.
|첫째, 문제 정의
문제정의는 다음과 같은 구성으로 이루어 진다.
1. problem statement / Jobs to be done (optional) / Root cause / Observation (데이터 등)
요 문제정의를 간결하고 명확하게 해본 적이 없었길래 처음에는 이것부터 난항을 겪었다. 모든 1-pager에 필수로 들어가는 것이었고 고객문제를 잘못 정의하면 의도한 결과가 나올 수 없기에 예리하게 접근한다. 나는 처음에 이것 못 해서 다른 분들이 한 것을 엑셀 시트에 쭉 다 정리해서 분석하고 나의 것으로 만들어 보기도 했다. 덕분에 아직 서툴긴 하지만 이전보다 훨씬 나아진 problem statement를 하게 되었다.
|둘째, A/B 테스트
기획자로서 A/B테스트도 겪어본 적이 없었기에 낯설었다. 그런데 PO로서는 A/B 테스트만큼 중요한 것이 없었다. 결과를 보고 원인을 분석하기도 하고 이를 보고 프로젝트를 더 진행할 지, 진행한다면 어떤 부분을 보완할 지를 판단하기도 한다. A/B 결과를 가지고 열띤 토론이 이어지기도 하고 프로젝트의 성과를 판단하는 가장 명확한 지표가 된다. 이 A/B 테스트 결과를 읽는 것이 나는 아직 어렵고 다른 사람들이 한 프로젝트를 보며 분석해보려 하고 있다.
내가 익혀야할 것들이 명확하고 PO는 기획자에 반해 뚜렷한 성과로 능력이 측정되기에 모티베이션이 확실하다. 아직은 힘들지만 나자신 월요일도 힘내자
