#0. 그로스 해킹 : 그로스 해킹이란?

 

그로스 해킹

그로스 해킹은 말 그대로 Growth Hacking.

성장할 수 있는 방법을 "해킹"하는 것

 
많은 시간과 노력을 투자해서 만든 제품이 알고 보니 아무도 원하지 않는 제품이라는 점을 뒤늦게 발견하는 것만큼 나쁜 일은 없다.
 
린 스타트업(Lean Startup)
아이디어를 빠르게 제품으로 만들고 고객이 제품에 대해 어떻게 반응하는지를 측정한 후, 그 결과를 통해 배움을 얻고 지속적으로 제품을 개선해 나가는 "제품 개발 방법론"
시간과 자원이 부족한 스타트업이 성공하려면 실패로 인한 비용을 최소한으로 줄이고, 작은 성공 경험을 꾸준히 쌓아 나가야한다.

제품 개발 - 지표 측정 - 학습 및 개선의 피드백 순환고리를 최대한 빠르게 진행하면서 작은 성공을 쌓아 점진적으로 개선하는 것.

린 스타트업에서는 아무도 원하지 않는 제품을 오랜 기간 열심히 만드는 것은 굉장히 어리석은 일이라는 점을 강조한다.
-> 빠른 출시와 지속적인 개선을 통해 점진적으로 완성도를 높여야 한다.
특히, 요즘은 서비스 출시는 끝이 아닌 시작에 가깝다.
출시 후, 사용자의 평가를 듣고, 사용 패턴을 분석하고, 새로운 기능을 추가함으로써 서비스를 꾸준히 개선할 수 있다면 성공할 확률을 크게 높아진다.
 
크로스펑셔널 팀(Cross-Functional Team)
그로스 해킹을 위해서는 여러 직군 간 협업이 필수적이다. 가령, IT 서비스에서 제대로 된 그로스 해킹을 진행하려면 개발자, 디자이너, 마케터, 데이터 분석가 등 다양한 직군의 멤버들이 팀을 이뤄서 각자의 전문성을 발휘하며 시너지를 내야 한다. 기능 기반 조직의 경직된 협업이 아니라, 목적 기반으로 구성된 조직에서 여러 직군의 구성원들이 치열하게 협업할 때 효율적인 성장 실험이 가능하다.
 
최소 기능 제품(Minimum Viable Product, MVP)
가설을 검증할 수 있는 최소한의 기능이 포함된 제품. 처음부터 완벽한 제품을 위해 달린다면, 내가 만든 제품과 시장이 원했던 제품이 다르다는 점을 뒤늦게 깨닫는 오류를 범할 수 있다. 우선, 아이디어를 검증할 수 있는 최소한의 제품을 만들고 고객의 피드백을 참고해서 조금씩 개선해 나가는 과정이 중요하다.
 
AARRR

• 고객 유치(Acquisition)
• 활성화(Activation)
• 리텐션(Retention)
• 수익화(Revenue)
• 추천(Referral)

위의 다섯 가지 범주에 따라 주요 지표들을 모니터링하고 관리하는 지표 관리 방법론
 
그래서 그로스 해킹이란?

• 크로스펑셔널한 직군의 멤버들이 모여서
• 핵심지표를 중심으로
• 실험을 통해 배움을 얻고, 이를 빠르게 반복하면서
• 제품이나 서비스를 성장시키는 것

 

어떻게 하면 성장하는 서비스를 만들 수 있을까?

 
 
그로스 해킹은 이 질문의 답을 찾는 과정이라고 할 수 있다.
 
그로스 해킹은 각 서비스의 사용 맥락이나 시장 상황을 반영해서 진행할 때만 의미가 있다.
 
극단적으로는, 그로스 해킹 공식을 통해 이러한 서비스들이 성장했다고 보는 것이 아니라 그냥 여러 번에 걸친 시도 중 성공한 시도를 "그로스 해킹"이라는 이름으로 나중에 보기 좋게 포장했다고 볼 수도 있을 것.
 
