#1. 그로스 해킹 : 그로스 해킹의 전체조건 (Product-Market Fit)

 

 

"뭐가 문제인지를 모르는게 문제다"

---

그로스 해킹의 전제 조건 : 제품-시장 적합성(Product-Market Fit, PMF)

그로스 해킹을 이해하려면 그로스 해킹의 전제 조건이 되는 제품-시장 적합성(Product-Market Fit, PMF)을 먼저 설명해야 한다.

 

보통의 서비스 기획 - 개발 - 출시 과정

1. (엄청난?) 아이디어가 있다.
2. 제품 만들기 시작
3. 제품 개발 완료 (약 6개월)
4. 서비스 런칭
5.  ...그리고 아무 일도 일어나지 않았다.
6. 홍보 시작
7. 홍보 덕분에 유저가 생긴다. 하지만, 며칠 쓰다가 이탈한다.
8. 돈을 더 지출해서 마케팅을 한다.
9. 그래도 유저들은 며칠 쓰다가 다 나간다. 이제 뭘 해야할까?

위와 같은 상황에 처하면 많은 사람들이 다음과 같이 생각한다.

"지금은 시간과 자원의 부족으로 인해 원래 기능의 30% 정도만 만들어서 내놓았으니까 서비스에 새로운 기능을 추가해서 완성도를 높이자!"

단언컨대 이 시점에 할 수 있는 가장 나쁜 결정이다.

기능이 추가되면 떠났던 사용자들이 다시 돌아올까? 입소문이 나면서 새로운 사용자들이 유입될까?

아마 몇 개의 새로운 기능을 추가한다고 해서 이러한 문제가 해결되지 않을 확률이 훨씬 더 높다.

생각해보면 이 시점에서의 문제는 명확하다.

 

뭐가 문제인지를 모르겠다는 것

 

제품 관리자가 하는 실수

1. 제품을 먼저 만들고, 그런 다음에야 고객을 찾는다.

논리적인(?) 기획서를 바탕으로 제품을 우선 만든 다음, 제품이 나오고 나서야 뒤늦게 고객을 설득하려는 경우가 무척 많다.

논리적인 기획서에서 출발한 제품이라고 해서 성공할 수 있을까? 서비스를 기획할 때 논리적 빈틈이 있는지 주도면밀하게 살피는 게 나쁜 것은 아니지만 논리에 논리를 덧칠하면서 보고서의 완성도를 높인다고 해서 제품의 성공 가능성이 높아지는 것은 절대 아니다.

기획 과정에서 내부 설득이나 보고를 위한 논리를 계속 덧칠하면서 기획하다가, 제품이 출시되고 나서야 사용자를 찾는다면 그 제품은 십중팔구 사용자에게 외면받게 될 것이다.

 

2. 기능을 계~속 추가한다.

성장하고 있는 시점에도 기능을 추가하고, 성장세가 둔화되면 기능을 추가한다.

많은 회사에서 "서비스 개선"이라는 용어를 "기능 추가"와 동일한 의미로 사용한다.

서비스에 특정 기능을 추가할 때는 관련된 운영 정책, 고객 커뮤니케이션, 로그 기록과 수집 등 기능이 추가되면서 발생하는 유지보수 리소스를 꼭 고려해야 한다.

제품의 기능이 조합이 되어서는 안된다. 제품은 가설의 조합으로 이뤄져야 하며, 그러한 가설을 테스트하기 위한 최소한의 기능으로 이뤄져야 한다.

기능이 많은 제품이 성공하는 게 아니라, 최소한의 기능으로 사용자에게 가치를 전달할 수 있는 제품이 성공한다는 점을 기억하자.

 

---

제품-시장 적합성

"아무도 원하지 않는 서비스를 열심히 만드는" 함정에서 벗어나려면 어떻게 해야할까?

이러한 함정에 빠지는 것을 방지하기 위해 린 스타트업에서는 제품-시장 적합성(Product-Market Fit)이라는 개념을 사용한다.

제품-시장 적합성 : 좋은 시장에, 그 시장을 만족시킬 수 있는 제품을 갖고 있는 것

그로스 해킹은 시장이 필요로 하는 제품을 만드는 것에서부터 시작된다. 애초에 수요가 없는 제품이라면 어떤 그로스 해킹 방법론을 사용하더라도 제품을 성공시킬 수 없다.

즉, 제품-시장 적합성을 확인한다는 것은 "우리가 만든 제품이나 서비스가 그로스 해킹을 할 만한 가치가 있는가?"라는 질문에 답하는 과정

"뭐가 문제인지를 모르는 문제"에 마주쳤을 때, 제품 개발 과정을 돌아보면서 곡 점검해봐야 하는 내용이기도 하다.

 

다음의 세 가지 질문을 통해 제품-시장 적합성에 대해 스스로 확인해 볼 수 있다.

1. 우리가 생각하는 그 문제가 진짜 있긴 한가?

많은 제품들이 존재하지 않는 문제를 가정하면서 만들어진다. 때로는 존재하지만 너무 규모가 작아서 사업화할 수 없는 경우도 있다.

