지원

지원님의 아티클

지원

지원

5일만에 가입전환률 18% 서비스를 만들었어요 😎

안녕하세요! 오랫만에 글을 쓰는 것 같아요 :) 지난 기간동안 여러 고민끝에 2주간 아이디어를 테스트했고 나름 괜찮은 성과가 있어서 디콰에 처음 들고왔어요!


최종적으로 표본 356명의 광고 유입 유저로부터 18%의 가입전환률을 기록했어요! 검증에 사용한 페이스북 광고의 평균 CVR 9.21% 인데, 우리는 2배의 수치를 기록했어요. 이러한 가설 검증을 통해 해당 아이디어가 고객 니즈가 있다고 판단하여 본격적으로 서비스를 멋지게 만들어 사업화할 예정입니다.


우리가 만든 서비스에요 >> 바로가기


0. Problem?

가장 협업이 많은 직군 중 하나가 개발자라고 생각해요. 포트폴리오에 협업한 코드 없는 개발자는 찾기 힘든 정도니까요. 근데 항상 이 네트워킹이 지인풀에서만 해결되는게 아쉬웠어요. 그래서 그런가 개발자들은 이런거나 이런거를 많이해요. 그런데도 늘 개발자들은 협업할 개발자를 찾는데 어려움을 겪더라구요. 쪼끔 더 나아가 혹시 이건 개발자들만의 문제가 아닐지도 모른다는 생각도 했구요.


1. Solution!

많은 이야기 끝에 우리는 개발자를 포함한 커리어 시장 그 자체에서 아래와 같은 가설을 세웠어요.


가설1.

💡 사람들은 자신의 커리어와 관련된 제안 및 네트워킹에 대한 수요가 존재할 것이다.


가설2.

💡 사람들은 가설1의 수요를 해결할 수 있다면, 자신의 프로필을 공개적으로 기꺼이 등록할 것이다.


가설3.

💡 우리는 이 데이터를 가지고, 재미난 유료 모델 시도를 마음껏 할 수 있다.


가설1/2/3을 차례대로 검증한다면 우리가 정의한 문제를 근본적으로 해결할 수 있을 것이라고 결론을 내렸어요.

이 때, 가설3의 재미난 유료 모델은 이미 동작하고 있는 BM들이 시장에 존재해서 우리는 가설1과 가설2만 검증하기로 했어요.


2. 가설검증 계획

기존에 우리 팀이 2번 시도했던 아이디어들의 검증 방식은 겉핥기 식이었다는 실수가 있었어요. 랜딩페이지 테스트를 1회만 하거나, SNS를 통해 유사한 형태의 서비스를 제공하는 방식이었는데요.

이러한 간접적인 검증은 편향 데이터나 오류가 많으며, 실제로 니즈 검증까지 도달하는데 많은 시간을 낭비했다고 생각해요. 따라서 우리는 직접적인 검증과 동시에 2주라는 짧은 시간 안에 테스트를 해야한다고 결론내렸고 그 방식은 “아이디어 불패 법칙의 XYZ 가설 검증” 방식으로 접근했어요.


XYZ 가설이란 ‘이 제품은 적어도 X퍼센트의 Y는 Z할 것이다' 같은 구체적이고 검증 가능한 명제를 말한다. 그리고 이를 검증하는 방법인 Pre-totyping 을 구성하라.
‘유능한 실행력'은 실패에 대한 해결책이 되지 못한다. ‘대부분의 신제품이 실패하는 것은 설계나 개발, 마케팅이 허술해서가 아니라 그냥 그 제품이 시장이 원하는 제품이 아니기 때문이다’
제대로 만들기 전에, ‘될 놈' 을 만들어라

-아이디어 불패의법칙 1장 발췌-


우리는 가설 검증 데이터를 확보하고, 우리의 데이터와 일반적으로 알려진 평균값을 비교해 니즈를 파악해보기로 했어요. 이때, 테스트마다 표본 구성은 100명 내외로 정했어요. 그리고 그 표본집단은 페이스북 타게팅 광고를 통해 도달시키고자 했구요.


2. 가설검증 (XYZ)

우리에게 있어서 가설1을 테스트할 수 있는 최적의 표본집단은 개발자 집단이에요. 제가 대학에서 컴퓨터공학을 전공했고, 주변에도 보통 다 개발자라서 집단의 특성을 이해하고 고객의 입장에서 가설을 제시하기에 적합하다고 생각했어요.


개발자 집단은 타 직군에 비해서 협업에 니즈가 더🔥 존재한다고 생각했어요. 구직 시에도 팀 프로젝트 위주로 평가하는 경우가 많고, 협업이 빈번하기 때문이에요. 당장 주변만 봐도 팀을 구해서 개발을 진행하는 사례를 볼 수 있구요. 그리고 최근에 노션으로 개발자 이력서를 만들어서 블로그나 Github에 등재하는 문화가 생기고 있다는 점을 보아 개발자들 간의 네트워킹에 대한 수요가 높을 것이라고 예측했어요.


