쏘카 PM의 차량 예약 퍼널 단계 개선기(feat. AB TEST)

안녕하세요, 쏘카에서 PM(Product Manager)으로 일하는 루시아입니다. 이 글은 쏘카 PM이 쏘카에서 어떤 생각을 가지며 일하는지를 알 수 있는 내용을 담은 글입니다. 제품과 관련된 AB TEST 사례를 공유해 PM분들이 데이터 기반 사고 과정을 얻길 희망해 글을 작성했습니다.

구체적으로 더 말씀드리면 쏘카 부름 서비스의 성장 방법을 찾기 위해 신규 부름 UX의 AB TEST를 진행했던 경험을 작성했습니다. 제가 PM으로서 사용자의 마음을 들여다보고, 문제를 해결 방법을 도출한 과정을 공유합니다.

글의 목차는 다음과 같습니다.

1. 우리 사용자들은 부름 서비스를 알고 있을까요?
2. 부름을 어떻게 전달하면 사용자들이 알아볼까요?
3. 부름을 새로운 모습으로 소개합니다.
4. 느낀 점

다음에 해당하신다면 글을 끝까지 읽어보시는 것을 추천드립니다.

• PM, PO가 일하는 방식이 궁금한 분
• PM, PO가 문제를 어떻게 해결하는지 궁금하신 분
• 사용자의 생각을 통해 서비스 성장점을 찾는 방법을 고민 중인 분
• 기획자에서 더 나아가 제품의 성장 어젠다를 발굴하는 역할에 흥미가 있는 분
• AB TEST를 사용해 제품을 개선한 AB TEST 예시가 궁금하신 분

쏘카 PM은 앱/웹/인터널 프로덕트 등 회사 내의 여러 제품을 관리하는 역할을 합니다. 저희들은 문제 분석과 어젠다 발굴의 주체일 때도, 제품 기획자일 때도 있습니다. 실제로 경험해 보면 굉장히 동적이고 다면적인 일입니다. 이전에 마리가 작성해 주신 글인 쏘카 PM(Product Manager)은 어떻게 성장하나요?을 읽어보시면, 저희 그룹의 분위기를 더 느끼실 수 있습니다.

저는 평소에 프로젝트 안에서 매우 다양한 문제와 만나고 있습니다. 그리고 문제의 원인을 찾기 위해 노력합니다. 물론, 문제의 원인을 파악하는 과정이 쉽지는 않습니다. 위로 보고 아래로 보고 다양한 관점을 토대로 파악하려고 합니다. 쏘카 PM들은 사업, 운영, 프로덕트의 동료들과 셜록 홈스 뺨치는 주도면밀한 관찰을 해야 합니다. 이렇게 머리를 쥐어짠 🤯 끝에는, 문제 해결 방법을 도출합니다. 즉 가설을 설정하게 됩니다.

가설을 설정하는 과정에서 다음과 같은 고민을 할 수 있습니다

• 선택한 가설과 가설에 기반한 문제 해결 방법이 맞는지를 어떻게 사전에 판단할 수 있을까요?
• 새로운 기능(또는 새로운 UX)을 사용자들은 과연 좋아할까요?
• 새로운 기능을 배포한 후, 지표는 잘 나올까요?

가설을 도출한 후에는 그 가설이 올바른 문제 해결 방법인지 확신을 얻는 과정이 필요합니다. 이렇게 확신을 얻기 위해 쏘카 PM은 AB TEST를 사용합니다.

AB TEST란?

가설이 실제로 들어맞는지를 확인하기 위해 실험군/대조군(A, B 혹은 그 이상)으로 사용자 그룹을 구분해 서로 다른 버전의 기능이나 페이지를 사용자에게 보여주고, 결과를 평가하는 실험입니다. 새로운 기능에 대해 미리 성공 여부를 예측하기 어려운 경우, 사용자 전체에 배포하기 전에 적은 규모의 그룹에게서 미리 반응을 확인할 수 있습니다.

1. 우리 사용자들은 부름 서비스를 알고 있을까요?

1.1. 큰 문제 이해하기

부름 서비스는 내가 지정한 위치로 차를 부르는 서비스입니다.

먼저 쏘카의 부름 서비스란 내가 지정한 위치로 차를 “부르는” 서비스입니다. 사용자는 차를 대여할 위치와, 반납할 위치를 자유롭게 설정할 수 있습니다. (쏘카존에 직접 방문해서 차를 픽업하고 그 자리에 차를 반납하는 ‘쏘카 왕복’과 다릅니다)

