그로스 해킹 너무 헷갈려 - 1

스타트업에 재직하는 개발자라면 X 상황에서도 호출로 전환되는 유저의 경우 높은 리텐션율을 보여주는 것 같아요, 이 부분이 서비스에 유저가 락인되는 아하 모먼트가 아닐까요? 와 같은 대화들을 자주 듣게 된다.

이런 단어들의 핵심을 관통하는 키워드는 그로스 해킹 이다. 내가 만드는 프로덕트의 방향성에 관한 대화를 따라가고 싶은 마음에, 그로스 해킹의 바이블이라고 불리는 진화된 마케팅 그로스 해킹 을 (프로덕트 개발자의 관점에서) 읽고 정리한 내용을 공유해보려고 한다.

글에 앞서

매번 새로운 개발 패러다임, 조직 방법론에 대해서 다룰 때 마다 되새기는 생각인데, 새로운 방법론을 무의식적으로 따라하는 것 보다 방법론이 추구하는 방향이 무엇인지, 그리고 그 방향이 현재 우리의 상황에 도움이 되는지 해가 되는지를 잘 판단하고 도입할 필요가 있다.

그로스 해킹을 공부하면서 실제로 지금 내가 속한 조직에 도입되면 어떤 영향이 있을지 떠올리며 글을 읽으면 더욱 많은 도움이 될 수 있을 것이라고 생각한다.

그로스 해킹의 정의

그로스 해킹이라는 단어가 아니라도, 린 스타트업 / 애자일 조직 문화 등의 키워들은 스타트업 개발자라면 굉장히 자주 들어보았을 것이다. 이런 방법론 들의 공통적인 특징은 빠른 반복 실행과, 실행 마다 얻는 피드백을 바탕으로 목적을 위한 개선이 발생한다는 점이라고 볼 수 있다.

그로스 해킹 또한 중심점은 위 방법론들과 비슷하다. 제품의 성장 이라는 목표를 위해 고객 중심의 지표를 선정하는 과정, 지표 개선을 위해 실험과 적응을 반복하는 과정을 그로스 해킹이라고 볼 수 있다.

그로스 해킹의 그로스 는 말 그대로의 성장을 의미하며, 해킹 의 경우에는 골치 아픈 문제들에 대한 창의적이고 협력적인 아이디어 창출과 문제 해결을 의미한다고 책은 설명하고 있다. 간단히 합쳐보자면 성장을 이루기 위해서 창의적이고 협력적인 아이디어를 고민하고 적용하는 행동이라고 볼 수 있겠다.

앞으로의 책 내용은 그로스 해킹을 실행하기 위한 팀과 프로세스, 왜 하필 지금 그로스 해킹이라는 방법론이 유의미한가, 실제 그로스 해킹을 적용하기 위해서 도움을 얻을 수 있는 프레임 워크(AARRR)에 대한 이야기를 해 보려고 한다.

그로스 해킹 팀

그로스 해킹을 실천에 옮기기 위해서는 적합한 팀이 필요하다. 전형적인 기능 조직 팀 구조에서는 지표 선정 ~ 제품 개발 까지 오롯히 사이클을 돌기 위해서는 수많은 조직의 우선순위와 이해관계가 얽혀있다. 또한 각 부서의 담당영역(e.g. 마케팅팀 -> 고객 유치, 제품팀 -> 고객 리텐션) 이 다른 만큼, 지엽적인 그로스 최적화를 만들 수 있지만 제품 전영역을 아우르는 거시적인 맥락의 그로스를 만들기에 쉽지 않다.

책은 이를 해결 하기 위해서는 여러 전문 분야와 부서의 구성원들이 포함되어 부서를 넘나드는 협력이 온전히 가능한 팀을 구성해야 한다고 이야기 한다. 팀의 구성은 정형화된 형태는 아니지만 PO, PM, 개발자, 디자이너, 데이터 분석가, 마케팅 전문가의 구성이 필요하다.

