그로스(Growth)란? / 그로스 팀의 역할 / 그로스 PM의 역할
43 min read

그로스(Growth)란? / 그로스 팀의 역할 / 그로스 PM의 역할

그로스란? / 그로스에 대한 오해는? / 그로스 팀과 그로스 PM의 역할은?
그로스(Growth)란? / 그로스 팀의 역할 / 그로스 PM의 역할
Photo by Luke Chesser / Unsplash

글의 목적

이 글은 독자들이 그로스(growth)가 무엇인지 이해하는 것을 돕기 위한 글입니다.

  • '그로스, 그로스, 많이들 얘기하는데 그게 뭔지는 잘 모르겠어요' 하는 막연함이 있다면 해소해 드리고
  • 그로스에 대해 흔히 가지고 있는 오해를 불식시키고
  • 그로스 프로덕트 매니저의 역할을 이해하도록 돕는 것이 이 글의 목적입니다.

좀 더 개인적인 이유로는, 제가 어떤 일을 하는 사람인지 설명하기 위해서 글을 쓰고 있기도 합니다. 최근 1년 사이에 저는 두 차례 이직을 했는데, 새로운 회사에서 팀 멤버들과 티타임을 할 때면 매번 그로스란 무엇인지, 제가 어떤 역할을 하는 사람인지 똑같은 설명을 반복하곤 했습니다. 제가 좋아하는 말 중 "When you say it twice, write it down"이라는 말이 있는데요, 열 번도 넘게 같은 말을 했으니 이제는 write it down할 시간이라고 생각해서 마치 자기소개서를 쓰는 기분으로 이 글을 작성합니다.

정의: 그로스(Growth)란 무엇인가?

퍼블리에 발행한 <그로스 해킹, 마케팅과 어떻게 다른가요?>에서도 그로스를 나름대로 정의해 보았는데, 이 글에서는 또 다른 각도에서 그로스를 설명해 보려고 합니다.

그로스, 말 그대로 성장이라는 뜻입니다. 굉장히 커다랗고 모든 것을 포괄하는 단어죠. 이걸 조금씩 더 구체화 해보겠습니다.