많은 아이디에이션 이 후! 우리는 [개발자]라는 집단에게, [팀 빌딩/스터디/기술 자문/커리어 고민 등]이라는 네트워킹 제안을 주고받을 수 있는 서비스가 있을 때 반응을 이끌어 낼 수 있는지를 검증하기로 의견이 모였어요! 그리고 XYZ 가설은 다음과 같아요.


💡 (XYZ) 팀 빌딩/스터디/기술 자문/커리어 고민 등 개발자간의 네트워킹 제안을 주고 받을 웹사이트가 있다면, 네트워킹을 원하는 개발자의 적어도 30%는 웹사이트에 가입할 것이다.


일반적인 전환률이 20%면 탑티어 지표라는 여러 사례와 데이터를 찾아볼 수 있었어요. 우리는 더 높은 30%를 목표치로 가설을 일단 설정했어요.

초기에 우리는 4개의 xyz1 가설과 2개의 xyz2 가설을 세우고 내부 데이터를 쌓기로 했습니다. xyz1의 경우 랜딩페이지 수준으로 검증이 가능했으며, xyz2는 회원가입이 존재하는 프로덕트여야 했습니다.


3. 유저 니즈 검증

XYZ 가설에 대한 로컬 테스트인 xyz는 아래와 같이 최종 정리되었어요.

💡 (xyz1-a) 사이드 플젝/스터디 등을 같이할 개발자를 찾는 사이트가 있다면, 수도권에 거주하는 20대 개발자 중 랜딩 페이지 접속자의 적어도 30%는 이메일을 남길 것이다.


💡 (xyz1-b) 사이드 플젝/스터디 등을 같이할 개발자를 매칭 시켜주는 사이트가 있다면, 수도권에 거주하는 20대 개발자 중 랜딩 페이지 접속자의 적어도 30%는 이메일을 남길 것이다.


💡 (xyz1-c) 사이드 플젝/스터디 등을 같이할 개발자를 찾는 사이트가 있다면, 랜딩 페이지 접속한 경희대학교 SW융합대학 재학생 중 적어도 30%는 이메일을 남길 것이다.


💡 (xyz1-d) 사이드 플젝/스터디 등을 같이할 개발자를 찾는 사이트가 있다면, 수도권에 거주하는 20대 개발자 중 랜딩 페이지 접속자의 적어도 35%는 ‘지금 시작하기’ 버튼을 클릭할 것이다.


💡 (xyz2-a) 사이드 플젝/스터디 등을 같이할 개발자를 찾는 서비스가 있다면, 수도권에 거주하는 20대 개발자 중 랜딩페이지 접속자의 적어도 10%는 회원 가입할 것이다.


💡 (xyz2-b) 사이드 플젝/스터디 등을 같이할 개발자를 찾는 서비스가 있다면, 수도권에 거주하는 20대 개발자 중 웹사이트 접속자의 적어도 20%는 회원 가입할 것이다.


팀이 자체 개발이 가능하기에, 예전 같았으면 직접 개발했겠지만 모르는 아이디어에 시간을 많이 투자하는 것이 비효율적이라는 것을 깨달았기에 고민이 많았어요.


노코드툴을 활용해서 회원가입이 가능한 서비스 수준으로 구축이 가능함을 확인했으나, [노코드툴을 지금 배워서 제작 vs 직접 개발] 했고, 결과적으로 xyz1는 노코드툴을 사용하고 xyz2는 싱글페이지 수준으로 직접 개발하는 것으로 결정했어요.

그 이유는 노코드툴이 UI 위젯을 그리는데는 최적화된 툴이지만, 회원가입과 같은 데이터 작업이 필요한 경우는 외부 플러그인을 연동하는 경우가 많았어요. 더욱이 생각보다 자료도 많지 않다고 느꼈습니다. 그에 비해 회원가입 정도는 하루 이틀이면 금방 구현할 수 있고, 자료도 구글에 널렸으니 회원가입이 필요한 프로덕트는 최소한으로 줄여 구현하기로 했어요.


여러 형태의 랜딩 페이지 중 우리는 토스의 초기 랜딩 페이지처럼 (핵심 가치+이미지+CTA)의 구성으로 만들어서 [프로덕트]에 대한 설명이 아닌, [고객의 니즈]에 대한 지표를 확인하기로 했어요. 유저들에게 핵심적이지 않거나, 이미 완성된 형태의 특징과 화면을 보여준다면 사람들은 유저 니즈가 아닌 프로덕트에 대한 수요를 바탕으로 해석할 것이라고 생각했기 때문이에요.

