뜬 구름 잡는 소리도 좋아해 준다면
주니어 PM 성장기 #5
사람은 적응의 동물이라는 말은 진리다.
어느새 입사한 지 한 달을 바라보고 있고, 처음으로 정규직으로서 월급도 받아봤다.
매일 회의에 참석하다 보니 이제는 회의와 업무가 어떻게 굴러가는지 슬슬 이해되기 시작했다.
외계어 같던 용어들도 매일 듣다 보니 뭘 뜻하는지 알게 되었고, 회의에서 작은 의견을 낼 수 있는 용기도 생겼다. (아직 내가 낸 의견이 받아들여진 적은 한 번도 없지만...)
회사는 학교처럼 나를 가르치려 드는 곳이 아니기 때문에 나에게도 금방 업무가 밀려들었다.
물론, 아무것도 모르는 신입이라는 점을 다들 알고 있었기 때문에 급한 업무를 주지는 않았다.
하지만, 신입 입장에서 진행하기에 버거운 업무임은 분명했다.
"아직 혼자 완벽하게 진행하기에는 어려운 업무일 거예요. 그래도 한번 최선을 다해봐요."
사수 분이 업무를 던져주며 했던 말이다.
PM은 생각하는 일을 도맡아 진행한다.
나는 생각하는 것 하나만큼은 자신 있었다.
그래서 호기롭게 주어진 업무를 시작해봤지만, 예상보다 훨씬 어렵고 힘든 일이었다.
저번 글을 통해 언뜻 말했다시피 우리 회사는 구독 서비스 배포를 앞두고 있다.
그 틈에서 내게 주어진 첫 업무는 엔터프라이즈 플랜에 대해 조사하고, 배포 예정인 서비스에는 어떻게 반영할 수 있는지 고민하는 일이었다.
사실, 첫 업무는 그렇게까지 어려운 일이 아니었다.
단순히 다른 서비스들을 조사해보고 내 나름대로 논리만 잘 세워서 정리하면 되었기 때문이다.
다행히 내가 생각하고 정리한 기획안은 리뷰 후에 컨펌되었다.
문제는 다음 업무였다.
지금 배포를 앞둔 구독 서비스는 Freemium 가격 전략을 사용한다.
(Freemium : 프리(free)와 프리미엄(premium)의 합성어로 기본 서비스는 무료로 이용할 수 있도록 하고, 부가 서비스나 고급 서비스는 유료화하는 가격 전략을 말한다.)
Freemium 가격 전략을 사용하기 위해서는 유료로 제공하고자 하는 기능을 각 타겟에게 어느 정도로 제한할지를 세심하게 고려해야 한다.
예를 들어, 피그마의 경우 무료 계정은 프로젝트를 3개까지 만들 수 있고, 그 이상의 프로젝트를 만들기 위해서는 유료 플랜을 사용해야만 한다.
또한, 피그마는 프로젝트 제한뿐만 아니라, 작업 내역 저장, 팀원 추가 등의 기능에서 제한을 두고 있다.
서비스 기능 제한은 유료 전환율을 높이기 위한 중요한 정책 중 하나다.
따라서, 각 기능 제한 범위는 매우 세심하게 정해야만 한다.
만약 제한 범위가 너무 크다면 무료 사용자에게 큰 불편을 주게 되어 서비스 사용량 자체가 떨어질 수 있고, 제한 범위가 너무 작다면 무료 사용자만 늘어나고 유료 전환율을 크게 낮아질 수 있다.
따라서, 기능 제한은 각 기능별 기존 유저 데이터 및 예상 사용 데이터를 고려하여 결정하게 된다.
내게 주어진 다음 업무가 바로 각 구독 플랜별 기능 제한 수치를 제시하는 것이었다.
데이터를 제대로 보는 법도 모르고, 예상 사용량을 예측하는 방법은 더더욱 모르는 상태에서 내가 할 수 있는 일은 그다지 많지 않았다.
그나마 다행인 것은 경쟁 서비스가 있기 때문에 벤치마킹할 대상이 존재한다는 점이었다.
하지만, 벤치마킹을 통해 제시한 수치에는 논리와 근거가 있어야 한다.
그러기 위해서는 벤치마킹한 서비스가 기능 제한 수치를 왜 그렇게 설정했는지 파악하는 것이 우선순위였다.
앞서 말했듯이 기능 제한 수치는 주로 데이터를 기반으로 세심하게 설정된다.
벤치마킹하는 서비스도 분명 유저 데이터를 분석한 결과를 바탕으로 기능 제한 수치를 설정했을 것인데, 단순 유저 입장에서는 벤치마킹 서비스의 내부 데이터를 파악할 수 있을 리 없었다.
그러다 보니, 내가 할 수 있는 일은 '추측', '가정'이 전부였다.
일부 기능 제한 수치는 작게나마 유저 데이터를 반영하기도 했지만, 대부분은 벤치마킹 서비스를 기반으로 추측하여 논리를 세우고 수치를 제시하게 되었다.
대부분의 논리가 추측을 바탕으로 세워지다 보니 누가 보더라도 논리에 허점이 많았다.
쓰는 도중에도 논리에 문제가 있는 것을 알았지만, 내가 가진 역량으로는 그 이상의 논리를 제시할 수 없다는 사실에 절망스럽기까지 했다.
뭐라도 해보려 발버둥 치고 있지만 결국 뜬 구름 잡는 소리만 하고 있는 꼴이었다.
하루하루 업무를 끝마쳐야 하는 시간이 다가올수록 스트레스는 커져만 갔다.
의미 없는 야근을 하면서까지 기획안을 써 내려갔지만, 퇴근 전에 쓴 부분을 읽어보고는 현타가 와서 결국 다시 백지로 만들고 퇴근하는 날이 허다했다.
그렇게 내게 주어진 시간은 하루가 남아있었고, 내 생각을 180도 돌려놓은 작은 일이 생겼다.
기획안은 위키로 쓰고 모두에게 공유하기 때문에 내가 작성하고 있는 기획안은 언제든지 누구라도 자유롭게 읽어볼 수 있다. (이런 점이 기획안을 쓸 때 더 부담되기도 한다.)
다음 날 기획안을 리뷰하기로 예정되어있었고, 오후에는 쭉 미팅이 예정되어있었기 때문에 논리가 부족하더라도 오전 중에 기획안을 어떻게든 완성해두었다.
길고 긴 미팅 이후 퇴근시간이 얼마 남지 않은 상태로 자리로 돌아와 마지막 마무리를 위해 기획안을 다시 살펴보았다.
그런데, 한 번도 울리지 않았던 위키 알림에 '1' 표시가 있었다.
신입이기도 하고, 내가 하는 일은 급한 일이 아니었기에 알림이 올 일은 전혀 없을 것이라고 생각했었는데 알림이 와 있어서 신기한 마음에 한번 눌러보았다.
여태 한 번도 울리지 않았던 내 위키 페이지의 첫 알림 주인공은 대표님의 좋아요였다.
그것도 내가 그동안 자신 없어하던 바로 기능 제한 수치 관련 기획안에 좋아요를 눌러주셨다.
대표님이 눌러준 좋아요는 믿을 수 없게 큰 용기가 되었다.
스스로 논리가 부족하다는 생각에 자신감은 점점 잃어만 갔고, 내가 월급을 받으면서 이렇게 일해도 되는 것인지, 대학생 수준에서 멈춰버린 것은 아닌지 걱정만 쌓여가던 찰나에 대표님께서 좋아요를 눌러주신 것이었다.
아마, 대표님은 내용을 읽어보았다기보다 단순히 '신입이 이런 일을 하고 있구나'의 정도로 둘러보시고 좋아요를 누르신 것이 전부일 것이다.
하지만, 내게 있어서는 누군가의 좋아요가, 특히나 대표님의 좋아요는 너무도 소중했다.
앞으로 주니어 PM 업무를 진행하면서 수많은 기획안을 작성하게 될 것이고, 아마 뜬 구름 잡는 소리가 90% 이상을 차지할지도 모른다. (그렇다고 뜬 구름 잡는 소리만 계속하겠다는 말은 아니다.)
그래도 내가 뜬 구름 잡는 모습이 누군가에게는 좋아 보이기만 한다면 멈추지 않을 수 있을 것 같다.
그만큼 내가 성장해나간다는 뜻이라고 스스로 받아들일 수 있기 때문이다.
아직 어느 스타트업에 가더라도 인정받는 PM으로 거듭나기에는 많은 난관과 어려움이 남아있겠지만, 목표를 향해 나아가는 용기를 놓치지 않는다면 도착할 수 있을 것이라고 믿고 있다.
비록 지금은 주니어이기에 뜬 구름을 잡고 있지만, 나중에는 근두운이라도 타고 다녔으면 좋겠다. (이게 무슨 말이람!!)