양승화 님이 쓴 <그로스 해킹 - 데이터와 실험을 통해 성장하는 서비스를 만드는 방법>에 의하면, 그로스 해킹(줄여서 그냥 '그로스')은

  1. 크로스펑셔널한 직군(엔지니어, 디자이너, 데이터, 프로덕트, 의 멤버들이 모여서
  2. 핵심 지표를 중심으로
  3. 실험을 통해 배움을 얻고, 이를 빠르게 반복하면서
  4. 제품이나 서비스를 성장시키는 것입니다.

아직은 ‘그래서 그게 뭔데요?’ 하는 생각이 드실 텐데, 하나씩 씹고 뜯고 맛보고 즐길 수 있도록 풀어 보겠습니다.

1. 제품이나 서비스를 성장시키기

그로스에서 목표로 하는 바는 제품이나 서비스를 성장시키는 것입니다. 그런데 성장이란 게 뭔지, 아직 잘 와닿지 않으시죠? 이쯤이면 다음과 같은 질문이 머릿속에 떠오르실 겁니다.

그래서 그로스에서 말하는 ‘성장’은…
- 매출이 늘어나는 건가요?
- 사용자 수가 늘어나는 건가요?
- 사용자들의 체류시간이 늘어나는 건가요?

여기에 대한 답은... 선문답같은 얘기로 들리겠지만, 그로스에서 다루는 성장은 이 모든 것(매출, 사용자 수, 체류시간)일 수도 있고, 이것들 중 아무 것도 아닐 수도 있습니다. 아직은 “It depends”라고 말할 수밖에 없습니다. 왜냐면 회사의 단계와 상황에 따라서, 회사가 목표로 하는 성장의 종류도 달라지기 때문입니다. 그래서 이어서 설명할 ‘핵심 지표를 중심으로’라는 포인트를 이해할 필요가 있습니다.

2. 핵심 지표를 중심으로

앞에서 말씀드렸듯, 회사(혹은 제품, 서비스)의 단계와 상황에 따라 목표로 하는 성장의 종류는 달라집니다. 어떤 회사는 매출을 증가시키는 것이, 어떤 회사는 많은 사용자를 확보하는 것이, 혹은 어떤 회사는 체류시간을 늘리는 것이 지상 목표일 수 있습니다.

어떤 경우에 매출 증가가 목표가 될까요? 돈을 버는 것은 (너무나 당연히) 어느 회사에나 중요하니까, 많은 경우 매출 성장이 지상목표가 되곤 합니다. 스타트업의 경우에는 투자자들에게 사업성을 증명해야 할 때 매출이 강력한 설득 포인트가 됩니다. 시리즈 A 이후에는 '실제로 돈을 벌 수 있는 팀'이라는 것을 시장에 증명해야 하니까요.

‘매출 성장’이 그로스의 지상목표가 되는 경우는 이해하기 어렵지 않으실 겁니다. 그런데, 어떤 경우에는 다른 것이 주된 목표가 될 수 있습니다.

예를 들어, 승자독식 구조의 시장에서는 매출이 아닌 사용자 수를 가장 중요한 핵심 지표로 설정할 수 있습니다. 일단 사용자를 많이 늘리고 락인시켜서 경쟁 업체들을 따돌릴 수 있다면 수익은 나중에 얼마든지 마련할 수 있다는 가정 하에 말이죠. 모빌리티, 배달 등 마켓플레이스에서 이런 방향성을 택하곤 합니다. 꼭 플랫폼이 아니더라도 초반에는 매출보다는 사용자 수를 늘려서 제품을 활성화시키는 방향성을 택하는 회사들이 많기도 하구요.

또 다른 예로, 광고로 돈을 버는 업체는 사용자들의 인게이지먼트(engagement)를 가장 중요한 핵심 지표로 설정할 수 있습니다. 사용자들이 더 많은 시간을 체류하거나, 더 많은 글을 읽거나, 제품에서 더 많은 액션을 할수록 더 많은 광고를 보게 되니까요. (이런 경우 '인게이지먼트가 곧 매출로 이어지는 거니까, 결국 매출이 핵심 지표 아니냐' 하고 생각하실 수도 있습니다. 하지만 그로스에서는 매출과 같은 후행지표(lagging indicator)보다는 인게이지먼트와 같은 선행지표(leading indicator)를 핵심 지표로 설정할 때가 많습니다.)

결론적으로, 그로스에서 목표로 하는 핵심지표는 그때그때마다 다릅니다. 회사와 제품이 어느 단계에 있고, 어떤 목표를 추구하는지에 따라서 핵심지표 역시 달라지는 것입니다.

3. 실험을 통해 배움을 얻고, 이를 빠르게 반복하기

그러면 핵심지표를 개선하기 위해, 그로스 팀은 무엇을 할까요? 바로 실험(test 혹은 experiment)입니다.

실험이라니… 과학실에서 실험 가운을 입고 화학물질이라도 만져야 할 것만 같은 기분이 듭니다. 다행히도 스타트업이 수행하는 그로스 실험은 과학자의 실험만큼 거창하지는 않습니다. 예를 들면, 그로스에서 하는 실험은 이런 것들입니다.

이미지 출처: 김민우, <제품 진단 - '프로덕트 마켓 핏'을 달성하지 않고는 99% 실패함>

(1) 핵심 지표 설정

  • 우리 제품의 핵심 지표는 앱의 주간 활성 사용자(weekly active user, WAU)다.

(2) 문제/기회 발견

  • (문제) 데이터를 분석해 보니 앱을 신규 다운로드해서 실행한 사람들 중 단 30%만이 다음 주에 또 앱을 실행한다. 다시 말해, 신규 유저의 2주차 잔존율은 30%(이탈률은 70%)이다.
  • (기회) 하지만 데이터를 더 분석해 보니, 신규 유저 중 첫 3일 내에 A 기능을 이용한 이들은 70%가 2주차에도 앱을 실행했다. 어쩌면 더 많은 사람이 A 기능을 쓰게 되면 리텐션 지표가 개션될 수도 있겠다.  
  • 데이터를 더 보니, A 기능을 이용하는 사용자는 전체의 20% 뿐이다. 어쩌면 사람들이 이 기능을 잘 모르기 때문에 안 쓰는 것일 수도 있겠다. 이 기능은 홈 화면에 드러나지 않고, 좀 더 안쪽으로 들어와야 보이니까.
  • 더 많은 신규 사용자에게 이 기능이 있다는 것을 알리면 리텐션을 개선해서 활성 사용자를 늘리는 데 도움이 될 수도 있겠다.

(3) 가설 수립

  • 가설은 ‘우리가 OOO를 하면, 고객들은 OOO하게 반응할 것이고, 그러면 OOO라는 결과를 얻을 것이다’ 같은 식으로 세웁니다.
  • A 기능을 앱 홈화면 최상단에 노출한다면, 앱 신규 유저들이 그 기능의 존재를 알게 될 것이다.
  • 매주 앱 신규 유저가 평균 1만 명이고, 그중 80%인 8천 명은 3일 내에 A 기능을 사용할 것이다.
  • 기존에는 신규 유저 중 20%가 A 기능을 이용하고 있었다. 신규 유저들이 A 기능을 경험하는 비율이 4배 높아질 것이다.
  • A 기능을 이용한 유저들 중 상당수는 앱이 제공하는 가치에 락인(locked-in)될 것이다. 그러면 신규 유저의 2주차 사용률도 높아질 것이다.

(4) 실험 설계

  • 이제 앞에서 수립한 가설이 맞는지 틀렸는지 확인해 볼 차례입니다.
  • 아직 이 가설을 믿고 제품을 전면적으로 변경하기엔 위험이 있습니다. 혹시라도 제품에 악영향을 끼칠 수 있고요. 이런 위험을 관리하기 위해 일부 사용자들만 대상으로 제품을 변경합니다.
  • 실험은 이런 식으로 설계합니다. (단순화해서 설명하겠습니다.)

    1) 실험군과 대조군 설정: 앱 신규 사용자 중 30%(실험군)에게는 홈 화면에 A 기능을 보여주고, 나머지 70%(대조군)에게는 기존처럼 홈 화면에 A기능을 보여주지 않는다.

    2) 실험 기간 설정: 2주 동안 이렇게 실험을 진행한다

    3) 목표 지표 설정: 실험군과 대조군 사이의 2주차 잔존율에 얼마나 차이가 있는지 데이터를 확인한다.

    4) 실험 성공 기준 설정: 실험군의 2주차 잔존율이 대조군에 비해 30% 이상 높으면 실험을 성공한 것으로 판단한다. 여기에 미치지 못하면 실험은 실패한 것으로 판단한다.

    5) 후속 조치 계획: 실험에 성공하면 모든 신규 유저들에게 A 기능을 홈 화면에서 보여준다. 실험에 실패하면 기존안으로 복귀한다.

(5) 실험 진행

  • 앞에서 설계한 대로, 실험을 구현해서 미리 정한 기간만큼 진행합니다. 실험을 진행한다는 것은 실제로 사용자들이 이용하도록 (이 경우에는 실험군인 30%에게 신규안이 보이도록) 배포한다는 것입니다.

