사회초년생은 좌절할 시간이 없어요 EP3
'첫 번째 프로덕트인 일기 기능을 만드느라'편
폭풍 같은 온보딩 기간이 끝나가면서 나는 드디어 '기획 다운 기획'을 시작할 수 있었다. 온보딩 기간 동안 팀의 주요 서비스에 대해 알아보는 기간을 가졌기 때문에, 그 이해도를 바탕으로 우선 개인적으로 서비스에 추가되면 좋을 기능을 생각해냈다.
커뮤니티가 내재된 서비스였기 때문에 다양한 아이디어 중 당장 필요한 기능으로 인앱 알림과 게시글 임시저장이 선택되었다. 하지만, 인앱 알림은 당시 FCM (Firebase Cloud Messaging - Android, iOS 및 웹 애플리케이션용 메시지 및 알림을 위한 크로스 플랫폼 클라우드 설루션)과 플러터 버전 업데이트가 필요해서 기획 단계에서 중단되었으며 게시글 임시저장은 필요한 데이터를 모으기 위해 GA 이벤트를 새롭게 삽입하고 확인하던 중 새로운 스쿼드에 배정받게 되면서 중단되게 되었다.
두 기획은 당시에는 개발로 이어지지 않았지만, 임시 저장은 내 기획을 바탕으로 새롭게 기획 및 개발이 진행되어 실제 현재 프로덕트에 있는 기능이다. 그리고 곧 두 번째로 배정받은 스쿼드에서 인앱 알림은 내 기획을 기반으로 직접 내가 기획자로 기능 개발이 진행될 예정이다. 두 기획을 작성하는 당시에는 초보 기획자였던 나에게 많은 깨달음과 배움을 얻었었다.
특히 본 기획과 기능의 필요성을 잘 전달하기 위해 데이터를 분석하고, 사용자의 의견을 찾고, 추가로 필요한 정보를 위해 클라이언트 개발자와 작업을 진행하였다. 결국은 기획의 당위성을 증명하기 위해 사고부터 실제 행동까지 진행하며 기획에 첫 발을 담근 셈이다. 특히, 게시글 임시 저장은 회사 내 문의 창구에서 다수의 사용자로부터 확인할 수 있었던 의견이었다. 그러나, 당시에는 게시글 작성 페이지에서 발생하는 이탈의 빈도수에 대해서 알 수가 없었고, 클라이언트 개발자에게 GA 이벤트 추가를 요청했다. 그때에는 단순히 빈도수로만 확인하려고 했지만, 지금 생각해보면 빈도수뿐만 아니라 게시글 작성 페이지에서 체류하는 시간 또한 같이 확인한다면 본 기능의 당위성을 더 객관적으로 전달할 수 있을 것 같다는 생각이 든다.
또 하나 깨달음을 얻었던 부분은 당시 인앱 알림 기획을 가지고 커뮤니티 PO와 논의를 통해서 받았던 피드백 중 케이스에 대해서 더 깊이 그리고 디테일하게 고민하는 것과 작업 범위를 조정하는 것이다. 단순히 인앱 알림을 받는 것에 대해서 고민했었던 초기 기획에서 결국 인앱 알림이 과도하게 오는 케이스는 사용성 저하로 인한 사용자의 불편함을 생성할 수 있다는 코멘트를 받았다. 또한 인앱 알림을 설정하게 하는 부분이 없다는 것도 알게 되었다. 하나의 단순한 기획이라도 정말 세세하고 상상 이상의 케이스가 발생할 수 있다는 것을 처음으로 체감하게 된 순간이었다. 그리고 또 하나 중요한 부분은 개발자와 의사소통 시 키포인트인 작업 범위, 즉 스콥에 대한 이야기였다. 단순히 하나의 기능은 한 번에 개발이 된다고 생각했지만 인적 그리고 시간적 자원의 한계 때문에, 혹은 기능의 복잡도 때문에 작업자들은 가장 작은 범위의 작업을 우선 진행하는 것을 선호한다는 사실을 알게 되었다(물론 이는 우리 팀의 특성일 수도 있다). 그리고 무엇보다 그렇게 작은 범위의 작업이 팀이 추구하는 '애자일'에 더 가깝다는 것도 알게 되었다.
비록 두 기획을 기반으로 바로 기능 개발에 착수한 것은 아니었지만, 그럼에도 기획서를 작성하고 피드백을 받은 과정에서 너무나 많은 경험과 배움을 얻었다. 그리고 진짜 기획자에 한 발자국 더 가까워진 것 같아서 엄청난 동기부여를 받았던 순간이었다.
스스로 파이팅을 외치던 그때 내 모습온보딩 기간 내내 스쿼드가 없었던 내가 드디어 합류 후 한 달 반 만에 유틸리티 스쿼드의 기획자가 되었다. 당시에는 유틸리티와 커뮤니티 두 개의 스쿼드가 구성이 되어있었다. 유틸리티 스쿼드는 커뮤니티 기능 외로 사용자들에게 편리성을 주는 기능을 개발하는 스쿼드이다. 기본적으로는 다양한 정보를 제공하기 때문에 정보의 정확성이나 정보가 업데이트되는 주기를 위해서 서버(백단)에서 진행되는 작업이 있었고, 기존 기능의 개선과 그리고 신규 기능 개발이 있었다. 팀에서 정말 오랜만에 나오는 신규 기능 개발의 기획자가 되었다.
사수와 함께 아이디어 리스트를 살펴보면서 1) 개발 가능성 2) DAU 증가 3) 유저들이 느끼고 있는 불편함을 해소 이 3가지의 기준으로 평가를 했다. 새로 생성된 스쿼드에서는 주말과 주중 DAU의 편차를 줄이고자 데일리 한 메인 기능을 필요로 하고 있었고, 이는 다른 말로 풀이하면 유저들도 주말에는 서비스를 이용할 가치를 상대적으로 작게 느끼고 있었다고 볼 수 있다. 여러 가지 요인을 종합적으로 살펴보았을 때, '일기'라는 아이템이 선정되었다. '일기'는 다음과 같은 3가지 이유에서 기획 및 개발을 하기로 결정했다.
1. 요일이나 시즌성에 비교적 적은 영향을 받는 데일리 기능
2. 서비스에서 일방적으로 정보를 제공받던 유저들이 본인의 기록을 생성할 수 있는 새로운 기능
3. 커뮤니티를 사용하지 않는 유저들에게 가치를 제공할 수 있는 기능
모든 기능의 시작은 당연히 사용자 중심으로 생각이 되어야 한다. 그러나 사실 빼놓을 수 없는 부분이 이 기능을 통해서 사용자의 만족감이 올라간다면 회사가 얻을 수 있는 이익적인 부분이다. 물론 당시에는 서비스 자체의 BM이 없었지만, 굳이 금전적인 부분이 아니라도 회사가 이 기능을 통해 얻는 부가적인 가치 또한 필수적으로 고려되어야 했다. 특히, 코로나 이후 매일 자가진단 검진을 해야 하는 주요 사용자의 특성상 자가검진 푸시와 기능 제공으로 꾸준히 유지되던 주중 유입이 코로나 완화 그리고 자가진단 제출이 의무에서 선택/권고사항이 되면서 DAU의 감소가 예상되던 상황이었다. 따라서 1번은 회사의 입장에서 충분히 개발을 시도해볼 만한 이유였다고 생각한다.
내가 정말 잘 만들 수 있는, 딱 맞는 기능이라고 생각했다. 우선 내가 일기 쓰는 것을 좋아하고, 기록을 남기는 것에 대한 가치를 정말 잘 느끼고 있기 때문에 사용자에게도 그런 가치를 더 잘 전달할 수 있을 것이라 생각했다. 내가 만들어낼 프로덕트에 대해서, 아니 그 프로덕트가 기반이 되는 것에 대한 애정이 기본적으로 있다는 것은 기획자로서 참 행운이었다.
일기 기능을 만들 생각에 정말 행복했던 나꿈과 희망에 가득 차 기획서를 작성하려고 자리에 앉았지만, 무엇부터 해야 할지 감이 잡히지 않았다. 우선 이전 기획을 작성하던 것처럼 기능이 필요한 이유와 배경에 대해서 정리하기 시작했다. 앞서서 말했던 일기 선정 기준을 기반으로 기능의 필요성을 입증하기 위해 데이터를 모으기 시작했다. 물론, 이번 기획에서도 사용자의 의견도 함께 반영했다. 그리고 본 기획과 이번 작업 범위를 통해 사용자에게 전달하고 싶은 가치에 대해서도 정리했다. 본 기획을 다 개발하고 난 후의 회고이지만 이 상황에서 KPI를 우선적으로 정해보았다면 더 좋은 기획과 프로덕트 완성본과 결과가 있지 않을까 하는 생각이다. 일기 기능을 만들면서 KPI를 실질적으로는 가장 후반부에 기능 홍보를 준비하면서 설정했었다. 그러다 보니 KPI가 달성하고 싶은 혹은 달성해야 하는 목표를 선정한다기보다는 만들어진 기획이 낼 수 있는 적절한 혹은 최대치의 성과를 확인하고 설정하는 느낌이었다. 개인적으로는 KPI를 달성하기 위한 기능보다는 기능이 달성할 수 있는 수치를 설정한 방식이라 성공 가능성이 축소되었던 하나의 요인이라고 생각한다.
정리한 내용을 바탕으로 '일기'를 작성하기 위한 최소 단위의 기능과 요구사항을 정리하기 시작했다. 그러나 문득 들었던 생각은 내가 지금 그리고 있는 '일기'가 기존의 서비스를 대체할 수 있을 만큼 매력적인가라는 의문점이 생겼다. 아무런 셀링 포인트가 없었다. 나 같아도 기존에 잘 사용하고 있는 예쁘고 편한 서비스들을 사용하지 그냥 무난 무난한 이 일기를 쓰지 않을 것이다. 누가 가르쳐주지도 않았지만 정신이 번뜩 차려졌던 순간이었다. 차별점이 없으면 내가 만들 프로덕트는 그저 리소스 낭비의 산출물이 될 거라는 느낌을 받았다.
그렇게 나는 내 첫 프로덕트를 반짝이게 빛나게 할 셀링 포인트에 대해 고민하게 되는데...
스스로 나에게 외쳤던 말사회초년생은 좌절할 시간이 없어요 다음 에피소드에서 계속!
