● Intro
서비스기획 입문 강의의 마지막에 실습숙제로 등장한 것을 진행해보려 한다. 문제정의~가설수립의 과정을 배울 수 있는 아티클을 선정해 요약해보려 한다. 각종 출처에서 아티클을 찾아보았으나, 강의에서 등장한 자료보다 좋은 퀄리티의 글을 찾기 어려워, '쏘카' PM이 작성한 '부름서비스 성장 과정'을 간략히 요약해보려 한다. 이를 통해, 실제로 내가 관심 있는 프로덕트를 기반으로 가상의 프로젝트도 다음 주제로 이어 작성하려 한다. 바로 아티클을 확인해 보자.
● 프로덕트 개선 과정(일반적)
: 문제확인 → 가설도출 → 가설검증 → 개선안 적용
▷ 아티클 정리 구성
: 서비스 소개 → 문제발견 및 정의 → 가설수립 → 액션 → 검증결과 → 인사이트
1. 서비스 소개
▶ '부름 서비스'란?
: 내가 지정한 위치로 대여할 '차를 부르는' 서비스이다.
- 사용자는 차를 대여할 위치와, 반납할 위치를 자유롭게 설정할 수 있다.
- 쏘카존에 직접 방문해서 차를 픽업하고 그 자리에 차를 반납하는 ‘쏘카 왕복’과 다르다.
2. 문제발견 및 정의
▶ 문제발견
: 문제는 최초 BO(Business Owner) 미팅에서 발제되었다. 지난 1년간 부름의 예약량 지표가 정체되었다는 것이다.
"올해 부름은 예약량을 늘려야 해요. 지난 1년여간 예약량 지표가 정체되어 있었습니다 …" by BO
▶ 문제정의
: 문제정의는 문제를 뾰족하게 만드는 것이다. 이는 계속 질문을 던져가며, 문제를 쪼개가며 진행된다. 내 생각엔 가장 중요하다.
▷ 1st Why?
: 왜 예약량 지표가 정체되어 있을까?
→ 사용자가 부름서비스를 이용해 결제까지 가는 경로를 살펴보자.
→ [쏘카존에서 부르기/ 부름핀 이용에서 원하는 위치로 부르기] 두 경로 상 결제 CTA 버튼이 있는 ‘결제정보 확인’ 페이지까지의 도달 전환율이 차이를 보였다(20%, 70%).
→ 후자의 경우, “여기로 쏘카 부르기”라고 말해주었기 때문에 사용자도 [부름 차량을 빌려야지]라고 명확히 결심한 상황이라고 생각할 수 있다. 부름에 대한 이해, 결제 결심이 반영된 것 아닐까?
→ 그럼 부름을 쓰는 사용자는 일반 사용자와 어떻게 다를까?
▷ 2nd Why?
: 부름을 쓰는 사용자는 일반 사용자와 어떻게 다를까?
→ 차량 예약 데이터 분석결과
: 3-40대가 많고, 예약시간이 2.3배 더 길다.
→ 전화 인터뷰 결과
: 차에 실어야 할 짐이 있거나, 승차할 동행이 많은 경우, 야간에 대여를 시작하는 경우 등 특정한 TPO에 차를 부름으로 불러서 이용한다.
▷ 3rd Why?
: 그럼 이 사람들은 지금 뭐가 불편할까?
→ 사용성 테스트 진행
: 부름 서비스를 한 번도 안 써본 사람들과 어느 정도 익숙한 사람들로 그룹을 분리해 진행.
→ 사용성 테스트 결과
: 사용자 입장에서 핀 UI가 활성되는 기준이 모호하고, 의미하는 바가 명확히 전달되지 않는다.
▶ 그래서 진짜 문제는?
그래서 위 내용을 종합하면, 부름서비스를
- 이용해 본 적 있는 사용자는 특정 TPO에 부름만의 장점을 확고히 인지하여 지속적으로 이용하고 있다.
- 이용해 본 적 없는 사용자는 부름서비스의 특장점을 몰라, 신규진입이 지체되고 있었다.
즉, 알면 좋아서 쓸 텐데, 몰라서 못 쓰고 있다.
3. 가설수립
: 사용자들의 부름서비스를 잘 알게 하면 해결될 것이다!라는 생각으로 다음과 같이 가설을 수립했다.
▶ 가설: 지금처럼 왕복과 똑같은 Flow가 아닌 [부름 사용자] 관점에서 설계한 부름 전용 예약 Flow를 제공한다면, 결제 전환율의 차이와 기분 좋은 예약 경험 두 가지를 확인할 수 있을 것이다.
‘신규 예약 페이지’를 새로 구현해 보자.
4. 액션
- 사용성 테스트에서 수집한 인사이트들을 바탕으로 와이어 프레임을 새롭게 스케치한다.
- 가벼운 프로토타입으로 만들어 주변 동료들에게 직접 써보게 하고, 이를 통해 기존 사용자의 문제를 해결하는지 확인하며 스케치를 진행한다.
5. 검증결과
▶ 검증방법
: 아래와 같은 AB TEST를 통해 제품 및 사업 지표가 달성되는지를 확인한 뒤, 전체 배포 여부를 결정하기로 했다.
▷ 주요 고려사항
- 배포 비율은 먼저 1월 24일 전체 사용자의 5%로 시작한 뒤 4월 24일까지 10%, 50%로 단계별로 늘려가며 사업지표와 CS 센터에 악영향이 없는지를 모니터링.
- 전체 예약 과정을 바꾸었기 때문에 단편적인 UI 성과 측정만이 목표는 아니었고, 사업과 운영에도 영향이 없는지도 중요한 품질 판단 요소.
▶ 검증결과
: '결제확인' 페이지에서 '차량예약'한 예약전환율이 눈에 띄게 증가했다(+21.8% p).
- 부름서비스에 대한 충분한 안내를 받고, 진짜 관심 있는 사용자는 결제까지 진행했다고 해석할 수 있다.
- 최초 목표가 22% p 이상이었던 점을 감안하면, 목표 달성률은 약 99%이다.
- 이에 따라, 4월 25일 100% 사용자에게 모두 배포되었다.
6. 인사이트
▶ Win-Win
- 해당 프로젝트는 문제상황은 비즈니스적 관점에서 파악되었다. 허나 해결방법은 사용자 관점에서 도출됐다.
- 결과적으로, 사용자 - 기업 모두 Win-Win 하는 아주 좋은 케이스였다.
- 생각해 보면, 대부분의 PM이 맞닥뜨리는 대다수의 문제-해결 프로세스는 위 과정을 거친다.
- 아주 당연하게도, 기업은 '수익창출'이 사용자는 '편의도모'가 그들의 궁극적 목적이기 때문이다.
- 위처럼 사용자의 편의도모가 수익창출로 이어지는 경우라면 참 좋겠지만, 이해상충이 발생하는 문제라면 어떨까?라는 의문이 피어났다.
▶ 문제 지표의 해석
- 난 이 프로젝트에서 핵심은 문제를 뾰족이 정의하기 위한 접근법에 있었다고 생각한다.
- 그중 '1st Why?'였던 예약량 지표의 정체를 분석하기 위해, 사용자를 분류한 점이 참 대단하다고 생각한다.
- 보통은 예약량이 정체되었다면, 왜 예약을 안 할까? 하면서 바로 부름서비스 이용자 인터뷰부터 진행할 수도 있다고 생각한다.
- 그러나, 어떤 부름서비스 이용자를 경로별로 파악해, 각 예약률을 살펴보고 그를 통해 사용자들을 매우 세분화했다.
- 거기서 얻었던 인사이트를 바탕으로, 정확한 문제가 무엇인지 정의해 효율적인 해결이 가능했다.
- 프로덕트 전반에 걸친 문제라고 생각되는 문제도, 일단 사용자 세분해서 분석을 진행하는 것이 문제정의에서 매우 중요함을 배웠다.
한 줄 코멘트: 케이스 스터디를 통해 PM의 문제해결 과정을 들여다보았다. 이미 충분히 안다고 생각했던 개념들도, 실제 사례에 정리해 적용해 보니 다르게 와닿았다. PM에게 있어 이러한 사례들은 그 자체가 하나의 교과서가 될 수 있단 생각도 든다. 이 학습을 토대로 나도 내 주변에 관심 있던 프로덕트들을 뜯어봐야겠다.
'[내일배움캠프(PM2기_본캠프)] > 서비스기획 입문' 카테고리의 다른 글
| [캠프 Day 17] 개인과제 - 네이버플러스스토어 개선안(2) (0) | 2025.04.22 |
|---|---|
| [캠프 Day 16] 개인과제 - 네이버플러스스토어 리뷰 분석 (0) | 2025.04.21 |
| [캠프 Day 13] 커리어데이 - 주의깊게 본 내용들 (0) | 2025.04.16 |
| [캠프 Day 12] 서비스 기획 입문 Chapter 1.4~2.2(完) (0) | 2025.04.15 |
| [캠프 Day 11] 서비스기획 입문 Chapter 1~1.3 (0) | 2025.04.14 |