그로스 해킹을 공부하는 이유 - 데이터에서 찾아낸 인사이트를 바탕으로 제품이나 서비스를 지속적으로 개선해 나가는 방법을 익히기 위해서
 
지속적인 성장을 위한 방법론과 프로세스, 그리고 그 과정에서 데이터를 활용하는 다양한 방법을 살펴볼 것.
 

느낀 점

모든 게 처음부터 완벽할 필요는 없는 것 같다. 나의 경우에는 처음부터 완벽한 설계를 해야한다는 강박이 있는데, 그로스 해킹의 관점에서 보면, 제품 개발부터 피드백 순환고리를 빠르게 하기 위해서는 어느정도 타협이 필요하다고 생각이 되었다. 그리고 나의 이러한 생각이 바로 옆 사람에게도 영향을 미치게 되어 어느새 "완벽을 추구하는 팀"이 되어버려 개발적인 요소뿐만 아니라, 기획적인 요소, 마케팅적 요소 등 비즈니스 전반에 걸쳐서까지 완벽을 추구하게 되지 않을까 싶다.
 
크로스펑셔널팀은 매우 공감이 간다. 여러 직군들이 서로가 서로의 인사이트를 주고 받으면서 내가 생각하지 못한 부분들. 예를들어 나는 개발자의 입장에서 서비스를 생각하고 있지만, 디자이너의 입장에서의 서비스 같은 부분들을 서로 이야기 하다보면 분명 개발자여서 생각 못하는 부분이 있을 수 있고, 디자이너이기에 생각할 수 있는 부분이 분명히 있을 것이다. 이렇게 서로 소통하면서 일을 하다보면 서로가 서로에게 영감을 받으면서 더욱 치열하게(열심히) 일을 하게 되고, 그로 인해 팀-팀 간의 형식적인 소통이 아니라 개인-개인 간의 효율적이고 직설적인 소통을 하면서 제품 개발에 더욱 박차를 가하고 더욱 좋은 제품이 나올 것이라고 생각한다.
단점이 있다면, 개인-개인 간의 소통이기 때문에 잦은 소통으로 인해 리소스가 낭비될 수도 있다는 점과 너무 직설적인 언행은 오해를 불러 일으킬 수 있다는 점이다.
 
최소 기능 제품은 이제 사람마다 생각하는 최소 기능이 다를 것 같다. 회사에서 그 기준을 잘 정하고 빠르게 제품을 개발해나간다면 베스트 아닐까. 물론 기준을 잘 정하는게 쉬운 일은 아니지만, 내 생각은 다음과 같다.
우리가 만드는 것은 그냥 프로토 타입이다. MVP 개발의 목적은 돈을 벌기 위해서가 아니라 시장의 반응을 보기 위해서 라고 생각하기 때문에, 우리 서비스의 핵심 로직만 개발한다. 예를들면, 결제나(이건 추후 필요하긴 하겠지만, 시장 반응을 보기 위해서는 굳이 필요없다) 알람 등 부가적인 요소는 일단 베제한다. 도메인이 커머스라면 상품에 관한 로직만, 도메인이 마케팅이라면 마케팅에 관한 로직만 짜는 거다. 부가적인 뭐.. 쿠폰같은 이벤트 적인 요소는 당장 생각하지 않고 만들어야 한다.
 
 
나는 지금까지 아무 생각 없이 개발을 해왔는데, 이 글을 읽고나서 서비스 개발 프로세스에 대해 눈이 트인 것 같다. 우리 제품이 완벽히 성공할 것 같다는 믿음이 있다면, 공을 들여 개발할 수 있다고 생각하지만(물론 이것도 사람마다 생각이 다를 것이다), 그렇지 않다면 일단 시장 반응을 살피기 위해 빠른 개발과 빠른 출시를 목표로 하여 우리 서비스의 성공/실패에 대한 빠른 판단을 내리게 끔 하는 게 좋을 것 같다는 생각이 들었다.