초기 유저의 문의 데이터로 기능 구현하기
V.O.C 수집부터 기능 구현, 데이터 분석까지
투두몰은 일잘러의 투두리스트로 빠른 능동적 학습을 도와주는 서비스로, 회사에서 사용하는 다양한 오피스 툴을 주제로 학습 콘텐츠를 제공한다. 서비스를 런칭한 지 벌써 1.5개월이 지났는데, 매일 유저가 꾸준히 들어와 클래스를 구매하고 있다. 구매 전환율, 학습 완주율 등 전반적인 지표도 만족스러운 모습을 보이고 있다.
스타트업을 위한 빠르고 쉬운 교육 서비스!
기업 도입이 궁금하면,
hello@todomall.kr로 연락 주세요!
기능 구현 유무 판단하기
1. 이 기능이 정말 필요해?
나홀로 사이드 프로젝트를 많이 해온 덕분에 서비스 기획부터 빌드, 데이터 처리 등 서비스의 AtoZ를 혼자서 처리할 수 있다. 더군다나, 작업 속도 자체가 빠른 덕분에 혼자서 기능을 만드는 데 빠르면 하루, 길어봐야 3일 안에 구현하고 있다. 기획부터 빌드, 분석까지 혼자 하는 모습을 상상하면 눈물겹지만, 창업 팀에서 최적화된 능력이기도 하다.
기능 빌드 시간이 짧다고 한들, 기능을 무작정 만들지 않는다. 팀원들이 자신이 생각한 아이디어를 들고 왔을 때, "이 기능이 정말 필요해?"라는 질문을 먼저 던지다. 그리고 설득이 타당하지 않으면, 후순위 백로그로 밀어버린다.
다 만들지는 않습니다. (출처 : <SBS - 학교의 눈물>)2. 질문을 답해주세요!
기능을 구현할지 결정하기 위해 (1) 리소스, (2) 임팩트와 (3) 범위와 관련된 질문을 던진다.
A. [리소스] 기능의 전체 라이프타임에 필요한 리소스는 얼마인가?
B. [임팩트] 유저가 이 기능으로부터 느끼는 가치는 얼마인가?
C. [범위] 다른 영역에서도 사용이 가능한가?
A. [리소스] 기능의 전체 라이프타임에 필요한 리소스는 얼마인가??
기능 리소스를 평가할 때, 전체 라이프타임을 기준으로 평가한다. 여기서 칭하는 라이프타임은 기획, 빌드, QA부터 유지 보수까지 포함한다. 리소스를 단순히 빌드적 측면에서만 산정한다면, 이후에 유지 보수를 할 때 놓친 부분에 의해서 계속 리소스를 뺏길 수도 있다. 더군다나, 배포한 기능은 이후에도 꾸준히 신경 써서 관리를 해줘야 한다. 기능을 어찌어찌 만들었는데, 이후에 이 기능을 유지하기 위해 리소스가 더 들어가는 불상사가 발생할 수도 있다.
B. [임팩트] 유저가 이 기능으로부터 느끼는 가치는 얼마인가?
기능은 유저가 가치를 느껴야지, 비로소 의미를 지닌다. 아무리 빠르고, 잘 만든 기능이라 할지라도 유저가 사용하지 않으면, 기능은 의미가 없다. 그렇기에 우리 팀이 좋다고 생각할지라도, 과연 타겟 유저가 이 기능을 정말로 가치 있게 사용할지를 고민한다. 또한, 기능을 직접 사용하면서, 얼만큼의 가치를 느낄지를 유추한다.
C. [범위] 다른 영역에서도 사용이 가능한가?
해당 기능을 다른 영역에서도 활용할 수 있는지도 고려한다. 한 가지 기능을 처음에 생각한 영역 외에서도 활용할 수 있다면, 그만큼 기능 개발의 효율성이 증가시킬 수 있다. 예를 들어, 최근에 구현한 보육 기관 제휴 기능이 있다. 해당 기능은 창업 보육 기관과 제휴를 맺기 위해 구현했다. 해당 기능을 통해 "계약을 맺은 창업 보육 기관"의 산하에 있는 "피보육 기업"이 투두클래스를 무료로 다운로드할 수 있는 권한을 부여할 수 있다.
이러한 제휴 기능은 다른 영역에서도 사용할 수 있다. 예를 들어, 보육 기관을 "마이플랜잇"으로 설정하고, 피보육 기업을 "일반 기업"으로 치환할 수 있다. 그러면, 같은 기능으로 내부 구성원의 역량 상승을 꾀하는 일반 기업에게 영업을 진행할 수 있다. 혹은, 피보육 기업을 "일반 개인 유저"로 치환할 수도 있다. 그러면, 인플루언서, 엠베서더, 서포터즈 등으로 사용할 수도 있다.
유저가 정말 필요로 하는 기능일까?
1. 초기 유저의 이야기를 들어봅시다.
앞서 언급한 요소 중에서 임팩트는 내부적으로 판단하기 힘들다. 기능의 가치는 우리가 아닌, 유저의 시선에서 정의되기 때문이다. 그렇기에 서비스 런칭 후, 초기 사용자의 이야기를 수집하는 게 중요하다. 직접 서비스를 사용한 분의 이야기를 들어봐야 유저가 어떤 기능을 정말 필요로 하는지 빠르게 파악하고, 기능을 올바른 방향으로 구현할 수 있다.
투두몰에서는 유저가 쉽게 자신의 이야기를 말할 수 있도록, 서비스 내 [문의하기]를 메인으로 내세우고 있다. 문의하기 버튼을 클릭하면, 바로 카카오 채널로 연결돼서 빠르게 응답을 남길 수 있다. 사실 문의하기 버튼을 넣었을 때, 유저가 실제로 문의를 남겨주실까란 생각을 했었다. 하지만, 우려가 무색하게도, 많은 분이 서비스를 이용하면서 불편하다고 느낀 점을 이야기하고 있다. 덕분에, 유저가 어떤 기능을 필요로 하는지 에 대한 데이터를 수집할 수 있었다.
2. 문제 현상 인식하기
일정 주기마다 유저가 남긴 문의를 정리해서 클러스터링 하고 있다. 겹치는 문의가 많을수록, 해당 문의와 관련된 니즈를 유저가 크게 느낌을 뜻한다. 최근에 가장 많이 들어온 문의로 "클래스를 구매했을 때, 학습이 당장 시작되나요?"가 있었다.
투두몰은 유저의 주도적이고 빠른 학습을 장려한다. 이를 위해 클래스를 세션이란 단위로 쪼개고, 각 세션마다 학습할 투두와 과제를 제공한다. 세션마다 적정 데드라인이 부여되며, 데드라인 안에 모든 학습을 완료해야 한다. 주어진 데드라인 안에 학습을 완료하지 못하면, 클래스가 소멸된다. 물론, 미처 못한 분들을 위해 재도전 기회도 부여하고 있다.
처음에 유저가 해당 문의를 남긴 이유는 결제 페이지에서 각 세션의 데드라인에 대한 안내가 부족했기 때문이라고 판단했다. 하지만, 좀 더 고찰해 보니 해당 가설은 유효하지 않음을 확인했다. 주변 지인들을 대상으로 사용성 테스트를 해본 결과, 클래스 상세 소개 페이지와 결제 페이지에서 학습 기간에 대한 표기가 명확히 인식되고 있었다. 또한, 대다수의 학습 콘텐츠 서비스는 구매 즉시 학습 콘텐츠를 접근할 수 있다. 즉, 유사 서비스의 사전 경험을 고려해 봐도, 클래스가 구매 즉시 시작 됨을 쉽게 유추할 수 있었다.
3. 문제의 근본 원인 해결하기
유저가 해당 문의를 남긴 근본적 이유를 쫓기 위해, 타겟 유저의 구매 당시 상황을 고려했다. 즉, "학습이 지금 시작되냐고 물어본 이유는 무엇일까?"이 아니라, "학습이 지금 시작되냐고 물어봤을 당시에 유저는 어떠한 상황에 있을까?"를 생각했다.
질문을 바꿔보니, 유저가 남긴 문의 속에 담긴 의미를 파악할 수 있었다. 유저가 남긴 문의는 "클래스를 구매했을 때, 학습이 당장 시작되나요?"가 아니라, "클래스를 지금이 아닌, 나중에 시작할 수 없나요?"였다. 투두클래스의 타겟은 직장인과 창업인을 메인으로 한다. 이들이 우리 서비스를 주로 접속하는 시간대는 퇴근 후, 늦은 저녁이나 밤 시간대이다. 내일 출근을 생각해야 하는 분들에게 학습 데드라인이 당장 주어지는 건 부담스러운 일이다. 적어도, 주말과 같이 여유로운 날에 클래스를 편하게 학습하고 싶을 수 있다.
결과적으로, 유저가 필요로 하는 기능은 클래스를 미리 구매하고, 자신이 여유롭게 학습할 수 있는 날에 시작할 수 있게 만드는 것이다.
만드는 데 얼마나 걸릴까?
1. 필요한 UI와 로직은?
임팩트가 큰 기능이라고 판단됐으니, 그다음으로 리소스 규모를 산정했다. 우선, 리소스를 더 정확히 판단하기 위해 기능 범위를 더 명확히 정의해야 했다. 플로우 차트를 그리며, 대략적으로 필요한 UI와 로직을 추정했다.
플로우 차트를 기준으로 봤을 때, 크게 아래의 UI 및 로직을 구현해야 했다.
[UI] 결제 페이지의 학습 시작일 컴포넌트 추가
[Logic] 학습 시작일 설정 로직 구현
[UI] 내 학습 페이지에서 나중에 시작하는 클래스의 카드 컴포넌트 유형 추가
[Logic] 오늘 바로 시작하기 로직 구현
2. 기존 자원을 그대로 활용하기
리소스 산정 시, 과대 평가하지 않도록 기존 자원을 최대한 활용하는 쪽으로 생각한다. 우선 결제 페이지의 학습 시작일 컴포넌트는 기존 컴포넌트를 그대로 활용하면 됐다. 또한, 시작일 설정 로직도 기존 로직에서 기준 시간만 변경하면 됐다. 기존 로직은 클래스의 구매 시간을 기준으로, 각 세션의 데드라인을 계산하는 설정하는 방식이었다. 여기서 사건 기준을 구매 시간이 아닌, 유저의 선택일로만 수정만 하면 로직 구현은 끝나는 일이었다.
클래스 시작일 등록이란 이벤트가 생김에 따라, 클래스를 구매한 이후의 고객 여정도 바뀔 필요가 있다. 나중에 진행하고자 한 클래스를 지금 당장 시작하고 싶을 수도 있기에, 학습 페이지에서 클래스를 지금 바로 시작하도록 변경하는 컴포넌트와 로직을 구현해야 했다. 다만, 이 컴포넌트와 로직도 기존의 것을 그대로 사용하면 되기에, 공수가 그리 많이 들지 않으리라 판단했다.
결과적으로 임팩트는 크고, 리소스는 적다고 판단되어 바로 기능 구현에 들어갔다. 4시간 정도를 투자해 기능 구현을 완료했다.
창업 팀은 일하고 또 일해야... (출처 : <네이버 웹툰, 역대급 영지 설계사>)데이터로 분석하기
1. 2주간 동향 비교하기
배포한 기능은 얼만큼의 수치 변화로 이어졌는지 항상 체크해야 한다. 그렇지 않으면, 정말 이 기능이 유효했는지 파악하기 힘들뿐더러, 액션에 대한 인사이트를 수집할 수도 없다. 기능 배포 전후의 2주간 데이터를 비교 분석했다. 파이썬의 pandas 라이브러리를 이용해 GA 데이터와 DB 데이터를 전처리 및 조인하고, seaborn을 이용해 데이터를 시각화했다.
일부 코드. 다들 판다스 하세요! 파란색 선은 클래스 상세 페이지를 방문한 유저, 주황색 선은 클래스를 구매한 유저를 뜻한다. 차트를 보면, 기능 배포일이 지난 후에 갑작스레 유입 유저가 늘었다. 이는 해당 일자에 투두몰 마케팅 액션을 집행했기 때문이다. 기능 배포일 전후로 유저 수가 크게 변화했기에, 다른 수치로 기능의 유효성을 판단해야 했다.
구매 전환율 데이터를 집계해 보니, 기능 배포일 전보다 우상향 곡선을 그리는 걸 볼 수 있다.
2. 데이터 분포로 확인하기
앞선 차트는 시계열 차트로, 데이터의 추세를 보는 데 용이하지만 분포를 파악하는 데 적합하지 않다. 보다 정확한 분포 구간을 확인하기 위해 일 별 전환율을 히스토그램으로 그려봤다. 히스토그램은 데이터의 빈도를 나타낸 그래프로, 차트에서 Peak가 보이는 부분이 데이터가 많이 나타 남을 뜻한다. 파란색 선은 기능 배포일 이전, 주황색 선은 기능 배포일 이후의 데이터를 뜻한다. Peak 부분을 봤을 때, 주황색 선이 파란색보다 더 높은 위치에 높게 있음을 볼 수 있다. 즉, 전환율 분포가 훨씬 개선 됐음을 보여준다.
물론 AB 데이터가 아닌, 전후 데이터를 비교했기에 100% 정확하다고 말할 수 없다. 다만, 추세 및 분포도를 볼 때 상승 패턴을 확인할 수 있으므로 해당 기능은 유효하다고 판단 내렸다. 창업 팀은 하루 빨리 많은 걸을 해내고 싶어 한다. 다만, 촉박함에 의해서 비이성적인 의사결정을 내리는 건 위험하다. 긴장감과 촉박감을 구분할 줄 아는 사람이 되도록 노력해 보자!
스타트업을 위한 빠르고 쉬운 교육 서비스!
기업 도입이 궁금하면,
hello@todomall.kr로 연락 주세요!