어느 날, 부름 서비스의 BO(Business Owner - 사업기획을 담당하는 분들) 분들이 미팅을 요청합니다.

“올해 부름은 예약량을 늘려야 해요. 지난 1년여간 예약량 지표가 정체되어 있었습니다. 전사적으로 볼 때 올해는 예약량 부스팅 반드시 필요하고요. 그나저나 부름 참 좋은데… 말로 표현을 못 하겠네…”

“예약량 지표 정체”라는 문제 상황은 명확합니다. 하지만 아직까지 사용자가 서비스를 잘 쓰지 않는 이유를 명확히 잡아내기 어려운 상태입니다. 문제를 조금 더 뾰족하게 만들어보기로 합니다. PM, BO가 머리를 맞대고 고민을 시작했습니다.

1.2. 현재 상황 파악하기

사용자들은 우리 앱을 보며 어떤 생각을 하고 있을까요?

과연 우리가 생각하는 것처럼 부름 서비스가 좋아서 고개를 끄덕여 주었을까요? 현재 사용자들이 보고 있는 우리는 어떤 모습일까요? 서비스 현황을 확인합니다. 먼저 왕복, 부름 서비스가 각각 무엇인지 확인해 봅니다.

왕복 서비스

왕복 서비스는 정해진 “쏘카존”에 차량들이 주차되어 있고, 사용자가 직접 쏘카존까지 이동하여 예약한 차를 픽업합니다. 쏘카에서 제공 중인 가장 일반적인 차량 대여 서비스입니다.

부름 서비스

부름 서비스는 반대로 사용자가 집 앞으로 차를 부르고, 차량이 지정한 장소로 호출됩니다.

앱의 UX

그런데 현재 부름은 왕복과 Flow, UX를 거의 똑같이 공유하고 있습니다. 왕복이 아닌 부름 상품을 원하는 사용자에게 이것이 최고의 경험일까요? 여기서부터 뒤집어서 생각해 보기로 했습니다.

1.3. 해결할 문제 뾰족하게 짚기

• PM : ”이 문제를 해결하는 우리들은, 쏘카 전체가 아닌, 1인칭 부름 사용자 중심으로 생각하도록 시선을 바꾸어야 해요! 부름 사용자들이 특히 어려워하는 것을 찾아 해결해 주어야 해요.”
• BO : ”왜요? 무슨 차이가 있어서요?”
• PM : 현재 “여기로 쏘카 부르기”라고 적힌 부름 PIN 을 통해서 뿐 아니라, 쏘카존 버튼을 통해서도 동일한 ‘부름’ 차량을 예약할 수 있는데요, 결제 CTA 버튼이 있는 ‘결제정보 확인’ 페이지까지의 도달 전환율이 다음과 같이 차이를 보였습니다. (비율로 표현하면 쏘카존 20% : 부름 PIN 70% 입니다)

• BO : 똑같은 상품을 팔고 있는데도, 출발점에 따라서 결과가 다르다고요?
• PM : 네. 출발점이 부름 PIN인 경우, “여기로 쏘카 부르기”라고 말해주었기 때문에 사용자도 [부름 차량을 빌려야지]라고 명확히 결심한 상황이라고 생각할 수 있을 것 같아요. 부름에 대한 이해, 결제 결심이 반영된 것 아닐까요?
• BO : 흥미롭네요. 그러면 부름 사용자만의 특징을 같이 좀 더 살펴봐요.

1.4. 파고들기

1.4.1. 사용자 Segment 확인

차량 예약 데이터를 확인했을 때, 부름 사용자는 왕복과 나이, 대여 시간에 차이를 보인다는 점을 발견했습니다. (아래 데이터는 일정 기간 동안의 평균치입니다.)

그리고 실제 부름을 애용하는 사용자들에게 전화 인터뷰(In-depth interview)를 진행했습니다.

• 차에 실어야 할 짐이 있거나, 승차할 동행이 많은 경우, 야간에 대여를 시작하는 경우 등 특정한 TPO에 차를 부름으로 불러서 이용한다는 패턴이 있었습니다.
• 사용자들은 위의 상황에서는 명확하게 부름을 쓰러 앱에 들어오며, 쏘카존까지 걸어가지 않아도 되는 부름 서비스의 장점을 느꼈다는 이야기를 자세히 들을 수 있었습니다.

