그로스 해킹(Growth hacking) 세미나를 듣고
12월 동안 들었던 수업 정리 및 팀원을 위한 세미나 자료
작년 12월 DS school에서 데이터 마케팅 수업을 들었다. 단순히 마케팅에 대한 내용만 배운 것은 아니고 그로스 해킹 개념도 함께 들었고, 2019년 개발팀의 PM을 맡았고, 팀 내 업무 프로세스와 사고방식 등의 문화를 만드는데 노력을 했던 것을 정리하는 기회가 되었다.
2020년에는 서비스 자체의 PM을 맡게 되는데, 그전에 새롭게 꾸릴 팀원에게도 개발팀에 공유했던 사고방식을 동기화하고 싶었다. 수업 내용에 내가 공부하고 반영해보면서 느꼈던 애자일, 린 스타트업, OKR을 조합하였다. 그래서 마케팅에 대한 내용은 거의 없다. 내가 받아들인 그로스 해킹의 원론적인 내용으로 채웠다.
시작해보자.
준비했던 slide에 대본 스크립트를 정리하는 식으로 해당 글을 작성하였습니다.
그로스 해킹이란 무엇일까? 구글에 쳐보죠.
위 이미지와 같이 실제 '데이터', '마케터'와 관련된 내용이 많습니다. (제가 들었던 수업도 제목이 데이터 마케팅이었습니다.) 그리고 저도 2015? 16? 년, 처음 이 개념을 배웠을 땐 오른쪽에 나온 '그로스 해킹(Growth hacking)'을 읽으면서 배웠고, 마케팅 방법론이라고 생각을 했습니다.
영어로 검색해서 wiki를 보면 "성장에 초점을 둔 마케팅에 새로운 분야"라고 설명이 되어있는 걸 보면, 그로스 해킹은 -> 마케팅과 관련된 게 아닐까? 생각이 들 수 있습니다. (틀린 말은 아니라고 생각합니다.) 하지만, 제가 들었던 수업의 강사인 Paul은 "마케팅 방법론이라기 보단 생각하는 방식 (사고방식)에 대한 부분이라고 생각한다고 합니다."
출처 : DS school그렇다면 그로스(Growth)? 해킹(Hacking)? 무슨 의미일까요?
출처 : DS schoolGrowth는 '성장', '자란다'의 의미입니다. 해킹이란 흔히 아는 건 비합법적인 혹은 허락되지 않은 방법으로 개인의 데이터를 빼내거나 하는 행위로 알고 있을 텐데, 요새 IT field에서는 복잡한 문제를 우아하거나 효과적으로 해결하는 의미로 사용된다고 합니다.(urban dictionary 참고)
실제로 위 이미지를 보면 집게와 테니스공을 이용해서 현실에서의 문제를 주어진 상황에서 '똑똑하게' 해결하고 있지 않은가요? 이런 건 꼭 누구여 서라기 보단 이런 (문제를 해결하고자 하는) 사고를 하기 때문이라고 생각합니다. 새로운 무언가를 만드는 게 아니라, 지금 상황에서 가장 현명한 방법으로 문제를 해결하는 것입니다.
출처 : Growth Tribe그리고 이런 그로스 해킹은 마케터나 그로스 해커만 하는 게 (혹은 할 수 있는 게) 아니라 그 누구도 할 수 있다. 회사를 경영하는 CEO도, 인사/회계담당자도.. 서비스를 만드는 사람이 아니라도 본인의 업무에서 발생하는 문제를 인지하고 개선하려는 자세를 가지면 된다고 생각합니다. 그냥 마인드셋 = 사고방식.
그리고 이 그로스 해킹은 혼자 하는 게 아닙니다. 함께 업무를 하는 팀원 모두가 함께 해야 합니다. 지금 우리가 바꾸려는 팀 구조(업무 단위의 팀 -> 프로젝트 단위의 팀)에서는 더욱더 그렇습니다. 특정 방법이나 툴이 아니라, (다시 한번) 사고방식. 업무를 어떻게 할까? 에 대한 사고방식을 함께 맞춰야 합니다.
세미나 전에 몇 분께 슬랙을 드렸죠? 그리고 짧은 설문조사를 부탁드렸습니다.
여쭤봤던 이유는(앱 개선에 대한 의견이 정말 궁금한 것도 있지만) 세미나를 진행하는데 보여드리고 싶었던 게 있어서 그랬습니다. 한 10명 정도가 답변을 주셨는데, 개선안에 대한 내용과 이유가 서로 다양합니다.
주신 다양한 의견은 모자이크 처리하였습니다.다양한 기능을 성격에 따라 3가지로 분류하였습니다. 저 3가지 분류는 업무의 방향성이라고 생각합니다. 그리고 그 방향성은 틀렸다, 잘못되었다 라고 생각하지 않습니다. 서로가 생각하는 우선순위, 업무에 대한 생각이 다를 뿐입니다.
(세미나가 끝난 후 다시 생각을 해보았는데, 위 예시는 사고방식이라기 보단 그냥 어떤 문제를 어떻게 해결할 것인가? 에 대한 다양한 아이디어라고도 생각할 수 있을 것 같습니다. 다만, 그 아이디어 자체가 어떤 이유에서 나온 건가? 에 대해선 생각해볼 수 있을 것 같습니다. )
UX나 최근 스타트업 관련 아티클 등에서 흔히 볼 수 있는 Cliche지만.. 우리의 상황에 딱 맞는 예시라고 생각합니다. 우리가 '그네'를 만들어야 한다고 했을 때 팀원 모두가 서로 다른 생각을 하고 있습니다. 물론, 그네를 만들어가는 과정에서 이런 다름은 대화를 하면서 맞춰가겠지만 애초에 서로 다른 방향성을 가지고 생각을 한다면 '의사소통' 과정에서 많은 에너지를 소모해야 할 것입니다. 그래서 생각을 통일해야 할 필요가 있습니다.
대단한 걸 얘기하는 건 아닙니다. 업무를 어떻게 바라볼 것 인가? 그리고 그 업무를 해결할 때의 방향성, 우선순위 등을 약속한 방식으로 align을 맞추자는 것입니다. 왼쪽 / 중앙 / 오른쪽 그냥 약속한 방식대로 생각의 줄을 맞추는 거죠.
서로 같은 곳을 바라보면서 그네를 만들어야 합니다. 통일된 생각을 가지고 '그네'를 생각해도 그 안에는 고민해야 할 부분이 수두룩 합니다. (그 수두룩한 것들에 대해선 앞으로 계속 얘기를 해나갑시다.)
정답은 없겠죠.. 다만 우리는 clever 한 답을 계속 찾는 것이고, 그 답은 고객에게 전달되고 판단됩니다. 항상 '고객'을 생각하면서 업무를 한다는 게 제가 생각하는 align의 시작인 것 같습니다. 고객이라는 base에서 어떤 방향성(예를 들어, 제가 위에서 얘기했던 주제)으로 목표를 잡고 업무를 할 지도 얘기를 해봐야죠.
"사고방식을 정렬하자." 그리고 "고객을 생각하자" 이 외에 우린 어떤 생각을 가져야 할까요?
이 부분은 좀 더 구체적인 가이드?라고 생각합니다.
1. 무조건 새로운 것을 하지 말고, 지금의 것을 개선한다. 그 개선을 반복한다.
2. 업무를 작은 규모로 생각하고, 그 생각을 실험하고 검증을 한다.
예를 들어, "온라인 매출을 높이자"라고 목표를 잡는다면 대개 쇼핑몰 페이지를 새로 만드려고 합니다. (실제로 저희도 그랬죠?) 새로 만드는 게 나쁘다 라기 보단 그 과정을 바꿔보면 좋을 것 같습니다. 기존에 사용했던 쇼핑몰에서 계속 사용할 부분과 개선해야 할 부분을 나눠봅시다. 그리고 그 개선할 부분만 나눠서 어떤 식으로 개선해야 할지 개선안을 가볍게 만들어서 테스트를 해보는 거죠. 그 테스트 결과를 새 쇼핑몰에 반영하고, 실제 오픈된 쇼핑몰도 결과도 보고 개선이 필요하면 싶으면 다시 개선안을 생각해보고, 실험하고 개선 작업을 반복하자는 겁니다. (물론, 언제까지 이것만 하고 있을 순 없겠죠.)
출처 : Growth TribeGrowth hacking process라고 구글에 검색하면 위 이미지와 같은 이미지를 여럿 확인할 수 있습니다. 좀 더 심플한 버전도 있습니다. 지금 제가 속한 프로젝트는 Pirate metric, OMTM을 잡아가는 단계에 있습니다. 쉽게 얘기드리면 목표를 세워가는 단계입니다.
위 과정을 간략하게 얘기해보면 다음과 같습니다.
1. 목표를 세운다.
2. 목표를 달성하기 위한 아디이어를 생각하고
3. 그 아이디어들의 우선순위를 매기고
4. 선정된 안을 디자인한다. (여기서 디자인은 최소 단위로 제품을 만든다?로 생각해주시면 좋을 것 같습니다.)
5. 실험한다.
6. 분석한다.
그리고 이 과정을 반복합니다. 제 경험을 가지고 설명을 해볼게요.
출처 : Growth Tribe이번에 들었던 수업 사례입니다. 왼쪽은 랜딩페이지인데, 유입된 사람들이 저 파란색 CTA 버튼을 누르는 횟수를(전환율) 높이자는 게 목표였습니다. 총 3번 (3주) 개선을 반복하는 작업을 진행하였습니다. 단순합니다. "빠르게 시작하기"라는 "나의 레벨 확인하기"로 바꾸고(타 팀의 좋은 사례 활용) 하단 텍스트들의 가독성을 높이기 위한 볼드 처리하는 정도로 진행하였습니다. 그 결과는 지난주 대비 전환율이 56% 증가하였습니다.
아까도 얘기했지만, 새로운 걸 만드려고 하는 그 생각을 한 수 접고 지금 가지고 있는 소스를 활용하자는 겁니다. 마케팅을 위한 새로운 콘텐츠, 랜딩 페이지 제작. 앱 개선을 위한 리디자인이 아니라 먼저 기존 안을 활용하여 개선하자는 겁니다.
이건 전 회사에서 진행했던 사례입니다. '타이머'라는 기능을 더 많이 사용하게 하는 게 목표였습니다. (스위처라고, 스마트폰을 이용해서 전등불을 켜고 끄는 제품입니다. 타이머는 정해진 시간에 자동으로 불을 켜고 끄는 기능입니다.)
목표를 달성을 위해 아이디어를 나누고, 디자인/개발하고, 결과를 분석하였습니다. 단순히 수치만 보진 않고 실제 사용자와 인터뷰를 하면서 개선안에 대한 인사이트를 받았습니다.
그리고 한 번 더 개선을 진행했습니다. 아예 새로운 디자인? 기능?처럼 보이지만 실제 공수가 크게 들진 않았습니다. 오히려 어떤 상황에서? 왜 사용하는가? 는 사용자 목소리를 반영하여 큐레이션 형태로 바꿔 마무리하여서 릴리즈 하였습니다.
그렇게 2번의 개선을 진행하였고, 처음 47%였던 타이머 미사용 비율을 22%까지 낮췄습니다.
그렇게 해당 프로젝트는 종료하였고, 새로운 프로젝트(개선해야 할 부분)를 진행하였습니다. 이 기능을 사용하기 위해서 기능 추가(혹은 리디자인) 했으니까 끝! 이 아니라 목표한 수치를 달성하는 순간까지 몇 번의 과정을 반복하는 것입니다. (혹은 안 되겠다 싶으면 포기할 수도 있습니다.)
단순히 마케팅, 개발 쪽에만 이런 반복을 하는 게 아니라고 생각합니다. 전반적인 업무 전체에도 마찬가지로 적용될 수 있다고 생각합니다.
개발팀에서 사용하는 트렐로 보드를 캡처한 겁니다. 제가 와이어프레임을 만들어서 공유한다고 하면 전 서너 번 정도 짧게 미팅을 가질 거라고 미리 얘기를 합니다. 애초에 최종본을 가지고 미팅해서 한 큐에 끝낼 거라고 생각하지 않습니다. 개발자와 서로 생각하는 부분을 맞추기 위해서 눈에 보이는 결과물을 가지고 계속 얘기하고 수정하는 과정을 반복합니다.
QA도 마찬가지예요. 작은 규모에선 전문 QA도 없으니 우리가 직접 해야 합니다. 개발자 입장에선 모든 기능이 다 구현되면 한 번에 QA를 하는 게 편하겠죠. (기능이 크게 따라 다르긴 하지만) 그래도 최대한 쪼개서 QA를 하려고 합니다. 디자이너/기획자의 의도에 따라 기능이 개발된 건지, 개발자 입장에서의 어려움을 UX적으로 풀 순 없는지 최대한 많이 얘기를 하면서 진행을 하려고 합니다. 그리고 한 번에 끝내려고 하면 버그도 더 많이 나와서 오히려 QA시간 및 기간이 더 길어집니다. (이 부분은 사실 개발팀의 상황에 따라서 많이 달라지는 것 같습니다.)
제가 생각하는 그로스 해킹을 위한 생각 정렬은 위와 같은 내용들입니다. 그리고 이런 그로스 해킹을 위해선 다음과 같은 환경이 준비되어야 한다고 얘기합니다.
출처 : DS school1. 우리의 상황을 파악하고, 거기에 맞는 목표를 설정해야 한다.
- funnel은 마케팅이나 앱 분석에 많이 사용되는 개념입니다. 어디서 사용자가 이탈하는지 확인하고 개선할 부분을 찾는 거죠. 개선 전(목표를) 잡기 전 우리 상황을 먼저 파악합니다.
- 그리고 개선의 목표를 세웁니다. 목표가 명확해야 팀원들의 생각을 한 곳으로 집중시킬 수 있습니다. (사람은 누구나 발산하는 사고를 하는데, 이때 그런 생각을 쉽게 잡아줄 수 있는 게 바로 이 목표라고 생각합니다.)
출처 : Google2. 데이터를 볼 수 있는 환경(Sandbox)을 구축한다.
- 개선은 하였는데 전/후 결과를 볼 수 없다면? 의미가 없겠죠. (뭐가 더 좋은 건지 모르니까) 이를 확인하기 위한 실험 환경이 구축되어야 합니다. 이를 위한, GA나 mixpanel 등과 같은 다양한 툴이 존재합니다. 우리 상황에 맞는 가장 좋은 툴을 선택하여 사용해야겠죠. 사실 이런 툴을 꼭 사용하지 않고 그냥 google sheet에 기록만 잘해서 봐도 된다고 생각합니다. (세팅을 위한 공수가 너무 크다면) 목적만 제대로 이룰 수 있다면 뭔들..
출처 : roadmunk3. 우선순위를 정합니다.
- 스타트업은 한정된 자원으로 최대의 결과를 내야 합니다. 그러기 위해선 우선순위를 잘 세워야 합니다. 우선순위를 정하는데 많은 framework이 있습니다. 수업 때는 ICE라는 게 있었는데, 구글링을 해보니까 RICE라는 게 나오네요. 뭐든 그냥 우리 상황에 잘 맞는 방법론을 이용하여 우선순위를 잘 세우면 됩니다.
출처 : Facebook4. 항상 테스트하기.
- 실험을 하지 않겠다는 말은.. 직관으로 일 하겠단 말이죠. 그럴 거면 결과를 볼 필요도 없겠죠? 그냥 직관대로 하면 되니까.. 항상 테스트하고 결과를 봐야 합니다.
여기까지가 제가 들었던 세미나에서 공유하고자 하는 부분입니다. 마케팅에 대한 부분이나 더 디테일한 부분은 다음 세미나 혹은 다른 자리에서 더 얘기를 할 예정입니다. 처음인 만큼 기본적인 부분에 대해서만 얘기하려고 했습니다.
그리고 내용을 다시 요약해보면, "업무에 대한 사고방식을 맞추자."
- 완벽한 답을 찾는 게 아니라 지금 상황에서 좀 더 현명한 (개선된) 답을 찾는다.
- 새로운 걸 계속 만드려고 하지 말고 기존의 것을 먼저 개선하자.
- 그 개선은 실험을 통해 진행되고, 한 번에 끝나는 게 아니라 작게 반복해야 한다.
이 자료를 준비하면서 이런 트윗 글을 공유받았습니다.
Spotify 출신의 디자이너 겸 CEO인데요. 그로스 해커는 어디 갔는가?라고 하자 그 아래 "아직도 그로잉(성장하고) 있다고" 비꼬는 답변이 달리네요.
사실 그로스 해킹은 폴 그레이엄도 이미 부정적으로 얘기한 바 있습니다. "누군가 그로스 해킹에 대해 얘기하면, 그냥 마음속으로 개소리라고 생각하면 된다."
그로스 해킹에 대한 부정적인 의견은 있을 수 있다고 생각합니다. 뭐든 지 이면?이랄까 장점이 있으면 단점이 있는 거니까요. 이런 단점을 보완하기 위해선 다음과 같은 자세를 잃지 않아야 합니다.
먼저, 프로젝트를 바라볼 때 Top-down(거시)과 Bottom-up(미시)를 번갈아 볼 수 있어야 합니다. 그리고 하고 있는 일을 관성적으로 하면 안 됩니다. 개인적으로 그 말을 좋아합니다. "그때는 맞고, 지금은 틀리다." 영원한 거 없죠. 페이스북 마케팅 효과 예전만큼 안 나오잖아요. 우리 인스타에 사진 올리지 페북에 안 올리잖아요. 관성에 젖어서 Facebook에 광고 돌려야 한다고 아무 이유 없이 얘기하는 사람이 제일 싫어요. 우린 계속 상황을 바라보면서, 이게 맞나? 고민해야 합니다.
그로스 해킹을 하다 보면 굉장히 작은 부분의 업무를 하게 될 때가 많습니다. 가령, 버튼의 모양이나 컬러를 바꾼다던지. 아까 보여줬던 CTA 버튼의 텍스트를 바꾸는 정도죠. 이런 일을 하다 보면 굳이 하지 않아도 될 일을 할 때가 발생합니다. (규모에 따라 다르지만) 1~2%의 전환율을 높이기 위해 버튼 텍스트를 고민하고 데이터를 쳐다보고 있는 거죠. 늘 하던 식으로.. 이때 자신의 프로젝트를 한 걸음 뒤에서 바라보거나, 최종 목표와 이를 위해 해야 할 업무를 생각해보면서 우선순위를 업데이트하면 위 트윗에서 얘기하는 "still growing"을 벗어날 수 있습니다.
두 번째로, 그로스 해킹 (특히 마케팅) 자체는 서비스 개선이 아닐 수가 있습니다.
진짜 해야 할 일은 유저가 우리 제품(서비스)을 사랑할 수 있게 그 자체를 개선해야 하는 겁니다. (버튼 크기 바꾸는 게 아니라.. 위에서 얘기한 마이너 한 부분에만 집중하는 것을 견제(?) 해야 한다고 폴 그레이엄은 얘기한 게 아닐까 싶습니다.) 저도 지난 5년간 업무를 하면서 실제로 느꼈던 부분입니다.
그리고 이런 스타트업 공부(?)나 업무 방법론 등에 대해 관심이 있으신 분들은 제가 지금까지 말했던 것들이 익숙하실 거예요. 제 생각에는 요즘 많이 회자되는 Agile, Lean startup, OKR 등등 대부분 다 비슷한 것 같습니다. '작은 실험을 반복하여 나간다.', '직관이 아닌 데이터 근거한 의사 결정한다.' 겉모습만 다르지 목표와 그 방식으 비슷합니다. 우린 더 효율적으로, 더 잘 일을 해야 합니다.
세미나는 이상입니다. 감사합니다.
자료 출처 & 읽어보면 좋은 글
- 7 product prioritization frameworks for product managers
- Lecture 3 - Before the Startup (Paul Graham)
- AARRR Framework- Metrics That Let Your StartUp Sound Like A Pirate Ship
- 실리콘밸리 하버드 만든 스타트업의 신, 폴 그레이엄
- 의도적 수련하기
