회사보안상 민감한 기능명과 수치는 공개하지 않습니다
우리팀의 그로스 해킹이 시작됐다. 이제 막 꾸려져 글쓰는 시점으로는 3주째 되는 팀이다. 우선 회사의 MAU 지표나 이것 저것 현황을 확인한다. 어느 부분에서는 상태가 이렇고... 그래도 그 전에 서비스 개발자로서 이것 저것 다 뜯어보면서 얼마나 트래픽이 존재하고, 어떻게 데이터를 전달하는지 알 수 있어서 그나마 쉽게 접근 할 수 있었다.
최근 서비스 플랫폼 팀으로 꾸려진 리드개발자님 덕분에 임팔라가 도입되어 사용자 지표를 빠르고 쉽게 볼 수 있게 되었고, 마케팅과 PO 가 투입되어 든든한 지원군이 생겼다.
가능한 짧고 많은 시간에 많은걸 테스트해 지표를 확인해 목표를 다 부시고 싶었다.
"그로스, 다 뒤졌다"
하지만 항상 뒤지는건 우리였다.!
검증, 실험
어떤 아이템을 해야하나?
이 기능이 어떤 의미로 좋을까. 이 기능은 우리의 MAU를 우상향시켜줄 수 있을까?
모든 스타트업의 고민이다. 아이템 선정은 곧 BM의 선정과도 같다. 우리 서비스는 이미 탄탄한 MAU 생산기능이 있다. 하지만 이 기능의 CC는 현재 지표에서 +-10% 정도로 산출된다. 어떤 기능을 추가해 MAU를 추가하거나, 기능의 순서와 안내를 변경해 기존 MAU를 더 확장시키는 게 모든 스타트업의 목표다.
아이템을 뽑을때, 쓸데없는 고민은 시간만 늦춘다. 하지만 고민을 대충해서도 안된다. 누구나 아이디어는 있지만 그 아이디어가 과연 최선인지, 내가 확신하는 그 기능을 추가해서 우리의 MAU가 오른다는 보장을 알 수 없다. 그중 가장 빠르고, 정확하고, 쉽고, 확실하게 알 수 있는 아이템을 골라야한다. 다해보고 싶지만 우리에게 그렇게 시간이 넉넉하진않다. 월급을 주는 회사도 기다려주지 않는다. 봉사단체가 아니니깐.
성공
첫 테스트로 두가지를 뽑았다. 우선 그로스해킹에 있어 가장 쉽게 이해를 하기위해 크게 두가지 성격의 아이템을 추천했다. 개발량이 있는 것과 없는 것. A 아이템은 작업량도 좀있고, 기획의 와이어프레임양도 많았다. B 아이템은 기획이랄 것도 없이 "A/B 테스트를 해보자", "싸이클을 한 번 경험해보자". 가 첫 그로스팀의 개인적인 전략이기도 했다.
그렇게 3주가 지났다. 결과는 실패한 것과 성공한 것 두가지로 극명하게 나뉘었다. 먼저 성공한 B아이템을 보았다. 가장 이상적인 싸이클을 경험했다.
아이템을 뽑는데 한시간? 한시간도 길다 그냥 그동안 있었던 문제인 공유하기 버튼을 변경하는 것 뿐이었다. 누구나 이 문제를 찾는 건 쉬웠다. 우리는 그걸 시작했다. UI를 변경하는 것도 FE 개발자에겐 아주 쉬웠다.
배포까지 4시간도 안걸렸다. 우리팀은 A/B 테스트를 진행했고 하루정도 지켜봤다. 결과는 아주 훌륭했다.
실험군으로 실행됐던 노란색 수차가 압도적으로 많은 사용자를 이끌어 냈다. 우리는 더 기다릴 것도 없이 실험군을 UI로 적용시키고 실제 전체 유저의 공유하기 지표를 기다렸다. 여기까지 모든 업무속도는 단, 하루였다. 우리팀은 그 동안 이 문제를 알고 있었다. 누구든 "바꾸면 수치가 오를 것이다" 라는 정도는 알고 있었다. 그렇다면 왜 하지 못했을까? 바로 '업무 방식의 문제'였다.
"이건 지금 못해.",
"이거보다 이 기획서가 더 중요하니까, 이걸 먼저해야해",
"대표가 이거하래"
아마도 대부분의 회사가 겪는 방식일 것이다. 어떤 것이 중요하고, 쉽고 빠르고, 성과가 나타나는지 우선순위 잘못 상정한다. 특정기능 C가 기획으로는 훌륭하고 될 것만 같다. 하지만 그건 해보지않는 이상 알 수 없다. 이 이야기는 실패 경험에서 풀어보겠다.
공유하기 버튼의 UI 개선은 위에서 말했듯이, 매우 간단하고 누구나 생각을 했던 것이지만, 아무도 실행하지 못했다. 이유는.. 아니 변명은 많을 것이다. 이해는 한다. 그런 식으로 일하는것이 잘못된 것은 아니다. 하지만 스타트업에겐 시간은 금이고 생명이다.
다시 돌아와서 우리는 공유하기 버튼을 변경하고 며칠 지켜보고있다. 어떤 결과가 있었을까?
엄청난 곡선을 보여준다. 지난 몇개월간 평균 수치의 10배 가까이 상승했다. 당연히 올라간다는건 누구나 알 수 있어도, 이정도 수치가 나올줄은 아무도 몰랐을 것이다.
그렇다 아무리 쉬운것이라도 테스트 해보고 적용한다면 예상했던 수치 이상의 결과를 볼 수 있다. "그거 우리도 하려고했는데", 그 유명한 그로스해킹 방법론인 ICE Score 가 괜히 있겠는가. 이건 변명이다. 해보자.
실패
사실 실패라는 말을 쓰기엔 조심스럽다. 결론부터 말하자면 실패는 실패가 아닌 디딤이다. 실패가 있음으로서 실패를 피해갈 수 있다.
우리는 어떤 기능하나를 추가하려 했다. 하지만 생각보다 기획량이 많았고, 디자인또한 신경썼다. 3~4일 개발을 하면서도 "굳이 이걸 알기위해서 이렇게 어렵게 작업해야하나." 라는 의구심이 들기 시작했다. 그런 느낌이 들었다는 것부터 실패요인중 하나일 것이다.
그렇게 QA 테스팅까지 2주가까이 걸려서 우여곡절 끝에 기능을 배포했다.
하루 몇만명 넘게 사용하는 화면에서 고작 이 기능이 보여준 수치는 위 사진인 10% (노란색) 도 안되는 수치를 받았다. 우리는 여기서 멘붕이 왔다. 고객들은 이 기능을 완전히 배제하고 앱을 스크롤했으며, 오히려 홈 가장 좋은 자리에 위치했지만 바로 다음나오는 기능, 즉 보이지도 않는 기능보다 1/5가량의 낮은 수치를 확인됐다. 충격적이었다. 우리의 결론은 사용자는 이 기능에 대해 매력을 느끼지 못한다라는 것으로 조용히 공감했다.
그 이후 1주일정도 UI, Design 등 변경해보고 광고도 넣어 역전을 노려봤지만 결과는 뻔했다. 광고를 넣으면 올라가는건 맞지만, 이탈률이 높다. 사실 2주간의 개발시간이 너무 아쉬웠다. 그시간동안 다른 기능을 충분히 더 많이 배포할 수 있었을 텐데 말이다. 하지만 이 경험 또한 값지다.
2주라는 큰 시간을 들여 수치가 저조하게 나왔다지만 앞으로 어떤식으로 그로스해킹을 해야할지 느낀점이 많다. 개발자로서 PO가 올바른 결정을 하기위해 데이터를 제공하고 개발을 조절해주는 것을 못한 나에게도 책임이 따른다.
AB 테스트
AB 테스트도 개판이었다. AB 테스트의 가장기본은 통제된 환경이다. 같은 버튼이라도 테스트를 위해서는 width, height, color 등 변경한 부분만 변경하고 다른 건 모두 똑같이 해야 그 실험의 의미가 있었다. 어떤건 목요일에 푸시를 쓰고, 어떤건 수요일에 그냥 하고... 그 사이에 세상에는 어떤일이 일어날 지 모른다. 사람들이 쓰느냐 안쓰느냐는 수치만 알아 보더라도 필요없을 지 몰라도, 기능을 변경하고자 할 땐, 통제를 시키는 것이 가장 의미있는 결과를 이끌어 낼 것이다.
AB 테스트를 하면서, 더 나아가 ABC 등 더 많이 해보며 가장 좋은 기능을 선택하는 것이 가장 빠르게 좋은 성과를 나아갈 수 있는 방법이다. 괜히 방대한 기능을 테스트하려면 오히려 테스트때문에 시간을 낭비하는 일이 생길 것이다.
배운건?
다음 주 부터 엄청나게 많은 실험과 작업을 할 예정이다. 목표치에 달성하기 위해 팀이 같이 고민하고, 빠르게 치고 나갈 것이다.
이 3주가 어떻게보면 아쉽기도 하지만 크게 우리가 하지말고 나아가야하는 방향을 얻을 수 있었다.
- 검증되지 않은 기획은 실험을 하기 전까지 상상일 뿐 옳다고하더라도 실험을 겪어야한다.
- 기획 검증은 가능한 최소한의 기능으로 검증하자
- AB 테스트는 통제할 수 있는 건 모두 통제하자, 날짜와 시간까지도
- 모든건 데이터를 기반으로 결정하자. 상상을 위해선 또다른 테스트를 하는 게 맞다.
우리회사는 이제 그로스 해킹을 시작하는 레벨의 스타트업이다. 투자금은 받았겠다. 완전한 지수곡선을 만들어내야 한다. 지난 3주간의 경험으로 타팀도 많이 느낄 수 있도록 난리를 떨었던 것도 있다. 우리팀은 언제나 결재,기획,개발 까지 한 달을 투자하며 한 기능을 위해 달린다. 망해도 같이 망한거도 시간도 같이 날렸다. 이런 업무 스타일에 대부분 익숙하겠지만 바뀌어야 우리팀이 살아남을 것 같다. (물론 그로스해킹이 모든 팀에 정답이라는 건 아니라는 걸 알려드립니다...)