제품을 개발하기에 앞서 문제라고 생각했던 것들이 정말 문제가 맞는지, 그 문제의 해결책을 내놓으면 기꺼이 그 해결책에 대한 대가를 지불할 만큼의 수요가 있는지 반드시 살펴봐야한다.

 

2. 우리가 만든 제품이 그 문제를 해결한 게 맞나?

문제를 확인했다면, 우리가 제품을 통해 제안한 솔루션이 그 문제를 효과적으로 해결했는지 확인해야한다.

문제는 잘 정의했지만 충분히 좋은 해결책을 제시하지 못하는 경우도 빈번하게 발생한다.

제품의 핵심 기능이 명확하고 그 기능이 앞서 언급한 문제를 해결하는 데 집중돼 있어야 한다.

 

3. 이 제품을 만들면서 세운 가설이 무엇인가? 그 가설이 검증됐는가?

제품은 기능의 조합이 아니라 가설의 조합이 돼야 한다.

하나의 제품을 내놓는다는 것은 검증하고자 하는 가설의 답을 내놓는 것이다.

제품을 출시한 후에는 이 제품을 통해 검증하려고 했던 가설이 무엇이었는지, 그리고 검증 결과가 어땠는지에 대한 답을 할 수 있어야 한다.

 

 

제품-시장 적합성을 확인하려면?

일반적으로 3가지 지표를 통해 확인할 수 있다.

1. 리텐션(Retention rate)

사용자들이 서비스에 얼마나 꾸준히 남아서 활동하는지를 보여주는 지표

제품-시장 적합성을 만족하는 서비스는 초기 일정 기간이 지나면 그래프의 기울기가 완만해지면서 리텐션이 안정적으로 유지되는 패턴을 보인다.

출처: brianbalfour

 

리텐션 수치를 확인할 때는 단순 비교 대신 해당 서비스가 속한 카테고리를 감안해서 지표의 건전성을 판단하는 것이 필요하다.

앱 카테고리별 리텐션 출처: Adjust

 

2. 전환율(Conversion rate)

한 단계에서 다음 단계로 넘어가는 사용자의 비율을 의미한다.

전환율을 구하려면 목표로 하는 이벤트를 정의하고, 이를 위해 거쳐야 하는 경로를 먼저 구체화해야 한다.

앱 다운로드 -> 회원 가입 -> 휴대폰 인증 -> 상품 페이지 조희 -> 구매하기 클릭 -> 결제완료

 

전환율 또한 카테고리마다 조금씩 상이하게 나타난다. 그리고 같은 카테고리에 속한 서비스 내에서도 상품에 속한 카테고리에 따라 전환율이 차이가 난다.

이커머스 상품 카테고리에 따른 구매전환율 벤치마크 출처: Adobe

이 외에도 친구를 통해 들어온 사람(전환율이 더 높다)과 광고를 통해 들어온 사람의 전환율 차이 등 전환율은 다양한 요인에 의해 영향을 받는다.

 

 

3. 순수 추천 지수(Net Promoter Score, NPS)

이 서비스를 주변 지인이나 친구에게 얼마나 추천하고 싶으신가요?

 

에 대한 답변 점수를 0~10점으로 나누는데, 0~6은 비추천 그룹, 7~8은 소극적 추천 그룹, 9~10은 적극적 추천 그룹으로 분류한다.

출처: netigate

 

NPS = (적극적 추천 그룹 - 비추천 그룹) / 전체 응답자

 

결국, 순수 추천 지수(NPS)는 "팬(fan)"에 대한 지표다.

서비스를 적당히 좋아하는 1000명의 사용자보다는 서비스를 열렬히 사랑하는 100명의 충성 사용자를 확보했을 때 그 서비스가 성공할 확률이 크게 높아진다.

 

 

보통 초창기 제품의 성공 여부를 확인할 때 설치 수, 가입자 수 등의 지표를 확인하지만, 이러한 지표는 일반적으로 제품-시장 적합성을 확인하기에 적절하지 않다. 

활동 회원 수도 마찬가지다. 초기에 마케팅 예산을 큰 규모로 투자하면 활동 회원 수는 단기간에 얼마든지 늘릴 수 있지만 제품-시장 적합성이 충분하지 않은 상황이라면 아무리 마케팅 예산을 쏟아붓더라도 결국 밑 빠진 독에 물 붓기이다.

 

제품-시장 적합성을 개선하기 위해 어떤 것들을 할 수 있을까?

해서는 안 되는 것

• 브레인스토밍
• 새로운 기능을 추가하는 것
• 잔존율이나 전환율을 개선하기 위한 실험

단순 브레인스토밍은 거의 도움이 되지 않는다. 상상속에서 만든 제품이 실제 시장의 요구사항을 담아내지 못했는데 여기에 또 다른 상상을 덧붙여 봐야 상황이 개선될 리 없기 때문. 새로운 기능을 추가하는 것은 이 시점에서 할 수 있는 가장 나쁜 선택이다.