사람들의 니즈는 일반적으로 변하지 않는다고 생각해요. 그러나 프로덕트는 우리가 변화시킬 수 있어요. 고객의 소리를 듣고, 그들이 원하는 형태의 프로덕트로 만들면 되거든요. 그렇기에 우리는 변하지 않는 지표인 니즈를 측정해야 했기에! 위와 같이 최소한의 컨셉 설명 수준으로 랜딩페이지를 만들어 보았어요.


1차 테스트는 [광고 클릭 → 랜딩페이지 이메일 남기기] 였습니다.


첫번째 검증 결과는 생각보다 유의미했어요. 광고 클릭 유저 98명 중 이메일 남긴 사람 29명이나 되었어요. CVR 29.6% , CTR 3.88% 라는 수치가 나왔어요! (FaceBook AD 평균 CVR 9.1%, CTR 0.89%)


------


전부 올리고 싶은데... 이미지가 계속 안올라가서요 😭 노션 링크로 대체하겠습니다. 이후에 실제 결과 지표를 모두 써놨으니 다른 메이커분들이 도움되었으면 좋겠어요!

여러가지 뒷이야기가 궁금하신 분들은 커피챗 해주시면 연락드릴게요!


이야기 더보기

19
5
지원

지원

이 개념을 알면 실패는 줄어듭니다! 토스의 한계수용력

안녕하세요! 토스 PO 세션 영상을 통해 얻은 인사이트를 공유하고자 합니다. 🙄

사실 저희 팀원들에게 제가 정리해서 공유했던 내용인데, 다듬어서 로깅하려고 정리 해보았습니다.

디스콰이엇 유저분들처럼 자신의 프로덕트를 성장시키기 위해 고민 중이신 분들에게 도움될 것 같습니다. 혼자 생각 정리한 부분이라서, 풀영상을 보시는 것도 추천드립니다!

영상 링크(https://www.youtube.com/watch?v=tcrr2QiXt9M)


Chapter.0] 개념을 짚기 전에 생각해볼 문제!

당신의 충성 유저들이 어떤 특정 행동을 하는 것을 알게됐다. 그랬을 때 모든 유저로 하여금 해당 특정 액션을 하도록 유도하는게 서비스에 도움이 될까? 예를 들어, 프로필 사진을 충성 유저들은 다 채운다! 그러면 프로필 사진 채우기를 강제하도록 유도하는 것과 같이 말이다.

답은 고민해보실 수 있도록, 맨 밑에 소개하겠습니다 :)


Chapter.1] 한계수용력 정의

해당 영상에서 제시하는 한계수용력의 개념은 웅덩이안 빗물의 크기로 빗대어 표현합니다. 아래 사진과 같은 상황입니다.



위와 같은 질문에 보통은 웅덩이가 패인 정도! 라고 대답할 수도 있을 것 같습니다.

그렇지만 한계수용력을 표현하기 위해서는 다음과 같은 대답이 더 적절할 것입니다.


내리는 비의 양(유입량) 대비 흙으로 스며드는 양(유실량)에 의해 정해진다입니다.

해당 영상에선 유입량을 Inflow, 유실량을 Churn 이라는 단어로 표현했는데요.

이 유입량 대비 유실량이 바로 Carrying Capacity. 한계수용력 입니다. 생태이론에서 실제 사용되는 용어라고 하네요.


이를 서비스 관점에서

Carrying Capacity = New Customers Daily(Inflow) / Lost Customers Daily(Churn Rate) = 한계수용력 이라고 정의할 수 있습니다.


예를 들어 봅시다. 한 서비스에 7,500명이 매일 신규 고객으로 들어오며, 매일 1% 고객을 잃습니다. 그렇다면 이 서비스의 C.C는 7,500/0.01 = 750,000명이며, 해당 숫자가 서비스가 자연스레 도달할 수 있는 고객수(대게 MAU)를 추측할 수 있는 식이 됩니다.

만약 해당 서비스가 현재 MAU 750,000명일 경우, 들어오는 고객이 7,500명이고 나가는 고객이 7,500명(전체 1%)이므로 계속 MAU에 변동이 없을 것이라고 볼 수 있습니다.


이때 고객의 정의도 중요한데요. 단순히 앱을 깐다고, Active한 유저가 아니라는 것은 잘 아실겁니다. Meaningful Action 을 하는 유저들만을 Customer로 정의해야하기 때문입니다. (근데 이건 토스 입사해야만 알려준대요..😂)

제가 아는 서비스 중 하나는 3개 이상 컨텐츠를 소비하는 유저를 Active User 라고 보는 곳도 있고, 영상에선 95% 이상의 Visitor가 꼭 하는 행동이라고 표현했네요. Case By Case!

