입사 1년 뒤에 찾아온 슬럼프
유정의 이야기(3) - 데스밸리(위기)
입사 1년 뒤에 찾아온 슬럼프
스타트업에서의 처음 몇 개월간 맡았던 일은 영어 서비스의 고객 문의 응대부터 이벤트 및 마케팅 기획, 콘텐츠 퀄리티 관리, 번역, 사용자 설문조사, 해외 시장 리서치에 이르기까지 광범위했다. 영어로 서비스를 오픈했지만 주로 타게팅하는 국가는 인도였는데, 영어 서비스를 담당하는 사람이 한두 명밖에 없었을뿐더러 인도에 대해서 잘 아는 사람이 아무도 없었기 때문에 '맨땅에 헤딩'할 수밖에 없었다. 앱을 쉽게 깔고 쉽제 삭제도 하는 인도 학생들에게 앱을 광고한다면 어떤 느낌으로 만들어야 할까, 앱을 설치한 다음에도 꾸준히 쓸 만한 서비스로 느끼게끔 하려면 어떤 점을 개선해야 할까, 어떤 이벤트를 해줘야 학생들이 많이 참여할까... 이 질문들에 대한 답을 얻기 위해 인도 플레이스토어에서 인기 많은 앱을 다운 받아서 써보고, 인도 인기 유튜버와 인스타그램 인플루언서를 구독하며 콘텐츠를 보는 등 최대한 인도 학생으로 빙의를 하려고 했다.
이후에는 맡았던 직무를 다른 분께 인수인계하고, 서비스의 핵심인 수학문제 데이터베이스를 쌓는 프로젝트를 진행했다. 수학문제를 풀어줄 알바생들을 인도에서 구인하고, 어떤 문제를 풀지 분배하고, 풀이가 완성되면 그것을 검수하는 프로세스를 만들고, 프로젝트에 참여한 사람들의 보상 체계를 만들고 정산하는 것. 목표한 데이터베이스를 주어진 시간 안에 쌓기 위해 200명이 넘는 알바생들의 작업 진행상황을 관리하고, (중도 이탈하거나 문제풀이 퀄리티가 기대 미만인 사람들이 끊임없이 생겨났기 때문에) 계속해서 새로운 알바생들을 구하고, 프로젝트 관련 문의를 응대하는 고객센터 역할까지 하며 3개월의 시간이 순식간에 지나갔다.
데이터베이스 프로젝트가 끝나갈 무렵 나는 꽤 지쳐있었다. 업무를 도와주는 파트타이머 분이 계셨지만 엄청난 양의 데이터베이스를 쌓는 일을 책임지며 대부분의 실무를 혼자서 맡다보니 체력적으로도 정신적으로도 한계가 오기 시작했다. 내가 스타트업을 첫 직장으로 선택하면서 긍정적으로 생각했던 '자율도 책임도 큰' 환경이 '외롭고 혼란스러운' 환경으로 느껴졌다. 무엇보다도, 내가 하는 일에서 보람과 흥미를 더 이상 느낄 수 없었다.
오피스에서 허망하게 밖을 바라보는 모습지난 1년간의 생활을 돌아보았다. 나는 왜 지쳤나?
첫번째로는, 일하면서 같이 상의하고 업무를 분담할 다른 팀원이 없다는 것이었다. 두번째로는, 담당하는 업무가 점점 반복되는 루틴의 연속이 되어갔다는 점이었다. 세번째로는, 내가 들인 노력의 결실이 가시적으로 드러나지 않는 것에 대한 답답함이었다. 결국 다른 팀원들과 활발하게 협업할 기회가 있고, 새로운 업무를 주기적으로 할 수 있으며, 성과를 더욱 가시적으로 확인할 수 있는 일이 내게 필요했다.
돌이켜보면 데이터베이스 프로젝트를 진행하면서 틈틈이 기획 업무를 시도해볼 기회들이 있었다. 예컨대, 다른 교육업체와 파트너십을 맺어 수급해온 좋은 퀄리티의 콘텐츠를 앱에 출시하는 일이나, 영어 서비스의 신규 사용자 온보딩 과정을 바꾸는 일이었다. 아무런 사전 경험도 지식도 없이 해보는 일이었기에 과정이 순탄치는 않았다. 기획은 구멍투성이었고 개발자와의 소통이 서툴러 우왕좌왕했다. 하지만 돌이켜보면 기획을 완성해나가고, 개발자와 합을 맞춰 나가고, 출시 후 앱에서 눈으로 결과물을 직접 확인하는 것은 스타트업에서 일하며 느낀 가장 큰 보람이었다. 기획 업무를 side가 아닌 주요 업무로 가져간다면, 내가 지금 시점에서 지쳤다고 느끼는 이유를 해결해줄 수 있는 방법이 될 수 있을거라 생각했다.
매뉴얼도, 사수도 없었던 환경
내가 원래 속한 팀은 Global Business를 담당하는 운영 및 사업개발 조직이었다. 직무 변경을 고민하면서 자연스럽게 사업개발보다는 개발자와 디자이너가 모여있는 제품 조직으로 팀을 변경하게 되었다. 당시 전사적으로도 조직 개편이 같이 일어나는 시기였고, 단순히 어떤 기능에 대한 상세 기획을 짜는 기획자가 아니라 데이터와 사용자 인사이트를 기반으로 제품에 대한 전략을 세우고 새로운 기능 개발 전반의 과정을 이끌 수 있는 PO라는 직무가 신설되던 때였다. 내 명함은 Global Business Manager에서 Product Owner(PO)이라는 이름으로 바뀌었다.
팀도 직무도 바꾸면서 새로운 종류의 스트레스가 찾아왔다. 일에 대한 매뉴얼도, 나를 담당해서 업무를 가르쳐줄 사수도 없었다. 물론 서비스 운영과 데이터베이스 프로젝트를 했을 때도 크게 다르지는 않았다. 그 때는 어떤 일을 어떻게 해야 할지에 대한 계획을 세울 수 있었고 그 과정에서 일어나는 크고 작은 어려움들을 감당하고 해결방법을 모색하면 되는 일이었다. 하지만 PO라는 업무는 어떤 일을 어디서부터 시작해야할지 감을 잡는 것조차 어려웠다.
이전에 기획과 제품 관리를 담당하던 사람들은 있었기에 그들이 작성했던 기획 문서를 찾아보고 슬랙 채널에서 오고가는 내용을 읽으며 업무를 제대로 파악하기 위해 노력했다. 다른 PO가 진행하는 프로젝트 회의에 참여하며 대화를 이해하려고 귀를 기울였다. 제품의 여러 가지 기능과 컨텍스트 파악에 필요한 자료가 없으면, 내가 문서를 만들고 팀원들과 공유했다. 회사가 원하는 사람은 가르쳐주지 않아도 알아서 빠르게 배우고 적응하고 성과를 낼 수 있는 사람이었다. 내가 가진 욕심이기도 했다. 회사의 기대와 나의 욕심에 부응하기 위해 스스로에게 압박을 주는 시기가 이어졌다.
뼛속 문과생이 개발자, 디자이너와 대화하는 법을 배우기까지
주니어 PO로 첫 발을 내딛으며 가장 크게 부담으로 느꼈던 것 중에 하나는 개발과 디자인에 대한 생소함이었다. (회사마다 PO의 역할은 조금씩 다르지만,) 기본적으로 PO는 매일매일 개발자와 디자이너와 커뮤니케이션을 해야 하는 직업이다. 어떤 제품이나 기능에 대한 전반적인 방향성과 반드시 필요한 주요 기능을 정하면, 그것을 토대로 디자이너와 같이 상세 기획과 사용자경험(UX)을 설계한다. 상세 기획 및 디자인이 어느 정도 확정되면 개발자와 QA 팀과 그것을 공유하고 해당 기능의 개발을 진행시킨다. 개발이 진행되면서 기획을 추가, 수정하거나 빼야 할 일이 생기는데 그에 대해 팀원들과 논의하고 의사결정을 내린다.
이렇게 커뮤니케이션이 많이 필요한 것에 비해, 나는 개발이나 디자인에 대한 아무런 배경지식이 없는 상태였다. API, DB 구조, 바텀시트, 드롭다운, ... 팀원들과 대화하면서 생소한 용어들이 나올 때면 우선 들리는대로 적어두고, 나중에 검색해보거나 관련 책을 읽으면서 개념을 익혔다.
노션에 정리한 개발 관련 개념들너무 기본적인 것들을 모른다고 말하기 부끄러워서 혼자 힘으로 기본 지식을 쌓으려 하다 보니 당연하게도 멘땅에 헤딩하는 시간들이 많았다. 개발이나 디자인 온라인 기초 과정을 등록해 강의를 들어보면서 '내가 어디까지 알아야 하는 걸까'하는 고민을 끊임없이 했다. 나중에는 효율적이지 못한 방법으로 혼자 스트레스를 받으며 낑낑대느니, 남이 나를 어떻게 생각할지 걱정하지 말고 용기를 내어 물어보는게 낫겠다는 생각이 들었다. 그렇게 모르는 것은 모른다고 솔직하게 말하면서 하나씩 배워가니 어느 순간부터는 대화할 때 느꼈던 멘붕과 부담감이 조금씩 사라지기 시작했다.
몇 개월이 지나며 깨달은 것은 결국 PO로서 역할을 제대로 하는 것이 중요하고, 개발이나 디자인 지식에 대한 전문성이 없다고 해서 그것을 보완하기 위해 매달릴 필요가 없다는 점이었다. 물론 개발이나 디자인 지식이 풍부하면 메이커들과 함께 대화하는 것이 더 수월하고 작업에 대한 피드백을 줄 때에도 더 나은 의견을 제시할 수 있다. 하지만 그보다 더 중요한 것은 메이커들이 크고 작은 기능들을 왜 만들어야 하고, 왜 이런 방향으로 만들어야 하는지를 잘 이해할 수 있도록 먼저 충분히 고민하고 설득하는 것이었다. 하나의 쟁점에 대해 너무 여러 가지 의견이 나와서 혼란스러울 때면 그 상황을 정리하고 최종 의사결정을 내릴 수 있는 강단도 중요했다. 개발이나 디자인에 대한 전문적인 피드백보다는 우리가 설정한 방향성에 맞는 것인지, 꼭 필요한 것인지, 지금 진행하는 방법이 최선인지에 대해 잘 커뮤니케이션하는 것이 PO로서 할 일이었다.