역시 부름은 ‘사용자’가 달랐다는 점을 확인했습니다. 사용자의 목소리를 들어본 뒤, 타깃에 맞춘 제품이 필요하다는 생각을 굳히게 됩니다.

차에 살어야 할 짐이 많은 경우 등 특정 TPO에 부름 서비스를 이용했습니다. by Mick Haupt on Unsplash

1.4.2. 사용성 테스트

사용자들이 보여주고 있던 예약 데이터의 결과와 더불어 제품에서도 사용자들이 허들로 느끼고 있는 명확한 UX를 짚어내기 위해, 앱 사용성 테스트를 진행했습니다. 디자이너, PM, BO 모두 뛰어들어, 사용자들이 어떻게 기존 앱을 사용하는지, 무슨 생각을 하는지 꼼꼼히 수집했습니다.

앱 사용성 테스트 과정

• 부름 서비스를 한 번도 안 써본 사람들과 어느 정도 익숙한 사람들로 그룹을 분리해 진행했습니다.
• 부름을 한 번도 이용해 보지 않은 사용자들에게서는 처음에 둘러보기는 했으나 이해하기 어려워 사용하지 않았다는 피드백을 다수 들었습니다.

더욱이 사용자들이 제품 기획 의도와 다르게 받아들이고 있는 UI 화면들을 발견했습니다. 그동안 부름을 써보지 않은 사용자들이 무엇을 불안해하고 있었는지 구체적으로 근거를 찾아낼 수 있었습니다.

사용자의 목소리는 생각의 전환점이었습니다. 이제 팀원들은 부름 사용자들은 왕복과는 다른 니즈가 있다는 점에 동의했습니다. 그리고 부름 사용자들만이 느꼈던 아쉬운 점, 불편했던 경험을 귀로 생생하게 들으며 깜짝 놀랐습니다. 사용자의 시각은 예상과 다르며, 책상 앞에 가만히 앉아서는 느낄 수 없다는 것을 새삼 깨달을 수 있었습니다.

이런 불편에 공감하고 해결해야, 사용자들이 쏘카 서비스에 매력을 느끼고 계속 이용하게 될 것입니다. 후행적인 사업 지표에 골몰하는 것이 아닌, 먼저 사용자들의 생각 속에 깊이 빠져들어 본다면, 자연스럽게 예약량은 늘어나게 될 거라 기대합니다.

2. 부름을 어떻게 전달하면 사용자들이 알아볼까요?

2.1. 가설 도출하기

2.1.1. 문제 정리

수집한 정보를 바탕으로 팀원들은 문제와 해결 방법을 다음과 같이 정리했습니다.

문제

• 사용자는 앱에서 부름이 정확히 무슨 서비스이고, 무슨 장점이 있어서 예약해야 하는지 알기 힘들다.
• 부름을 한 번도 써보지 않은 상태에서는 차를 내가 지정한 장소로 부를 때 드는 걱정들이 어떻게 해결되는지, 쏘카가 어떤 방지책을 제공하는지 알기 힘들다.
• 한 번도 부름을 써보지 않은 사용자의 고통이 부름 이용 경험자 보다 크게 나타난다.

해결 방법

• 예약량 확대를 위해서는 사용자에게 부름만의 매력을 직관적으로 전달하면서(=PMF 찾기)
• 불안감을 낮출 수 있는 예약 경험을 주어야 한다.

PMF(Product/Market Fit)이란, 타깃을 만족시키는 제품을 가능성 있는 시장에 제공하는 상태입니다.

2.1.2. 가설 설정

다음과 같은 가설을 설정했습니다.

• 가설 : 지금처럼 왕복과 똑같은 Flow가 아닌 [부름 사용자] 관점에서 설계한 부름 전용 예약 Flow를 제공한다면, 결제 전환율의 차이와 기분 좋은 예약 경험 두 가지를 확인할 수 있을 것이다.

차량을 예약할 때 내 바로 앞으로 차를 부르고 싶은 사용자 마음의 흐름에 맞추어 독립적인 부름 서비스 전용 ‘신규 예약 페이지’를 새로 구현해보자는 아이디어입니다.

2.2. 프로덕트 제작, 실험 출시하기

2.2.1. 부름 ‘신규 예약 페이지’ 프로토타입 제작