• PO(Product Owner) 는 팀 전체의 지표와 로드맵을 관리하고, 그로스 실험을 설계하는 작업을 한다. 그에 따른 실험의 우선 순위 선정 및 외부/상위 조직으로 부터 자율적인 권한을 인정받는 편이다.
• PM (Project Manager) 은 기능 개발의 DRI를 가지고 기획 ~ 배포 까지의 과정을 관리하고, 제품의 사용자들의 피드백을 수합하는 환경을 설계한다.
• 데이터 분석가의 경우 PO 와의 협업을 통해 지표를 설정하거나 실험을 설계하는 역할을 담당한다. 실험의 결과로 부터 다음 스텝을 위한 유의미한 인사이트를 뽑아내는 역할을 한다고도 볼 수 있다.
• 개발자 / 디자이너 / 마케터 의 경우 자신의 전문성을 잘 살려 개발, 디자인, 마케팅의 DRI 를 가지며 각자의 전문성을 활용해 다양한 아이디어를 역으로 제공하는 역할을 수행해야 한다.

꼭 그로스 해킹 팀이라고 이름을 붙이는 곳이 아니더라도 많이 본 구조일 것이다. 앞선 직군이 꼭 존재하고 주어진 역할을 지켜야 그로스 해킹을 할 수 있다는 것은 당연히 아니다. 각 조직에 맞춰 적합한 팀의 형태를 이룰 수도 있다.

하지만 집중해야 하는 부분은 필요로 하는 실험의 독립적인 실행을 위해 필요한 구성원들이 최대한 포함되어 있어야 한다는 점이다.

개인적으로는 PO 는 실험 우선순위 설정에 대한 최종 DRI 를 가진 만큼 지표 설정과 관리에 더욱 힘을 써야 한다는 점과 개발자의 경우 스스로에게 주어진 일을 잘 하는 것 뿐 아닌, 공학적인 접근을 통해 보다 높은 효율의 솔루션 / 아이디어를 역 제시할 필요가 있다는 점이 그로스 해킹 조직에서 나타나는 중요한 특성이라고 생각한다.

그로스 해킹의 추진

이제 그로스 해킹팀이 갖춰졌으니, 실제 그로스 해킹을 어떻게 추진해야 하는지 살펴보자. 그로스 해킹은

• 데이터 분석 / 인사이트 정리
• 아이디어 도출
• 실험의 우선순위 결정
• 실험의 진행

의 사이클을 반복적으로 실행하며 제품에 대한 개선을 만들어 내는 과정이다.

각 구성원은 앞서 언급된 개별 업무를 진행하면서, 실험 설계 / 지표 선정 등의 중심적인 과정을 함께 논의하며 서로의 합의를 맞추고 새로운 아이디어를 발굴해 내는 역할을 맡게된다.

특히 이런 과정을 위해서는 주간 회의 등 정기적인 회의가 도움이 될 수 있다. 회의를 통한 정기적이고 잦은 공유를 통한 업무 투명화와 진행 현황의 변화를 민첩하게 확인하고 계획의 수정을 만들 수 있고, 공유를 통해 다양한 관점의 (개발, UX, 마케팅) 인사이트를 발굴해 낼 수 있다. (이런 잦은 공유 / 사이클의 형태는 애자일 조직 구조 와 일맥상통하는 부분이 많은 것 같다)

물론 과도한 회의는 내부 비효율화로 이루어질 수 있으므로 좀 더 알맹이 있는 회의만을 남길 수 있도록 트레이드 오프를 적당히 조절해야 한다.

또한 실험의 설계 등 그로스 해킹 실행에 있어서는 단순한 가정이나 추측이 아닌 명확한 데이터를 기반으로 삼는 것이 중요하다. 고객이 원하는 것이 무엇인지에 대해 충분한 근거를 가지고 우선순위가 선정되어야 하며, 이런 방식으로 잘 설계된 실험에서 나온 결과를 기반으로 작더라도 많은 성공을 만들어 조직 내에서 그로스 해킹 팀에 대한 신뢰를 쌓는 과정 또한 중요하다.

마무리, 다음 글

앞서 알아본 그로스 해킹의 실행은 항상 좋은 방향이라고 볼 수 있을까? 그렇지 않을 수 있다. 실제 시장에서 필요로 하지 않는 제품에 대해서 그로스의 최적화를 진행하려고 하는 것은 매우 안타까운 결정이 될 것이다. 그로스 해킹의 실행은 고객에 대한 충분한 분석으로 실제 시장에 내 제품이 적합한 제품이 될 수 있을 지 확인한 후 진행되어야 한다.

다음 글에서는 그로스 해킹을 진행하기 전 이 제품이 실제로 고객이 필요로 하는 가치인가? 를 확인하는 방법에 대해서 다루어 보려고 한다.