(6) 결과 분석 및 후속 조치

  • 2주 뒤에 실험을 종료하고, 실험군과 대조군의 2주차 잔존율을 비교합니다.
  • 만약 실험이 성공한다면 (실험군의 2주차 잔존율이 대조군에 비해 30% 이상 높다면) 신규안을 전체 사용자에게 적용합니다. 이제 모든 신규 사용자들은 홈 화면에서 A 기능을 볼 수 있게 됩니다.
  • 만약 실험이 실패한다면 (실험군의 2주차 잔존율이 대조군에 비해 30% 이상 높지 않다면) 눈물을 머금고 신규안을 폐기합니다.

굳이 실험을 하는 이유

‘왜 굳이 이렇게 번거롭게 일하나요? 그냥 우리가 가진 가설에 따라 바로 제품을 변경하면 되는 거 아닌가요?’라고 생각하실 수도 있습니다.

실험을 하는 이유는 간단합니다. 가장 큰 이유는 가설이 맞아 떨어질지 아니면 틀릴지, 다시 말해 유저들이 우리 생각대로 움직여줄지 미리 알기 어렵기 때문입니다. 유저들은 우리 예상대로 움직여 주는 존재가 아니니까요.

그리고 리스크(Risk)의 문제도 있습니다. 무슨 리스크냐면, 제품이나 서비스에서 새로운 것을 시도했을 때, 뭔가 변경을 가했을 때, 그게 잘못되었을 때 우리가 손해를 보게 될 리스크입니다.

예를 들어 앞에서 생각한 가설을 우리가 굳게 믿고, 실험 없이 곧바로 모든 사용자에게 신규안을 적용해 본다고 해 보겠습니다. 예상대로 좋은 결과가 나오면 좋지만, 신규안이 예상치 못하게 나쁜 결과를 야기할 수도 있습니다. 예를 들면 홈 화면에서 다른 기능을 잘 이용하던 사람들이 이 기능 때문에 이탈하고, 오히려 잔존율 지표가 악화될 수도 있습니다.

사용자 100%에게 신규안을 적용할 경우에는 제품이 전적으로 이 리스크에 노출됩니다. 반면 실험으로 사용자 30%에게만 신규안을 적용했을 때는 제품이 그만큼 적은 리스크에 노출됩니다. 신규안이 나쁜 결과를 야기하더라도 손해를 크게 보지 않고 끝낼 수 있습니다.

빠른 실험

이런 실험을 반복해서 수행하다 보면 대다수의 가설은 틀린 것으로 판명됩니다. 실험이 실패하는 것입니다. 실험을 10번 하면 8~9번 정도는 실패한다고들 합니다. 성공하는 1~2개의 실험이 지표를 끌어올리는 데 기여합니다. 그래서 이런 실험을 얼마나 빠른 속도로 반복할 수 있는지가 그로스 팀의 성패를 좌우합니다.

4. 크로스펑셔널한 직군의 멤버들이 협업하기

앞에서 예를 든 실험을 하려면, 크로스펑셔널(cross-functional)한 직군의 멤버들이 협업해야 합니다. 디자이너와 엔지니어가 제품을 수정하고, 데이터 분석가가 실험 설계 및 결과 분석을 합니다. 마케터가 고객 커뮤니케이션을 하고, 프로덕트 매니저가 전체적인 실험 과정을 관리합니다.

그로스는 ‘그로스 해커’ 한 명이 하는 일이 아닙니다. 그로스를 잘 이해하는 프로덕트 매니저 , 그로스를 잘 이해하는 엔지니어, 그로스를 잘 이해하는 디자이너, 그로스를 잘 이해하는 마케터, 그로스를 잘 이해하는 데이터 분석가…가 모여서 하는 일입니다.

다시 말해서 그로스 팀의 멤버 구성은 프로덕트 팀의 구성과 크게 다르지 않습니다. 프로덕트 팀에 PM, 엔지니어, 디자이너 등이 있듯이 그로스 팀에도 PM, 엔지니어, 디자이너 등이 있습니다. 제가 개인적으로 안타까운 것은, 그로스 팀을 구성하겠다고 하면서 엔지니어, 디자이너 없이 '그로스 해커'와 데이터 분석가만으로 이루진 팀을 만들겠다고 하는 얘기를 하는 분들이 종종 보인다는 점입니다. 데이터를 분석하고 실험 아이디어를 내는 사람만으로는 실험을 할 수도 없고, 어떻게 어떻게 제품팀에서 엔지니어와 디자이너의 시간을 빌린다고 하더라도 빠른 실험을 반복하는 것은 불가능합니다.

그로스 팀의 조직 구성에 대해서는 Andrew Chen(Andreessen Horowitz, ex Uber)이 쓴 <How to build a growth team – lessons from Uber, Hubspot, and others> 를 참고해 보시길 바랍니다. SEO처럼 테크니컬한 분야를 제외하면 거의 모든 경우에 PM, 엔지니어, 디자이너가 팀에 포함됩니다.  

그로스에 대한 오해들

그로스라는 분야가 최근에 생긴 분야이다 보니, (그리고 요 몇 년 사이에 buzzword가 되면서) 오해도 많습니다. 그로스에 대해 제가 지금까지 들었던 오해들을 다뤄 보겠습니다.

그로스에 대한 오해: 눈 가리고 코끼리 만지기

그로스 매니저로서 일했던 한 회사에서, 팀 분들로부터 이런 말들을 들었습니다. (지어낸 말이 아닙니다)

  • “그로스는 데이터를 분석하면서 하는 마케팅이죠?”
  • “민우님이 그로스 매니저니까 프로모션 페이지 만드는 거 해 주세요."
  • “민우님은 가입자 수 늘리는 일 하는 건가요?”