가설에서 제안한 [부름 사용자] 관점에서 설계한 부름 전용 ‘신규 예약 페이지’를 고민하기 시작합니다. 디자이너와 PM이 사용성 테스트에서 수집한 인사이트들을 바탕으로 와이어 프레임을 새롭게 스케치했습니다. 그리고 가벼운 프로토타입으로 만들어 주변 동료들에게 직접 써보게 하고, 이를 통해 우리가 생각한 UX가 기존 사용자의 문제를 해결하는지 확인하며 스케치를 진행했습니다.

와이어프레임 스케치

UX 변경 전, 기존 사용자 관점의 문제

프로토타입 구상

2.2.2. 실행 방법 고르기

그런데 여기에서 위 도입부에 이야기했던 [올바른 문제해결 방법인지 확신이 필요한] 문제가 대두됩니다. 새로운 예약 Flow를 적용해 보려는 생각을 부름의 사업, 운영팀에 공유했을 때 이런 우려점이 있었습니다.

• 갑자기 예약 과정을 다 바꿔버려도 될까요?
• 기존 사용자들이 적응을 못하고 이탈하면 어떡하죠? 이 UX를 사용자들이 좋아할 거라 어떻게 확신할 수 있어요?
• 사용자 테스트를 대규모로 하면 시간이 너무 많이 들지 않을까요?
• 혹시나 잘못되면 원래 유지되던 예약률은 방어할 수 있을까요?
• 배포했다가 지표가 잘못되면 롤백 할 수 있을까요?

2.2.3. AB TEST 적용

위와 같은 우려를 보완하기 위해, AB TEST를 통해 제품 및 사업 지표가 달성되는지를 확인한 뒤, 전체 배포 여부를 결정하기로 합니다. PM과 데이터 사이언스팀은 아래와 같이 AB TEST 실험을 설정하고, 사업 팀과 목표 및 관찰 지표를 정했습니다.

쏘카에는 데이터 기반으로 실험하기 위한 인프라가 마련되어 있어서 수월하게 실험 계획을 짤 수 있었습니다. 데이터 분석 직군이 아니더라도, PM들이 AB TEST 실험을 프로젝트에 사용할 수 있도록 여러 교육과 가이드가 준비돼 있습니다. ❤️

배포 비율은 먼저 1월 24일 전체 사용자의 5%로 시작한 뒤 2월 4일 실험 결과를 통해 1차 결론을 냅니다.
더 많은 모수에서 같은 결과가 나오는지 확신을 갖기 위해 4월 24일까지 10%, 50%로 단계별로 늘려가며 사업지표와 CS 센터에 악영향이 없는지를 모니터링했습니다.
전체 예약 과정을 바꾸었기 때문에 단편적인 UI 성과 측정만이 목표는 아니었고, 사업과 운영에도 영향이 없는지도 중요한 품질 판단 요소였습니다.

2.2.4. 개발 착수하기

💡 BO가 고민하던 아젠다인 부름의 예약 성장시킬 아이디어 찾기부터, 드디어 “부름 전용 신규 예약 페이지를 개발하고, AB TEST로 출시하여 실험군과 대조군 차이 발견하기” 라는 프로덕트 제작 목표까지 도착했습니다. 이에 맞추어 다음 과정이 진행됩니다.

• 디자이너와 UX Writer의 아이디어가 UX 설계에 뿜어져 나옵니다. 🔥

특히 사용자들이 부름에 대해서 이해가 되지 않았던 부분을 해결하기 위해서, 문장 하나하나에 특히 신경을 많이 써주셨어요.

• iOS, Android, Server 팀, QA 팀은 새로운 프로덕트를 설계하고 개발합니다. 🔥

부름 예약만을 위한 독립 페이지를 만드는 만큼, 기존 예약 페이지를 활용하면서도 새로운 플로우를 많이 설계해야 해서 꼼꼼하게 봐야 하는 작업이었어요.

2.3. 결과를 확인하자

치열했던 개발 기간이 흐르고.. 드디어 실험이 담긴 버전을 출시!!! 🚀🚀🚀 몇 주간 두근두근 하며 사용자들의 반응을 모니터링 했습니다.

2.3.1. 실험 결과

(총 기간 : 2022-01-24~ 2022-04-24)

2.3.2. 후속 사용성 테스트 결과

더불어, 처음에 문제 확인을 위해 진행했던 기존 UX에 대한 사용성 테스트를 새로운 UX를 가지고 다시 진행해 보았습니다. 새로 개발한 부름홈을 보여주면서, 기존과 동일한 질문을, 새로운 사람들에게 던져보았습니다.

