얼마 전 클래스101은 “클래스101+” 라는 이름의 구독 서비스를 출시 했습니다. 클래스 하나의 가격이 평균 20만원에 달했던 것을 생각해보면 파격적인 비즈니스 모델(BM) 변화인데요. 오늘은 지난 구독 전환기 1편에 이어 클래스101이 BM 피봇을 어떻게 결심하게 되었는지, 그리고 300명이 넘는 전사원이 함께 6개월만에 MVP를 만들고 출시하기까지의 과정을 소개해 보고자 합니다.
왜 클래스101은 구독을 시작했을까?
22년 초 클래스101은 더 큰 성장을 위해 유저 층을 확대하고, 유저들이 더 오래 잘 클래스101을 사용하게 하기 위해 어떤 것이 필요할까 고민했어요.
“가격이 비싸서 시도에 허들이 있어요”
“클래스가 만족스럽지 않을 경우, 환불의 경험이 좋지 않아요”
“수강 기간에 제한이 있어서 잘 들을 수 있을까 하는 생각에 구매가 망설여져요”
개별 클래스의 평균 객단가는 20만원이 넘습니다. 높은 가격대에 많은 유저는 구매 자체에 허들을 느꼈고 만약 이렇게 구매한 클래스가 기대와 달랐을 경우 실망감을 느끼기도 했습니다. 또한 대부분의 클래스는 5개월의 제한된 수강 기간을 가지고 있었는데, 이 기간 제한은 유저들이 클래스 시작을 주저하거나 구매 후에도 압박감을 느끼게 하는데 작용하고 있었습니다.
이런 고객의 문제를 해결하면서 지금보다 훨씬 더 많은 사람들이 클원의 비전인 “모두가 사랑하는 일을 하면서 살 수 있도록” 하려면 어떻게 해야할까? 에 대한 고민끝에는 “구독”이라는 솔루션이 있었습니다.
클래스101은 지금까지 국내에서 독보적으로 많은 클래스를 셀링하며 콘텐츠 소싱 및 제작 비즈니스 역량을 키워왔고 스트리밍과 커머스를 동시에 해결하는 제품을 만들고 안정화 해나갔습니다. 22년에는 새로운 비즈니스 모델로 더 많은 대중들에게 다가갈 수 있는 헤게모니를 만듦으로써 다시 한번 클원이 큰 도약을 만들고자 했습니다.
또 내부적으로는
- 크리에이터가 더 롱테일로 정산을 받아가지 못하는 개별 클래스 판매 모델의 정산 구조 문제
- 인앱 결제 정책으로 인해 클래스과 준비물이 결합된 상품 구조의 기존 개별 판매 모델에서는 iOS 앱에서 클래스 판매를 할 수 없었던 문제
- 글로벌 비즈니스(일본/미국)의 제품이 각각 존재해서 개발/유지/보수에 리소스가 2배 이상 들었던 문제
- 관심사 타게팅에 따라 점점 더 복잡성이 늘어가는 마케팅과 그에 따른 유저의 피로도 문제
등을 구독 모델 그리고 새로운 제품이 해결해 줄 수 있을것이라 생각했습니다.
전사가 하나가 되어 나아가기 위한 워크 프로세스
위의 문제들을 해결하는 솔루션으로 구독 BM에 대한 테스트가 리더십에서 검토 되었고, 문제 없는 전환을 위해서는 대내외 상황을 고려하여 빠른 시간 내에 전사원에게 변화를 설득하고 MVP를 통해 테스트를 진행해야한다는 결정이 이루어졌습니다. 이제 이 변화를 전사에 전파하고 실제로 제품을 빠르게 만들어 나가야 했어요.
전사에 변화의 가치를 알리고 소통을 통한 설득하기
구독 BM에 대한 논의가 시작 되었을 시점 클래스101의 구성원은 300명을 훌쩍 넘은 상태였습니다. 작은 조직일 때보다는 확실히 전사적인 변화를 설득하고 나아가는데에는 난이도가 있었는데요, 클래스101의 설득의 과정은
“구독 전환 네러티브 프로포절 문서(6 pager) 공유 → 조직 리더 및 팀원 전파 → 전사 Kick-off 진행”
의 순서로 진행되었어요.
구독 모델을 시도하는 이유와 목표를 상세하게 담은, 네러티브로 작성된 문서가 먼저 조직에 공유되었고, 이 문서에는 리더십에서 먼저 검토하며 나올 수 있는 열린 질문(ex. 왜 구독 가격은 월 19,000원인가요?)등에 대한 근거자료가 담긴 답변을 최신화해서 업데이트 하였습니다.
또 본격적으로 프로젝트가 시작하기 전에 구독 모델로의 전환에 대한 내용을 알리는 킥오프를 전사원을 초대하여 줌 미팅으로 진행했고 프로포절 문서를 간략화해서 핵심을 리뷰하고 실험 계획을 공유했어요. 미리 쌓였던 질문도 받아 이 자리에서 즉각적으로 답변하고 후속 질답을 하는 시간을 가졌습니다. 먼저 문서를 통해 오해없이 이해가 될 수 있도록 내용을 전달하고 조직별 전파 그리고 전사적으로도 눈높이를 맞추는 시간을 가져서 빠르게 전환에 대한 이해 정도를 맞출 수 있었습니다.
Escalation & Share 회의체
프로젝트가 시작되고 정산 구조, 런칭 시기, 제품 스펙 등과 같은 중요한 의사 결정들이 매일 곳곳에서 일어났습니다. 하지만 이 정보가 즉각적으로 동기화 되지 않았고, 조직간에 의논이 필요한 만큼 쉽게 결론 내리기 어려운 결정들이 많이 생겨나면서 여러 조직에서 이슈를 제기하기 시작했어요.
이 문제는 회의체가 다시 셋팅되고 공유와 이슈레이징이 활발해지면서 점차 해결되었는데요, 그 구조는 다음과 같았습니다.
도메인 별 논의체
각 도메인의 목적을 중심으로 실무자들이 참여하는 위클리 미팅입니다. 구독으로 전환 과정에서 제품팀과 비즈팀이 같이 동일한 목적을 위해 논의해야할 사항들이 많이 생겨났습니다. 이 회의에서는 현재 제품 개발 진행 상황과 제품 스펙에 대한 얼라인 그리고 액션 실행 계획 등을 논의했고, 타 팀과의 디펜던시등으로 바로 결정이 힘들거나 상위 의사 결정이 필요한 경우 리드가 Subscription Decision 으로 해당 이슈를 에스컬레이션했습니다.
Subscription Decision — 의사 결정 회의체
각 팀의 리드 + VP + 관련 아젠다의 실무자가 참여하는 미팅입니다. 도메인 별 논의체에서 에스컬레이션 된 이슈를 데이터 중심으로 리뷰하고 의사 결정이 이루어지는 자리입니다. 여기서 결정된 사항들은 다시 결정과 동시에 각 도메인과 전사에 공유되었습니다.
Subscription Townhall — 주요 결정 사항 및 진행 상황 공유체
전사가 참여하는 위클리 공유체 입니다. 각 주에 논의 되었던 주요 의사 결정 사항들과 테스트 진행 상황 및 주요 수치, 진행된 유저 리서치 결과가 전파되었습니다. 이 프로세스로 에스컬레이션과 공유가 주 단위로 빠르게 진행되면서 전사가 같은 목표를 향해서 빠르게 달려갈 수 있었습니다.
MVP를 같은 모습으로 이해하기
완전히 새롭게 제품을 개발하면서 런칭도 검증하는 단계에 따라 알파, 베타, 정식 런칭으로 나누어 진행하다보니 제품 팀과 비즈 팀간 어느 스테이지에서 어떤 기능이 개발되는지, 제품 팀 내에서도 각 도메인 별로 각 기능의 스펙과 개발 진행정도는 어떤지 파악이 어려운 순간들이 많았습니다. 이를 해결하기 위해 여러가지 액션 아이템들이 도출되고 실행되었어요.
제품의 청사진 함께 그리기 — Story Mapping Workshop
유저가 서비스에 유입해서 가치를 느끼고 지속적으로 이용하기까지의 여정을 PM, EM이 모여 함께 그려보고 우선순위로 스토리를 나열하고 Must have, Should have, Could have, Will not have 의 선을 긋는 활동을 진행했습니다. 이 활동을 통해서 단기간 내에 MVP의 비전과 큰 범위 안에서의 기능 리스트를 확정할 수 있었습니다.
전사의 프로젝트를 누구나 한눈에 — Company Roadmap Project
Story Mapping Workshop에서 결정된 스토리 목록을 바탕으로 각 도메인 PM들이 PRD를 작성하고 릴리즈 플랜을 세워나가는 과정에서 추가로 맞춰나가야할 부분들이 발견되었어요. 구독 전까지는 각 도메인별로 프로젝트를 관리하고 있었기에 한 눈에 각 런칭 스테이지 별로 어떤 기능이 개발되는지, 그리고 그 진행 정도는 어떤지, PRD는 어디에서 관리되고 있는지 등에 대한 파악이 어려웠고 다양한 도메인의 제품팀과 협업하는 비즈니스 이해관계자들은 특히 이 부분에 대해서 더 많은 어려움을 겪고 있었습니다.
모든 개발팀이 Jira 프로젝트를 활용하여 이슈 관리를 하고 있었기에 이를 활용하여 로드맵을 구성할 방법을 찾아 나갔고, 트위터의 Advanced Roadmap 활용 케이스 아티클에 영감을 받아 전사의 제품 개발 관련 주요 워크 플로우를 맞추며 Jira Advanced Roadmap을 활용하여 각 스테이지의 진행 정도와 스펙 확인이 전사 누가 봐도 용이할 수 있도록 하는것을 목표로 로드맵을 구성하고 활용했어요.
진행 정도를 가장 와닿게 가시화 하는 법 — Demo Session
개발이 어느 정도 시작되고 각 파트에서 PRD가 작성되고 실제 개발도 진행 되었지만, 크로스 도메인간 실제 개발 진행 상황 파악과 스펙 파악이 쉽지 않아 디펜던시가 있는 영역에 대해서 소통하는데 많은 시간이 들었습니다. 이런 문제를 해결하기 위해 PM 회의에서 솔루션으로 데모를 진행하자는 의견이 나왔고 이를 시작으로 매 주 수요일 해당 날짜까지 개발된 내용을 PM 내부에서 데모를 시작하게 되었습니다. 각 도메인의 PM이 개발한 피쳐를 나와 설명을 진행했고, 데모 과정에서 도메인간 서비스에 대한 이해 정도를 구현된 제품을 통해 더 확실히 이해할 수 있었고, 추가로 도메인간 겹치는 영역 등에서 추가 논의가 필요한 부분을 빠르게 발견해 낼 수 있었습니다. 기능 개발이 끝나고 QA가 시작될 시점에는 Subscription Townhall에서 전사원을 청중으로 데모를 진행하고 질문 및 피드백 시간을 가지기도 했어요.
제품에 대한 이해도를 맞추는 시간 — Bug Bash
Bug Bash는 전 사원이 함께 버그를 찾아내는 활동입니다. 서비스에 대한 이해도를 높이면서 다양한 유입 케이스 및 상태에서의 확인을 거쳐 제품의 완성도를 높일 수 있습니다. 구독에 대한 QA가 어느정도 마무리 되는 시점에 QS팀 의 기획 하에 Bug Bash 이벤트를 베타 런칭 전 이틀간 진행했어요. Bug Bash를 통해 구성원은 제품을 실제로 제품을 사용해보며 익히는 시간을 가졌고, 추가 크리티컬 이슈들을 발견해서 더욱 안정된 상태의 제품을 출시 할 수 있었습니다.
3단계에 걸친 MVP 출시 계획
출시는 알파, 베타, 정식 런칭 총 3단계에 거쳐서 이루어졌는데요 한번에 출시하기보다는 MVP를 만들고 각 Stage의 가설들을 정량적 수치로 구독 BM이 지속 가능한 모델일지 검증하면서 유저 리서치를 통해 다음 단계에서는 어떤 것을 개선해야할지를 배워나가기 위함이었습니다.
가장 중요한 것은 아무래도 피봇을 통해 더 나은 유저 리텐션 및 LTV를 보장할 수 있는지 그리고 더 많은 유저들을 데려올 수 있는지였는데요 이는 아래와 같은 지표로 드러난다고 생각했고, 프로젝션상의 목표 수치에 도달하지 않으면 구독으로의 피봇을 다시 롤백할 수 있도록 지표를 셋팅했습니다.
📌 피봇을 결정할 주요 지표들
- 각 유저 세그먼트의 구독 리텐션
- 각 유저 세그먼트 구독 전환율 & CAC
알파 테스트
알파 테스트는 가장 빠르게 유저의 반응을 보기 위해 제품 개발 기간을 최소화해서 진행했습니다. 제품이 완벽하지 않더라도 구독 모델의 본질인 다채로운 클래스를 월 19,000원에 이용할 수 있는 가치를 제공한다면 유저들의 구독 리텐션이 확보될것이라는 가설하에 기존에 서비스하고 있었던 Money+ 구독 제품을 활용하여 2주만에 제품을 만들고 매우 소수의 기존 클래스 구매 유저를 대상으로 테스트를 시작했습니다.
성능, UX상 개선의 여지가 많은 제품이었지만 알파 테스트를 통해 유저들이 구독 모델에서 더욱 활발히 활동하는 이용 리텐션을 보임을 확인했고, 목표로 하는 구독 리텐션을 상회하는 지표를 확인하여 다음 베타 단계로 나아갔습니다.
베타 테스트
베타 테스트에서는 새롭게 만든 제품의 MVP로 기존 유저가 아닌 신규 유저에게도 가치가 느껴지는 제품일지를 검증하는 단계입니다. 알파 테스트에서도 일부 데이터를 확인 할 수 있었지만 매우 소수의 유저, 그리고 기존 구매 유저에게만 딜리버되었기에 통계적으로 유의미하게 세부 데이터를 해석하기에는 한계가 많았습니다. 실제로 구독 모델이 동작하기 위해서는 신규 유저를 더 많이 데려올 수 있을지 그리고 신규 유저들의 리텐션도 기존 유저와 비슷하게 유지 되는지를 새로운 구독 MVP의 지표들을 확인해야했어요.
런칭 초기에는 목표로 하는 지표에 몇가지 지표가 미달하여 제품 개선을 통해서 수치를 개선하는 작업도 동시에 실행하며 정식 런칭을 준비했습니다.
정식 런칭
정식 런칭은 앱 출시와 동시에 모든 유저들이 접근해서 바로 구독이 가능한 상태로 서비스를 오픈하는 단계입니다.
베타 테스트를 진행할 때 개발했던 제품을 기반으로 개인화 영역과 비즈니스 목표를 달성하기 위한 주요 장치들을 보충하여 8월 25일 부터 기존 클래스101의 유저들에게도 런칭 소식을 알리고 본격적으로 서비스가 시작되었습니다.
이제 진짜 시작!
300명 규모의 스타트업에서 3월 초 부터 8월 말 까지 6개월이라는 짧은 기간 내에 BM을 바꾸고 새로운 제품을 만들어 나가는 과정을 구독 전환 PM의 관점에서 다뤄봤는데요, 이 과정속에서 클래스101의 창업 멤버인 윌리와 많은 정말 이야기를 나눴는데 한번은 “CLASS101 창업하기 vs BM 피봇하기” 중에 어떤게 더 힘든지 물어봤더니 0.1초 만에 후자가 훨씬 힘들다며 농담반 진담반 이야기를 나눴던 것이 생각이 납니다. 회사에서도 개인으로도 처음 해보는 파격적 변화라서 우당탕탕 실행하고 회고하고 프로세스를 수정하는 연속이었지만 그 과정속에서 압축적으로 많은 조직적, 개인적인 성장을 할 수 있었던 것 같아요.
이제 어려웠던 전환 과정이 유의미한 성과로 나타날 수 있도록 또 달려나가야 할 때입니다.
저희의 새로운 여정을 함께 하고 싶다면 여기를 눌러 클래스101과 함께 해주세요!