음... 데이터를 분석하면서 마케팅하기, 프로모션 페이지 만들기, 가입자 수 늘리기가 그로스가 하는 일이 '아닌' 것은 아닙니다. 그로스가 아니라고 할 수는 없긴 한데… 이런 느낌인 거죠. 눈 가리고 코끼리 만지기 같은.

눈 가리고 코끼리 만지기
  • 상아를 만지는 사람은 ‘코끼리는 날카로운 창이다!’라고 말하고,
  • 코를 만지는 사람은 ‘코끼리는 길다란 뱀이다!'라고 말하고
  • 귀를 만지는 사람은 ‘코끼리는 넙적한 부채다!’라고 말하고
  • 몸통을 만지는 사람은 ‘코끼리는 커다란 벽이다!’라고 말하고
  • 다리를 만지는 사람은 ‘코끼리는 나무 같은 원통이다!’라고 말하고
  • 꼬리를 만지는 사람은 ‘코끼리는 밧줄 같은 것이다!’라고 말하겠죠.

그게 코끼리가 '아닌' 것은 아니지만, 그렇다고 그게 코끼리라고 할 수는 없는 그런 거죠… 그로스도 마찬가지입니다. 앞에서 말씀드린 것처럼, 그로스는 제품이나 서비스를 성장시키기 위해 / 핵심 지표를 중심으로 / 크로스펑셔널한 직군(엔지니어, 디자이너, 데이터, 프로덕트, 의 멤버들이 모여서 실험을 통해 배움을 얻고, 이를 빠르게 반복하는 것입니다.

그렇기 때문에

  • 단기적으로 커다란 부스팅을 하기 위해 프로모션을 이용하기도 하고
  • 트래픽을 높이기 위한 액션 아이템을 실행하기도 하고
  • 데이터를 분석해서 퍼포먼스 마케팅을 하기도 하고
  • 인간 심리를 활용한 판매 방식 (‘오늘만 할인', ‘정가는 20만원이지만 여러분에게는 특별히 10만원에 판매’ 등)을 통해 매출을 높이기도 합니다.

하지만 중요한 것은, 핵심 지표를 정의하고, 그 지표를 향상시키기 위해 끊임없이 실험을 반복하는 것입니다. 그 실험은 심지어 제품 그 자체를 변경할 만큼 제약 없이 하는 것이구요.

그로스에 대한 오해: “우리는 핵심 지표 OOO을 늘려야 한다. 그러니 핵심 지표를 바로 늘릴 수 있는 ㅁㅁㅁ를 해야 한다!” (핵심 지표 개선 방법에 대한 오해)

그로스 일을 하면서, 들었던 오해들 중 또 큰 부분을 차지하는 것이, 지표를 개선하는 방법에 대한 오해입니다. 예를 들면 이런 것들입니다.

  • “이번 달 매출이 떨어졌으니까 매출을 끌어올릴 수 있는 이벤트를 기획해서 실행해 주세요."
  • “사용자 잔존율(리텐션율, retention rate)이 떨어졌으니까, 푸시 메시지를 보내서 사용자들이 앱에 들어오도록 해야겠어요."
  • “주간 활성 사용자(weekly active users, WAU) 수를 늘려야 하니까, 푸시 메시지를 보내서 사용자들이 앱에 들어오도록 해야겠어요.”

모두 언뜻 보기에는 아무 문제 없는 얘기인 것 같습니다.

  • 매출을 끌어올리는 이벤트를 해서 잘 먹히면 매출이 올라가는 것은 사실이고
  • 사용자들에게 푸시 메시지를 보내서 앱에 다시 들어오게 만들 수 있으면, 리텐션율이 높아지는 것은 사실이고 ('푸시로 유저들이 들어오게 만들 수 있으면'이라는 단서가 붙지만)
  • 사용자들에게 푸시 메시지를 보내서 앱에 들어오게 만들 수 있으면, 앱에 들어오는 사람이 늘어나니까 당연히 WAU 지표도 증가하는 것도 사실이니까요. (여기에도 '푸시로 유저들이 들어오게 만들 수 있으면'이라는 단서가 붙지만)

그런데 여기엔 문제와 해결책에 대해 다음과 같은 가정이 숨어있습니다.

  • “이번 달 매출이 떨어졌으니까 매출을 끌어올릴 수 있는 이벤트를 기획해서 실행해 주세요.”
    • 가정: ‘매출 감소'라는 문제에는 '매출을 끌어올리는 이벤트를 하는’ 것이 효과적인 해결책이다.
  • “사용자 잔존율(리텐션율, retention rate)이 떨어졌으니까, 푸시 메시지를 보내서 사용자들이 앱에 들어오도록 해야겠어요.”
    • 가정: ‘리텐션율 감소’라는 문제에는 ‘푸시메시지를 보내서 앱에 들어오도록 하는 것’이 효과적인 해결책이다.
  • “주간 활성 사용자(weekly active users, WAU) 수를 늘려야 하니까, 푸시 메시지를 보내서 사용자들이 앱에 들어오도록 해야겠어요.”
    • 가정: ‘주간 활성 사용자 수 부족’이라는 문제에는 ‘푸시메시지를 보내서 앱에 들어오도록 하는 것’이 효과적인 해결책이다.

조금 더 생각해 보면 이런 얘기들은 의학으로 치면 대증요법입니다. 통증이 심하니까 진통제를 먹는 걸로 끝낸다든지, 열이 심하게 나니까 해열제를 먹는 걸로 끝낸다든지 하는 것과 비슷한 거죠.

그럼 대증요법이 아닌 그로스는 무엇일까요? 지표를 어떻게 개선하는 게 좋은 방법일까요? 여기에서 활용하기에 좋은 멘탈 모델이, 'Output과 Input을 나눠서 생각하기'입니다.

  • 사업 성과를 보여주는 지표들은 대부분 Output metric입니다.
    • 예: 매출, 리텐션율, WAU, MAU 등
  • Output metric은 여러 가지 Input을 투입한 결과로서 나타납니다.
    • 예: 리텐션율(retention rate)이라는 지표(Output)는 ‘Activation, Engagement, Resurrection’이라는 Input들이 작용한 결과로 나타납니다. (각각의 Input이 무엇을 뜻하는지는 지금은 모르셔도 됩니다. Output은 여러 Input을 투입해서 나오는 결과라는 것만 기억해 주세요)
  • Output metric을 개선하고 싶을 때, ‘어떻게 Output metric을 개선하지?’를 고민해서는 답이 나오지 않습니다. 왜냐면 Output에 직접적으로 영향을 미치는 것은 정-말 어렵기 때문입니다.
    • 예: ‘리텐션율을 어떻게 개선하지?’는 직접 해결하기에는 너무 큰 질문입니다. 리텐션이라는 결과는 여러 가지 요인이 합쳐진 끝에 나오니까요.
  • Output metric을 개선하고 싶다면, Output metric에 영향을 끼치는 Input들이 무엇인지 정의하고, ‘어떻게 하면 Input을 개선할 수 있을까?’라는 질문을 해야 합니다.
    • 예: ‘리텐션율을 어떻게 개선하지?’보다는, ‘리텐션의 핵심 Input 중 하나인 Activation을 어떻게 개선하지?’라는 질문에서 더 actionable한 답을 도출할 수 있습니다.
    • 예: 한 발짝 더 나가면, Activation이라는 Input을 다시 더 세부적인 Input들로 쪼개 보면 더 actionable한 답을 도출할 수 있습니다. ‘어떻게 Setup moment를 만들지? 어떻게 Aha moment를 만들지? 어떻게 Habit moment를 만들지?’와 같은 식으로… (다시 말씀드리지만, 각각의 Input이 뭔지는 지금은 모르셔도 됩니다. Output은 여러 Input을 투입한 결과라는 것 하나만 기억해 주세요.)

개념적인 얘기들을 늘어놔서 잘 와닿지 않을 수 있는데, 이해를 돕기 위해 비유를 들어서 설명해 보겠습니다. (제가 만든 비유는 아니고, Reforge에서 만든 비유를 인용하겠습니다.)

농구 경기가 있다고 해 보겠습니다. 농구 경기에서는 점수를 많이 내야 이깁니다. 점수를 내려면 뭘 해야 할까요? 여러 가지 플레이를 성공시켜야 합니다. 각 플레이어들이 적절하게 상대팀과 매치업을 해야 하고, 스크린도 해야 하고, 압박도 탈출해야 하고, 패스도 해야 하고 등등… 점수는 이런 Input들이 차곡차곡 쌓인 끝에 나오는 결과(Output metric)입니다.

이미지 출처: Reforge, https://www.reforge.com/blog/north-star-metric-growth

만약 ‘점수를 더 내야 한다’라고 생각해서 그냥 무턱대고 슛만 던진다면 그 팀은 자멸하게 될 겁니다. 그로스 핵심 지표를 향상시키기 위해서도 무턱대고 ‘그 지표에 직접적으로 영향을 끼칠 것 같은’ 일만 하는 게 아니라, 그 Output Metric에 영향을 끼치는 Input들이 무엇인지 정의하고, 그 Input을 개선하는 것이 필요합니다. 이 점을 이해하면, 우리는 그로스에 대해 다른 관점을 가질 수 있습니다.

(기존 관점) “우리는 매출을 늘려야 한다. 그러니 그로스는 매출을 바로 늘릴 수 있도록 판매를 위한 이벤트와 프로모션을 하자! 그게 제일 효과적으로 매출을 늘리는 방법이다!”

(새로운 관점) "매출에 영향을 끼치는 Input은 무엇일까? 그중에서 지금 활용했을 때 가장 효과적인 것은 무엇일까?"

  • 앞에서 말한 것처럼, 매출은 Output Metric입니다.
  • 매출을 개선하려면 매출에 영향을 주는 Input을 개선해야 합니다.
  • 매출에 영향을 주는 Input은 여러 가지가 있습니다. 대강 쪼개서 보면 이런 것들이 있습니다. 구독 사업의 매출을 예시로 들어 보면, 매출이라는 Output metric은 다음과 같이 세부적인 Input metric들로 쪼개집니다.
    • 구독 사업의 매출 (Output metric)
      • 신규 결제 매출
        • 신규 가입자 수
        • 신규 구독자의 결제 전환율
          • 신규가입자의 활성화율
          • 활성 사용자의 결제 전환율
      • 재결제 매출
        • 기존 구독자의 재결제율과 이탈률
        • 기존 구독자가 더 비싼 가격제로 이동 (expansion이라고 부릅니다)
        • 기존 구독자가 더 저렴한 가격제로 이동 (contraction이라고 부릅니다)
      • 이탈고객의 부활(resurrection이라고 부릅니다)
  • 위와 같은 Input metric을 개선하기 위해서 건드릴 수 있는 레버(Lever, 지렛대)역시 여러 가지 있습니다.
    • 가격 책정 방식(Pricing)을 변경할 수도 있고, 고객에게 제안하는 가치(Value proposition)를 더 잘 다듬을 수도 있고, 기존 구독자들이 제품에서 가치를 얻어가도록 도울 수도 있고, 더 좋은 제품을 제공해서 더 비싼 돈을 내게 할 수도 있고 등등…
    • 이벤트와 프로모션은 지표를 개선하기 위해서 건드릴 수 있는 레버들 중 하나입니다. 이런 레버를 효과적으로 활용하는 것은 좋은 일입니다.
    • 하지만, 오직 그것만이 전부라고 생각하고 다른 좋은 레버들을 고려하지 못한다면, 그래서 더 효과적인 지표 개선 방법을 놓치게 된다면 그건 문제입니다.
  • 다시 한번 말씀드리지만, 그로스에서는 단기적인 부스팅을 위한 이벤트와 프로모션 같은 활동들을 부정하지 않습니다. 전체적인 프레임워크 안에서 잘 쓴다면 얼마든지 효과를 만들어 낼 수 있으니까요. 단기적인 부스팅이 그로스의 모든 것이라고 생각하지만 않으면 됩니다.

(기존 관점) “우리는 주간 활성 사용자(Weekly Active Users)를 늘려야 한다. 그러니 푸시메시지를 보내서 사용자를 앱에 들어오게 하자! 그게 WAU 늘리는 데는 직빵이다!”

(새로운 관점) "WAU에 영향을 끼치는 Input은 무엇일까? 어떤 레버를 당겼을 때 가장 WAU를 증가시키는 데 효과적일까?"

  • 앞에서 말씀드린 것처럼, WAU도 Output metric입니다.
  • WAU를 늘리려면, WAU에 영향을 주는 Input을 개선해야 합니다.
  • WAU라는 Output metric은 다음과 같이 세부적인 Input metric들로 쪼개질 수 있습니다.
    • 이번 주에 신규 가입한 사용자 수
      • 신규 회원 가입자 수
      • 전환율: 신규 회원 가입자들 중 몇 퍼센트가 ‘활성 사용자’가 되나?
      • 전환율: 신규 회원 가입자들 중 몇 퍼센트가 서비스에 접속하나?
      • 전환율: 서비스에 접속한 사용자들 중 몇 퍼센트가 활성 사용자가 되나?
      • (참고로, 서비스에 접속한 사용자가 곧 활성 사용자는 아닙니다. ‘활성 사용자’라는 정의에 부합하는 사용자가 활성 사용자입니다. 보통은 서비스에서 핵심적인 액션을 한 사용자를 ‘활성 사용자’라고 정의합니다.)
    • 기존에 가입한 사용자 중 이번 주에 활성화된 사용자 수
      • 가입 cohort별 사용자 수
      • 가입 cohort별 서비스 접속 전환율
      • 서비스 접속한 사용자들의 활성사용자 전환율
  • 이런 Input metric을 개선하기 위해서 건드릴 수 있는 레버역시 여러 가지가 있습니다. 일부만 열거해 보면…
    • 신규 가입자를 늘리기 위한 마케팅하기.
      • 새로운 채널 시도하기
      • 기존 채널 최적화하기
      • 마케팅 크리에이티브 변경해 보기
    • 사용자들이 계속해서 이용하게끔 Activation 시키기
      • 사용자들이 습관(habit)을 형성하게 하기
      • 사용자들이 제품의 가치를 느끼게 하기(aha moment)
      • 사용자들이 제품의 가치를 느낄 수 있는 준비를 시키기 (setup moment)
    • Activation된 사용자들이 계속해서 이용하도록 하기
      • 사용자가 계속해서 서비스를 인지하게 만들기
      • 사용자가 서비스를 사용하고 싶어할 만한 타이밍에 잘 Trigger를 주기 (예: 푸시알림)
  • 기존 가입자들에게 푸시알림을 보내서 서비스에 접속하도록 하는 것은, WAU라는 Output metric을 움직이기 위해서 동원할 수 있는 수많은 레버들 중 하나입니다.
  • 그로스를 잘하기 위해서 필요한 것은, 여러 레버를 파악하고, 그중 어떤 레버가 효과적일지 우선순위를 정해서 실행하는 것입니다. 가장 머릿속에 먼저 떠오르는 레버부터 실행하는 것이 아니구요!

그로스 팀은 프로덕트 팀과 어떻게 다른가요?

여기까지 읽으신 분은 그로스 팀이 마케팅 팀과는 다르다는 것을 쉽게 알아차리셨을 겁니다. 조금 더 상세한 설명을 원하시는 분은 퍼블리에 발행한 <그로스 해킹, 마케팅과 어떻게 다른가요?>를 읽어 주세요.

그런데, 지금까지 한 설명으로는 그로스 팀과 프로덕트 팀이 어떻게 다른지 이해하시는 데는 불충분할 겁니다. 이런 질문이 드실 수 있을 겁니다.

  • 그로스 팀도 제품을 건드리는데, 그럼 프로덕트 팀과 무엇이 다른가요?
  • 그로스 팀과 프로덕트 팀의 멤버 구성(PM, 엔지니어, 디자이너, 분석가 등)이 거의 같은데, 두 팀의 역할이 어떻게 다른가요?

여기에는 페이스북에서 그로스 팀을 처음 이끌었던 차마스 팔리하피티야(Chamath Palihapitiya, CEO at Social Capital)가 잘 정리해 줬습니다. 프로덕트와 그로스의 차이를 요약하면

  • 프로덕트 팀의 존재의 이유는 ‘Building Core Value’ 즉, 고객들에게 제공할 핵심 가치를 제품으로 만들어 내는 것이고
  • 그로스 팀의 존재의 이유는 그렇게 만들어진 핵심 가치를 최대한 많은 사람이 경험하게 만드는 것입니다.
이미지 출처: Brian Balfour, https://brianbalfour.com/essays/growth-vs-marketing-vs-product

이것만으로는 ‘무슨 소리지?’ 싶으실 테니, 비디오 커뮤니케이션 앱 Zoom을 예로 들어서 설명드릴게요.

Zoom 팀은 Zoom이라는 제품으로 고객들에게 이런 가치들을 제공합니다.

  • 멀리 떨어진 사람들과 원격 회의를 할 때 컨퍼런스 콜을 세팅하기 힘들다.
    → 프로덕트 팀이 화상 회의 솔루션을 만듦으로써, 쉽고 안정적으로 여러 사람이 원격으로 회의를 할 수 있게 해 줍니다.
  • 원격 강의, 웨비나를 진행하려고 할 때 참여자를 모으고, 관리하고, 참여자들과 상호작용까지 하려면 많은 노력이 필요하다.
    → 프로덕트 팀이 비디오 웹 세미나 솔루션을 만듦으로써, 웨비나에 필요한 모든 기능을 원스탑으로 이용할 수 있게 해 줍니다.

프로덕트 팀의 역할은 이렇게 고객의 문제를 파악하고, 고객의 문제를 해결할 수 있는 해결책을 제품으로써 만들어서 고객에게 전달하는 것입니다. 이를 위해 고객의 문제를 이해하고, 문제를 해결할 솔루션을 기획하고 구현해서 고객에게 전달하는 일을 합니다.

반면, 그로스의 초점은 ‘우리가 고객에게 이렇게 좋은 가치를 제공하고 있는데, 어떻게 하면 더 많은 사람에게 이 가치를 전달할 것인가?’입니다. (추가로, ‘이를 통해 어떻게 돈을 더 많이 벌 것인가?’도 있습니다)

아무리 좋은 제품과 좋은 기능을 만들어 놓았더라도, 사용자들/고객들이 실제로 제품과 기능을 이용해야 가치를 만들어낼 수 있습니다. 더 많은 사람에게 가치를 전달하기 위해서는 많은
사용자를 획득(Acquisition)해야 하고, 그들을 활성화(Activation)시켜야 하고, 활성화된 사용자들이 계속 이용하게(Retention) 해야 합니다. 기업으로서 돈을 더 많이 벌기 위해서는 사용자들이 제품에서 얻어 가는 가치를 매출(Revenue)로 전환시켜야 하구요.

만약 화상 회의 솔루션, 비디오 웹 세미나 솔루션 등의 제품이 고객의 문제를 해결해 주는 멋진 기능임에도 아직 많은 사용자들이 제품에서 그런 경험을 하지 못하고 있다면, 그로스 팀이 나설 차례입니다. 퍼널의 어느 단계에서 문제가 있는지, 혹은 지표를 개선할 기회가 어디에 있는지 파악하고, 어떤 레버를 당겼을 때 가장 효과적일지 가설을 수립하고, 그 가설이 맞는지 틀린지 확인할 수 있는 실험을 설계해서 진행하고, 실험 결과에 따라 후속조치를 하는 일을 합니다.

다시 요약하면 프로덕트 팀은 고객들에게 제공할 '핵심 가치'를 제품으로 만들어 내고, 그로스 팀은 그렇게 만들어진 핵심 가치를 최대한 많은 사람이 경험하게 만듭니다. 똑같이 PM, 엔지니어, 디자이너 등으로 구성된 팀이고 제품에 영향을 끼치는 팀이라 하더라도, 역할이 이렇게 다릅니다.

그로스 PM의 역할은 무엇인가요? (부제: 자기소개서)

저는 주로 그로스 프로덕트 매니저(PM)로서 일해 왔습니다. PM은 PM인데, 그로스에 집중하는 PM인 겁니다.

PM의 역할: Discovery와 Delivery

여기서 PM은 (PO, PM 포지션이 있는 몇몇 회사에서 정의하는 것과는 달리) ‘의사결정권자인  Product Owner보다 아래 단계에 있는, 기획 실무자’를 뜻하는 것이 아니라, ‘프로덕트의 성공을 책임지는 사람’을 가리킵니다. PM은 제품의 책임자로서 고객의 문제를 파악하고, 팀(주로 엔지니어 및 디자이너들)과 협업해서 문제를 해결하고 고객에게 가치를 전달하는 과정을 책임지는 역할을 합니다.

PM들은 이를 위해서 크게 ‘Discovery’와 ‘Delivery’ 영역의 업무들을 합니다. (Discovery는 무엇을 만들지 정의하는 일, Delivery는 실제로 그것을 만드는 일입니다. 참고자료) 편의상 제가 겪었던 업무들을 가지고 말씀드리면

Discovery: 제품에서 무엇을 만들지 정의하기 위한 일

  • 고객의 문제를 이해하기 위해 정성조사(인터뷰와 설문조사, 사용성 테스트 등)를 하고
  • 고객의 행동을 파악하기 위해 데이터를 분석하고
  • 제품이 사업에서 가치를 내게 만들기 위해 회사 내부 이해관계자들과 커뮤니케이션하고,
  • 고객의 문제가 무엇인지 정의하고
  • 여러 문제 중 어떤 문제를 해결해야 하는지, 우선순위를 정의하고 (회사의 비전과 전략을 고려해서)
  • 문제를 해결하기 위한 방법을 프로덕트 팀 동료들(엔지니어, 디자이너 등)과 함께 아이디에이션하고
  • 각각의 아이디어 뒤에 팀이 갖고 있는 가설을 명확히 하고 (문서화, 문서화…)
  • 어떤 아이디어를 실제로 제품으로 구현할지 정합니다. (의사결정)
  • 그리고 이 과정에서 프로덕트 팀원들(특히 엔지니어와 디자이너)이 전체적인 맥락을 이해할 수 있도록 커뮤니케이션합니다.
  • 프로덕트 매니저가 (회사의 의사결정 구조에서) 더 높은 레벨로 올라가면, 우리 제품이 어디로 나아가야 하는지 비전(Vision)을 정하고, 그 비전을 달성하기 위해 어떻게 해야 하는지 전략(Strategy)을 정하는 일도 하게 됩니다.

Delivery: 실제로 제품을 만드는 일

  • 사실 실제로 제품을 만드는 일은 디자이너와 엔지니어가 합니다.
  • Delivery 단계에서 프로덕트 매니저의 역할은 ‘제품이 우리가 가고자 하는 방향으로 잘 갈 수 있도록’ 디자이너와 엔지니어를 서포트하는 것입니다.
  • 구글의 Ken Norton은 제가 처음으로 프로덕트 매니저 직군에 관심을 갖게 한 분인데, 이런 말씀을 했습니다. “최고의 프로덕트 매니저들은 팀이 성공하는 데 도움이 되는 것이라면 뭐든지 하려고 한다. (I believe the best product managers are willing to do whatever it takes to help their teams succeed.)"(https://www.bringthedonuts.com/donuts/)
  • 이를 위해서 PM은 디자이너 엔지니어들과 커뮤니케이션을 열심히 하기도 하고,
  • 뭔가 디자이너와 엔지니어들이 하기 애매한 일들(예: QA)을 하기도 합니다.
  • Ken Norton은 이렇게도 말씀하셨습니다. “프로덕트 매니저는 PM이 하지 않으면 누락되기 쉬운 업무를 해야 한다는 것을 인지해야 한다. 그런 업무들은 그 정의상 때묻고 재미 없는 일들이다. 버그 목록을 정리하고, 문서 저장소를 정리하고, 고객 서포트 이메일에 답하는 등의 일들. 하지만 프로덕트 매니저들은 이런 일들도 해야 한다. (An important aspect of that is recognizing that PMs often have to do the work that would fall through the cracks otherwise. By definition that can be grimy, un-fun work: cleaning the bug queue, organizing a document repository, replying to a customer support email. No job should be beneath a product manager.)”(https://www.bringthedonuts.com/donuts/)
  • 그러면서, Ken Norton은 ‘PM은 팀에게 도넛을 가져다 주는 사람’이라는 유명한 말을 남기기도 했습니다. (https://www.bringthedonuts.com/essays/leading-cross-functional-teams.html)
  • 어쨌든, 요약하면 PM은 엔지니어와 디자이너들이 프로덕트를 잘 Deliver할 수 있도록 서포트하는 역할을 합니다.

그로스 PM의 역할: 역시 Discovery와 Delivery

제가 생각하는 그로스 프로덕트 매니저의 역할도 마찬가지로 Discovery와 Delivery로 나뉩니다. Discovery는 어떤 그로스 실험을 할지 정의하는 일이고, Delivery는 그 실험을 실제로 Deliver하기 위해 팀을 서포트하는 일입니다.

Discovery: 어떤 그로스 실험을 할지 정의하는 일

  • 그로스 실험을 잘 하려면, 고객을 잘 알아야 합니다.
  • 이를 위해 정성조사(인터뷰, 설문 등)를 하고
  • 고객의 행동을 파악하기 위해 데이터를 분석하고
  • 제품이 어떻게 성장하는지 프레임워크(Framework)를 정의합니다.
    • 우리 고객들은 어떤 사람들인지 페르소나(Persona)를 정의하고
    • 고객들을 특성에 따라 세그멘테이션(segmentation)하고
    • 고객들이 제품에서 어떤 여정을 거치는지 정의하고
    • 성장 관련 핵심 지표를 정의하고,
    • 핵심지표에 영향을 끼치는 Input과 레버(Lever, 지렛대)을 정의하는 등
  • 이번 실험에서는 어느 레버를 당겼을 때 가장 성장을 만들어내는 데 효과적일지, 우선순위를 정의하고
  • 그 레버를 당기는 실험을 어떻게 수행할지 정의합니다.
  • 가설 설정: 가설을 명확히 하고,
  • 실험 설계: 가설을 실험하기 가장 좋은 방법을 정의하고(실험 설계),
  • 실험 결과의 성공 여부를 어떻게 평가할지 사전에 정의하는 등의 일을 합니다.
  • 이 과정에서 함께 실험을 진행할 엔지니어와 디자이너들과 함께 커뮤니케이션하며, 엔지니어 디자이너들이 충분히 맥락을 이해할 수 있게 합니다.

Delivery: 실제로 그로스 실험을 하는 일

  • 일반 PM과 마찬가지로, 엔지니어와 디자이너를 서포트하는 모든 역할을 합니다.
  • 커뮤니케이션도 하고, 누가 해야 할지 애매한 일(예: 운영상의 업무들)이 있으면 그것도 하고…
  • 실험이 끝난 뒤 결과를 평가하고, 회고를 통해서 앞으로의 개선 방안(어떻게 하면 우리가 1) ‘더 좋은’ 실험을 할 수 있고, 2) 실험을 ‘더 나은 방식으로’ 할 수 있을지)을 찾는 것도 그로스 PM이 중요하게 하는 일입니다.

이 정도면 그로스 PM이 (그리고 제가 😉) 대략적으로 어떤 역할을 하는 사람인지 이해하시는 데 도움이 되지 않을까 생각합니다. 업무의 모든 부분을 글로 설명하려니 쉽지는 않지만, 어느 정도는 윤곽을 잡으시는 데 도움이 되길 바랍니다.

마무리

이렇게 그로스란 무엇인지, 그로스에 대한 오해는 어떤 것들이 있는지, 어떤 식으로 그로스를 생각해 볼 수 있는지, 그로스 팀의 역할이 무엇인지, 그로스 PM은 어떤 일을 하는 사람인지 알아 보았습니다.

이 글은 일종의 개론이고, 앞으로 가설, 실험, 지표 설정, 데이터 기반의 의사결정 문화 만들기 등에 대해서 이 뉴스레터를 통해 더 전달해 드리려고 합니다. 여러분이 그로스를 좀 더 잘 이해하시는 데 제 글이 도움이 되길 바랍니다. 긴 글 읽어 주셔서 감사합니다!