부름 사용자의 가장 큰 페인 포인트였던 “서비스를 이해하기 어렵다”라는 문제가 크게 해결되었다는 걸 확인할 수 있었습니다.

3. 부름을 새로운 모습으로 소개합니다.

3.1. 액션 플랜 실행하기

3.1.1. 배포

결제 가능성과 UX 이해도를 높인 파워풀한 새로운 [부름 홈]은 더 많은 사용자에게 배포해도 되는 제품으로 결론을 내렸습니다. 50% 배포 후 사업지표 및 CS 지표에 이슈 없는걸 확인한 뒤 4월 25일을 기준으로 100% 사용자에게 모두 배포할 수 있었습니다.

3.1.2. TPO 재정의

부름의 TPO를 반영하는 새로운 메인화면

부름 서비스는 사용자들에게 왕복과 다른 TPO로 설명될 수 있다는 것을 확인한 프로젝트인 만큼 새로 출시될 메인화면에서 “여기로 부르기”라는 버튼으로 부름을 나타내는 입구를 신설하기로 했습니다. 이제 사용자들이 기존 왕복 예약과 부름 서비스를 분리해서 이해할 수 있게 되었습니다.

2022년 5월 업데이트 한 새로운 쏘카 앱 메인 페이지에서, 새로운 부름 서비스를 더 편리하게 이용해 주세요!

4. 느낀 점

맨 처음 ‘부름 서비스를 성장시키자’는 목표를 들었을 때 들었던 일차원적인 생각은, 여기서 더 어떻게?였습니다. 😂

약 3년 전 쏘카의 신규 사업에 대한 치열한 고민을 통해 탄생했던 부름 서비스는 론칭 후 운영되며 나름대로 좋은 성적을 유지하고 있었습니다.

PM으로서 저 자신이 어떤 태도로 임해야 하는지 고민이 됐습니다. 그리고 생각의 함정에 빠질 뻔한 순간도 있었습니다.

“부름처럼 큰 서비스를? 그동안 담당자도 아니었던 내가 어떤 시사점을 더할 수 있을까? 부름의 A to Z를 다 파악하고 나서야 개선점이 눈에 보인다면 공부하는 데 한참 걸릴 텐데.”

만약 제가 주어진 목표를 쉽게 해결하는 방법에 집중했다면, 단순히 ‘안 보이던 안내 문구를 더 잘 보이게’라던가, ‘상품 가격을 내려볼까’ 같은 무책임하고 지속 불가능한 안을 선택했을 것 같습니다. 하지만 이번 프로젝트에서는 “무엇을 해결할 것인가”를 찾는 부분에서 사용자의 도움을 많이 받았습니다.

• 사용자는 무엇이 마음에 안 들어서 부름을 쓰러 들어왔다가 이탈할까?
• 반면 부름을 계속 써오던 사용자들은, 추가 비용을 지불하며 부름을 왜 쓸까?

두 가지 질문에 대해 사용자들의 입에서 직접 대답을 들었고 또한 사용자의 모습을 관찰하는 과정에서 뜻밖의 단서들을 찾을 수 있었습니다. 운영자 관점에서 단순히 예약이 더 많이 들어왔으면 좋겠다는 생각에 집중했다면 사용자가 무슨 생각을 하는지 파헤쳐 보자는 선택을 하지 않았을 것 같습니다.

저도 프로젝트의 처음부터 끝까지 ‘사용자’를 중심에 놓고 온전히 집중해 본 경험은 흔치 않았습니다. 돌이켜보니 정말 배운 게 많은, 잘 한 선택이었다 생각합니다. 문제는 현재 진행형으로 해결하고 있지만 성장점을 찾아야 하는 PM에게는 이 방향성을 알게 된 것만으로도 큰 수확이었습니다.

더욱이 프로덕트 Funnel 데이터 집계 결과와 AB TEST를 통해 얻은 비교 근거들을 가설 검증 과정에서 사용했던 부분 또한 큰 도움이 되었습니다. 저는 데이터 분석 전문가나 지표를 바탕으로 사업전략을 짜는 직무는 아닙니다. 그러나 쏘카에서 그런 데이터에 접근할 수 있고, 쿼리 하여 읽을 수 있고, 관찰한 바를 토대로 문제를 추정할 수 있게 열린 환경이었기에 가능했습니다. (결론적으로 저는 쏘카라는 회사를 좀 더 좋아하게 됐어요. ㅎㅎ)

제가 준비한 글은 여기까지입니다. 긴 글 읽어주셔서 감사합니다.