이 단계에서의 목적은 제품-시장 적합성을 찾는 것이고, 리텐션과 전환율은 이를 확인하기 위한 수단으로 활용해야 한다. 리텐션과 전환율을 높이는 것을 목적으로 하고, 이를 위한 실험을 해서는 안된다.

 

해야하는 것

• 사용자를 직접 만나서 이야기를 듣기
• 사용자 행동 데이터 분석

이 시기에 해야 하는 가장 중요한 일은 사용자에 대해 더 많이 연구하고, 사용자를 이해하려고 노력하는 것이다.

사용자가 우리의 의도대로 서비스를 잘 사용하고 있는지, 우리가 포착하지 못한 숨겨진 니즈는 없는지, 실제로 제품을 사용하는 맥락이나 환경이 우리가 생각한 것과 동일한지에 대해 상요자의 생각을 직접 들어보고 그 행동을 꼼꼼하게 관찰해야 한다.

 

이 시기에 필요한 것은 1:1 사용자 인터뷰와 행동 관찰

1. 미래가 아닌, 과거와 현재에 초점을 맞춘 질문을 할 것
2. 가정이 아닌, 경험을 물어볼 것
3. 결과가 아닌, 과정을 깊이 살펴볼 것
4. 기억이 아닌, 습관을 통해 드러난 구체적인 경험을 확인할 것
5. 일반화된 진술이 아닌, 개인의 경험이 드러날 수 있도록 질문/답변할 것
6. 편향된 믿음을 확인하는 과정이 아닌, 순수한 호기심으로 접근할 것

 

사용자 인터뷰는 내가 생각한 가설을 확인하는 과정이 아니고 사용자의 목소리와 의견을 통해 제품에 대한 사용 경험과 맥락을 깊이 있게 이해하는 과정이다.

• 기대했던 답변을 끌어내기 위한 유도 질문X
• 사용자가 답변한 내용을 문자 그대로 해석X - 사용자가 이야기해주는 것은 '정답'이 아닌 '맥락'이라는 점에 유의

인터뷰는 정성적인 데이터를 수집해서 제품의 PMF를 찾아가는 과정

정량적인 데이터를 사용할 수도 있다. 제품을 사용하는 과정에 대한 사용자 행동 로그를 잘 기록하고 있다면 사용자들이 어떤 시나리오에서 어떻게 행동하는지를 이해하는 데 큰 도움이 된다.

 

 

느낀 점

"우리가 생각하는 그 문제가 진짜 있긴한가?"에서 생각한 것은, 우리가 지금 문제라는 것을 억지로 끄집어내서 만들어내고 있는게 아닌가? 라는 생각이 들었다. 억지로 "이런 문제가 있을거야" 라며 문제를 정의해버린다. 무언가, 문제를 해결하기 위해서 서비스를 만드는 느낌이 아니라, 우리가 만들려는 서비스에 해당하는 문제를 억지로 찾는 느낌. 물론 이 방법이 틀렸다는 건 아니지만, 항상 무언가 프로젝트를 진행할 때마다 회의감이 들었다. 그리고 이 책을 보면서 조금 명확해진 것 같다. 처음에는 문제를 먼저 제시하고 서비스를 개발하지만, 결국 서비스에 기능을 붙이고 개선하려고 하다 보면 주객이 전도된다. 서비스에 문제를 끼워 맞추는 상황이 되어버리는 것이다. 처음에 가정한 문제가 규모가 작거나 하는 등의 문제가 있기도 하지만 말이다.

 

그리고 "뭐가 문제인지를 모르는 게 문제다"라는 말은 조금 무서운 것 같다. 내가 하고 있는 서비스가 잘 되지 않아서 무엇을 더 해야 잘 될지 모르는 것이라고 생각할 수도 있지만, 정작 내가 가는 방향이 옳다고 맹신하여 정말로 이 길이 맞다고만 생각하여 "문제"라는 것 자체를 인식하지 못하는 경우도 있을 것이기 때문이다. 그래서 그 전에 서비스에 대한 시장의 반응을 살펴보고 "문제"라는 것을 인식하는 게 중요하다고 생각이 들었다.

 

"제품은 기능의 조합이 아니라 가설의 조합이 되어야 한다"라는 말에서도 공감을 느꼈다. 우리는 기능을 강조해서 제품을 출시하는 게 아니라, 먼저 가설을 세우고 이러한 가설이 시장에서 먹힐 것인지를 확인하는 것을 목적으로 제품을 출시해야 한다는 것을 느꼈다. "아 우리 제품은 이런이런 기능을 내세워서 시장을 공략해야지"가 아닌, "아 우리 제품이 어떠어떠한 이유로 시장에서 잘 먹힐 것이고, 사용자가 우리 제품을 일정기간 사용한 이후에는, 이러이러한 부가적인 요소들로 인해 시너지를 발휘해서 시간이 지날수록 점점 사용자가 늘어날 거야" 라던가.

 

그리고 제품-시장 적합성을 개선하기 위해 기능 추가 혹은 사용자를 더 끌어모으기 위한 실험보다는 솔직 담백하게 사용자에게 이야기를 듣고 개선할 점을 찾는 것이 더 중요하다는 것도 공감할 수 있었다.