사회초년생은 좌절할 시간이 없어요 EP2-1
'기획자로서 첫 업무를 진행하고 피드백을 받느라'편
팀에 합류한 지 2주 차가 되었을 때, 나는 모든 팀원들에게 공유되는 지표 내용을 작성하게 되었다. 그리고 내부 확인 용 릴리즈 노트 노션 페이지를 제작하게 되었고, Carrying Capacity와 유입 채널, 운영 체제 별 이탈률을 분석하게 되었다. 고작 2주가 지난 시점이었는데.
업무를 전달받은 내 모습. 이거 제가 해도 되는 건가요? 거짓말,,,지금 생각해도 굉장히 무모(?)했던 것 같다. 물론 팀원들은 내가 해낼 줄 알았다고 말하시지만, 해내든 말든 어쨌든 2주 된 신입에게는 조금 버거웠던 기억이다. 당연히 그 기간 동안 나는 폭풍 성장을 했다고 느끼지만, 언제나 성장은 고통을 동반하는 법. 사실 글을 쓰는 시리즈의 제목과는 달리 쓰디쓴 좌절감을 맛보았다. 그러나 그 감정에 오래 얽매일 순 없었다. 또 다른 일들이 밀려왔으니까!
오늘은 각각의 맡았던 업무에 대해 간단히 이야기하면서 배운 점, 느낀 점 등 회고를 중심으로 이야기를 써보려 한다. 모든 스타트업, 기업이 우리 팀과의 환경과는 똑같지 않을 것이다. 그렇지만 이런 스타트업도 있고, 그 환경 속에서 내가 어떻게 성장하고, 좌절감을 극복했는지에 대해 포커스를 맞추어 주길.
1. 지표를 분석하고 내용을 작성해서 매일 아침 팀 전체에게 공유하기
우리 팀은 애자일이라는 소프트웨어 개발 방법론 사용하고 있다. 시시각각 변화하는 외부 환경에 더 빠르게 적응하고 맞춤 서비스를 제공하기 위해 특정 기간 동안 반복적인 개발을 진행하는 방법론이다. 특이한 점은 매일 오전 팀원들이 한 자리에 모여 1) 어제 한 일, 2) 오늘 한 일 3) 발생한 문제에 대해 함께 이야기한다. 이 방식을 우리 팀에서는 데일리 스크럼이라 칭하며 기본 내용과 더불어 매일 지표를 공유한다.
기존 기획 챕터의 리소스 부족으로 인해 운영 챕터에서 꽤 오랜 기간 대신 지표 공유를 해주셨었다. 나의 합류를 기점으로 원래의 주인에게 지표는 돌아왔다. 기획 챕터 내부에서도 지표를 공유하는 방식에 대한 고민이 필요한 시점이었기 때문에 당시 3명이었던 기획자들이 로테이션 형식으로 1주씩 진행하기로 했다. 그런데, 내가 처음이라니??
기획 챕터 회의 중 지표 공유를 담당하게 된 나의 모습나는 재차 묻고 말했다."이거 정말 제가 해도 되는 건가요? 제가 잘못 전달하면 어쩌죠? 저는 못 하겠어요. 이게 맞는 건가요?"라며,,, 팀원들은 한 번 시도해보라고 하셨고, 충분히 해낼 수 있다고 말했다. 지금에서야 되게 많은 응원을 받았다고 느껴지지만, 그때 당시에는 아무것도 들리지 않았다. 분명 온보딩 기간이긴 하지만 그 업무 자체는 실전이었으니까.
내가 처음으로 담당한다는 것에 꽤나 많은 부담감을 느꼈다. 하지만 지금 생각해보면 오히려 좋은 시도였고 경험이었다. 예시가 없기 때문에 틀에 박히지 않을 수 있었고, 포맷에 얽매이지 않고, 또 나의 장점은 높은 스탠다드로 꽤나 디테일한 지표 분석과 내용 전달을 시작할 수 있었다. 내가 한 분석과 결과물이 추후에 공유되는 내용들의 기본 스탠다드가 된 것이다. 물론 높은 스탠다드 때문에 꽤나 애를 먹었지만.
지표 내용 주제는 활성 사용자 증감으로 보는 활성도 분석, 유저 1인 당 사용 시간 변화 분석, 마케팅 전환당 단가 추이 확인, 푸시 발송 건수 분석 등등 지금 다시 확인해봐도 아주 다양한 내용이 있었다. 이 내용을 전달하기 위해 초반에는 하루에 최소 1시간 정도의 시간이 필요했다. 당시에는 다행히도 온보딩 기간이었기에 시간을 할애할 수 있었다.
심리적으로 아주 부담이 되었다. 실제로 잘못된 정보를 전달해서 급하게 수정 내용을 전체 메시지로 전달한 적도 있다. 그러나 실수를 할 때에는 팀원들이 빠르게 확인해서 알려주어서 고맙다는 말을, 그리고 변경된 지표 전달 방식에 많은 인사이트를 알 수 있었다는 피드백이 그 간의 긴장감을 한 순에 풀어주었다.
그리고 무엇보다 중요하게 하나도 이해되지 않았던 GA, Datastudio에 단 한 주만에 완벽 적응해 실제로 다른 챕터 멤버께서 요청하신 지표도 뚝딱 제작해 제공해드릴 수 있었다. 역시 어떤 것이던 실제로 해보는 게 가장 빠르게 학습할 수 있다는 것을 새삼 느꼈다.
단 5일이었지만 너무나도 길고 쉽지 않았다. 그럼에도 불구하고 꽤나 성공적으로 업무를 진행했다고 생각한다. 그 후로도 지표와 데이터 분석은 꾸준하게 진행 중이고, 지표를 전달하는 방식도 구체화되어 안정적으로 운영 중이다.
2. 지표 분석을 위해 내부 확인 용 릴리즈 노트 페이지를 제작하다.
지표 분석을 하다 보니 원인 분석을 통해 가장 큰 인사이트와 넥스트 액션을 제시할 수 있었다. 하지만 내부적으로 어떤 이벤트가 일어났는지를 한 곳에 기록한 자료가 없었다. 따라서 매번 슬랙 검색, 노션 검색을 통해 날짜를 확인해 인과관계에 대한 추측을 해야 했다. 앞으로도 지표 내용에 대한 공유가 될 예정이라면 내부 확인 용 릴리즈 노트는 기본적으로 갖춰져있어야 했다.
그래서? 만들었다. 누가? 합류한 지 2주가 된 내가! 여전히 모두가 쓸 노션 페이지를 만들어보라는 게 당황스러웠지만 이전보다는 더 자신감을 가지고 "제가 해보겠습니다"라고 말했다.
그래도 한 결 나아진 내 모습.지표에 가장 큰 영향을 주는 것에는 우선적으로 개발 릴리즈와 마케팅 이벤트가 있다고 판단되었다. 각 이벤트마다 필요한 정보에 대해 리스트업을 하고 보니 실제 속성으로 작성할 수 있는 관련 정보는 운영 체제를 제외하고는 동일하다고 판단되었다. 우선적으로 실제 케이스를 활용해 예시를 작성해보며 속성을 추가/수정/삭제해 나갔고, 1차적으로 팀원들의 피드백을 받았다. 이벤트 유형을 태깅으로 분리했지만 노션에 제공되는 표 분리를 통해 각 표마다 단일 이벤트 형태만 제공할 수 있도록 수정했다. (이 경험을 기반으로 하나의 데이터 베이스를 활용하며 정보의 분산은 막되 실제 사용자에게 필요한 정보만 제공할 수 있을 때 본 포맷을 유용하게 활용하고 있다)
14개의 백링크가 걸릴 정도로 잘 활용되고 있다!이후 페이지 작성 규칙과 템플릿을 제작했다. 페이지 작성 규칙에는 이 릴리즈 노트를 제작한 배경, 생소했던 표 분리에 대한 안내, 템플릿 사용 방법, 작성 방법 (공통 설명과 각 챕터 별 설명)에 대해 이미지와 텍스트를 활용해서 작성했다. 본 내용에 대해서는 실제 노션 페이지를 사용해야 하는 개발자분들께 피드백을 요청드렸다.
이후로도 여러 피드백을 통해 수정과 수정을 거쳤고, 여러 번의 리마인드로 이제는 이벤트 발생 = 릴리즈 & 이벤트 페이지에 작성이 되었다. 추가로 예상치 못하게 발생한 이슈에 대한 내용도 함께 기재되고 있다.
이때 받은 피드백 중 기억에 남는 것은 목표로 했던 기획 챕터가 지표 내용을 분석하는 데에 활용하는 것 외에도 개발자분들도 함께 기록을 관리하며 내부적인 리소스를 줄일 수 있어서 너무 좋았다는 내용이다. 템플릿이나 작성 방법, 그리고 제작 배경도 잘 설명이 되어 있어 처음 사용하는 사람도 쉽게 작성을 할 수 있다는 피드백도 기억에 남는다.
이 업무를 진행하면서 "왜?"에 대한 생각이 중요한 지를 깨닫게 되었다. 상대가 누구든 이 일을 "왜?" 해야 하는지에 대해 이해가 된다면 절반은 성공이라고 생각한다. 실제로 '제작 배경'에 기획 챕터에게 돌아오는 이점뿐만 아니라 팀 전체적인 기록 관리 리소스 감소에 대해 언급하였고, 이 부분이 개발 그리고 마케터 분들께서 이 문서를 활용할 수 있게 된 큰 이유라고 생각한다.
이후로 "왜?"에 대한 생각이 점점 지배되고 있다. 물론 기획자로서는 참 좋은 사고의 방식이라고 생각한다. 다만, 실생활에서도 "왜?"를 남발해 조금은 T 같아 보이기도 하지만,,, (원래는 F)
이렇게 두 번째 업무도 잘 마무리되었다. 그러나 마지막 세 번째 업무에서 내 멘털이 와장창 깨졌다.
이 사건은 바로...
사회초년생은 좌절할 시간이 없어요 다음 편에 계속!