반대로 Lost Customer의 정의도 중요합니다. 해당 유저가 꼭 삭제해야만 이탈되었다고 할수는 없을 것입니다. 마찬가지로 케바케인 것 같아, 스스로 고민해보시는걸 추천드립니다.


Chapter.2] C.C가 왜 중요할까요?

바로 "아무리 마케팅 지출을 늘려, 매일 새로 들어오는 유저를 늘려도 분모의 매일 잃는 유저 비율에는 큰 변화가 없을 것" 이므로 "결국 750,000명이라는 C.C에 다시 도달할 것이다" 라는 논리로 귀결시킬 수 있기 때문입니다.

결국 Inflow와 Churn Rate를 본질적으로 바꾸지 않으면, 서비스는 결코 성장할 수 없다는 것입니다.

그리고 우리가 집중해야 할 것은 Churn Rate 입니다. 유입된 유저들이 느낀 문제를 해결하는 확실한 경험을 주어야, 서비스에 유저가 남아있을 것이고 이는 곧 Churn Rate를 줄이는 방향이기 때문이죠.

추가로 불필요한 마케팅비를 줄일 수 있습니다. 가령 C.C가 750,000명인 서비스가 600,000명 가까이 MAU가 발생할 때는 어차피 자연스럽게 해당 숫자에 도달할 수 있기 때문에, 도달 이전에 광고를 꺼도 된다! 라고 이야기할 수 있습니다. (토스도 미리 준비하고, 그러했다고 하네요)


Chapter.3] C.C를 활용한 프로덕트 운용 방식

토스의 경우, 초기 간편송금 모델의 C.C가 300만 이라고 하는데요. 이 숫자를 이해하고 있었기에 토스가 C.C에 도달하기 전에, 신용조회 서비스 런칭과 같은 신규 피쳐를 통해 새로운 C.C를 만들어낼 수 있었다고 합니다(C.C가 1000만이었대요!)

새로운 피처나 서비스를 런칭하면 완전히 새로운 가치에 대한 C.C가 생길 것 입니다. 우리는 계속해서 이 C.C를 늘릴 방법을 찾고, 제시하는 등 서비스를 고도화하고 제품을 개선해야 한다고 생각합니다😋


더 나아가 결국 C.C의 개념이 주목하고자 하는 부분은 마케팅이 아니라, 본질적인 문제해결에 집중해야 한다는 점을 시사한다고 생각합니다. 우리가 아무리 새 배너 광고를 띄워도(=Inflow 증가) 우리 프로덕트가 가진 C.C에 한계가 존재한다면, 밑빠진 독에 물붓기와 같은 무의미한 마케팅비 지출만 발생할 것입니다.


그래프로 그리면 좋은 프로덕트는 아래와 같이 그리는게 맞겠네요!

초기 C.C를 가진 프로덕트에 문제 정의와 해결을 통해 C.C를 끌어올리고, 다시 새로운 문제 정의로 해결을 하고! 무한 반복

당근마켓을 예로 들면 초기에는 중고거래로 초기 C.C를 채우고, 서비스 지역을 확장하여 중간 C.C를 채우고, 지금과 같은 커뮤니티화를 통해 최종 C.C에 도달했다고 비유할 수도 있겠네요.(이게 최종이 아닐지도..)


Chapter.4] 그래서 챕터0 정답은..

앞서 제시한 문제 정답 혹시 고민해보셨나요?

저같은 경우, 유저에게 강제한다는 의미가 사실 조금 꺼려지긴 했는데요. 안되지 않을까...? 하는 생각이었죠.

토스 이승건 대표님의 답은 Yes or No 입니다. 그럴수도 있고, 아닐수도 있다.

해당 기능을 도입했을 때, C.C에 악영향을 주면 No 이고, 악영향이 없으면 Yes..

그만큼 C.C가 중요하다는 질문이기도 하겠네요.


잡담

저도 프로덕트를 개발하는 입장에서 많은 조언을 들으러 다니고, 고민해보았던 입장이라 매우 공감가는 내용이었습니다. 최근에 시리즈A 펀딩 받으신 분께 1대1로 조언을 들을 수 있는 자리가 있었는데요.

"네가 해결하고자 하는 문제 정의가 제대로 서지 않는다면, 무의미하게 들어왔다 나가는 유저만 생길 것이다. 다운로드 수는 높지만, 유저는 없는.."

이와 같은 말씀을 해주신게 기억이 납니다. 앞서 제시한 개념이랑 매우 유사한 말씀이라서 더 와닿네요. 결국 그때부터 다시 정신차리고 문제 정의부터 확실하게 한 문장으로 정리도 했습니다. :>


19
13