지난 과제에서는 '다양한 아티스트를 스트리밍 하도록 유도한 플레이리스트 단위 설계가, 취향을 찾아 스스로의 플레이리스트를 구축하고자 하는 고객에게 걸림돌이 된다'라는 플로의 문제를 해결하기 위한 솔루션을 정의하고, 해당 솔루션을 구체적인 MVP로 기획해 보았습니다.
지금까지의 내용을 정리해보면 아래와 같습니다.
* 출처 : 한국콘텐츠진흥원 2021 음악산업백서
(시장)고객이 스트리밍 서비스를 선택하는 이유는 무엇인가?
- 합리적인 가격*
(시장)고객이 스트리밍 서비스를 사용하는 이유는 무엇인가?
- 사용자 주도 하에 원하는 음악을 선택해서 스트리밍 하기 위함*
플로의 목표는 무엇인가?
- 시스템 플레이리스트 기반 청취를 유도해 유저와 다양한 아티스트를 만날 수 있도록 하고, (1인당 스트리밍 아티스트 수 증대가 목표)
- 다양한 아티스트를 스트리밍하며 정교화된 유저의 취향을 바탕으로
- 새로운 노래를 끊임없이 추천해 주는 것
고객이 필요로 하지만 플로가 제공하지 못하는 요소는 무엇인가?
- 스트리밍, 플레이리스트 커스텀 등 스트리밍 과정에서의 사용자 주도권 불충분
왜 그것을 제공하지 못하는가?
- 플로의 핵심가치가 다양한 아티스트를 스트리밍 하도록 유도하는 것이며, 이것이 플레이리스트 단위 스트리밍으로 설계되어 있기 때문
플로에서 고객이 이탈하는 이유는 무엇인가?
- SKT할인 요금제가 끝나기 전까지 플레이리스트 기반 설계를 이해하지 못함
- 멜론, 지니 등 사용자의 커스텀에 특화된 서비스에 익숙한 플로 신규 사용자들의 경우 플레이리스트 기반 청취를 이해하기 어려움
- 취향을 찾아 주도적으로 스트리밍하고자 하는 욕구가 생겼을 때, 플레이리스트 기반 설계가 이를 해결해주지 못함
- 정해진 플레이리스트에 새로운 곡을 추가하거나, 기존 플레이리스트를 믹스하는 등 유저의 마음대로 커스텀할 수 없음
왜 이탈을 막아야 하는가?
- 음악 스트리밍 사용 이유 중 비용(30.0%)다음으로 계속 써오던 것이어서 익숙하기 때문에(24.8%)라는 응답이 2위를 기록함*
- 이전 음악 스트리밍 서비스 비이용 이유로 이용 요금이 비싸서(31.6%)가 1위, 이벤트 참여/단기 혜택을 위해 이용했던 것이라서(11.7%)가 3위를 기록함*
- 실제 플로를 비롯한 다른 스트리밍 서비스 이용 경험이 있는 유저 대상으로 플로 유입 이유와 이탈 이유에 대해 조사한 결과 유입 이유로는 'SKT 할인 요금제', 이탈 이유로는 '불편해서, 요금제 할인이 끝나서'를 꼽았음.
- 인터뷰와 앱스토어/플레이스토어의 리뷰에서 불편했다는 요소를 자세히 살펴보면, '곡 위치를 마음대로 바꿀 수 없는 것이 불편하다, 플레이리스트를 커스텀(병합, 곡 추가)하기 어려워서 불편하다' 등의 이유가 있었음.
위의 결과에서 추론해 볼 수 있는 것은 아래와 같음
1. 고객은 할인(요금제 할인, 이벤트 등)으로 유입된다.
2. 유입된 고객이 시스템에 익숙해진다면 다른 서비스로 이탈하지 않을 가능성이 높다.
3. 유입된 고객이 시스템에 적응하는 데 불편함을 느끼는 요소는 '사용자 주도 하에 스트리밍을 할 수 없다'는 것이다.
3. 플로의 SKT 할인 요금제로 유입된 고객이 할인 기간이 끝나기 전까지 서비스에 적응할 수 있도록 하는 솔루션이 필요하다.
고객 이탈을 막기 위한 솔루션은 무엇인가?
1. 플레이리스트 단위 설계는 플로의 존재 이유이기 때문에 이를 수정할 수는 없고, 사용자가 플레이리스트를 커스텀할 수 있는 옵션을 제공
>> 곡을 재생목록에 추가 시, 플레이리스트를 지정해 추가할 수 있는 옵션을 준다.
2. 할인 기간동안 고객이 플로의 시스템에 적응해 이탈하지 않을 수 있도록 안내 기능을 제공
>> 스트리밍 시 곡 추가 순서 등을 커스텀할 수 있는 재생설정 기능이 있다는 것을 알린다. 이 경우 고객에게서 '기능 안내가 없어 불편하다'는 요구를 확인한 것이 아니라, '재생설정과 같은 커스텀 기능이 있다는 것을 고객에게 알려준다면 고객의 이탈률이 줄어들 것이라는 가설'에 기반한 것이기 때문에 향후 AB테스트와 같은 실험을 통해 검증한다.
오늘은 위의 과정을 통해 도출한 솔루션을 MVP로 개발할 수 있도록, 기획 문서를 작성해 보고자 합니다.
1. 유저스토리(백로그 작성)
먼저, 유저의 불편사항을 개발자, 디자이너분들이 구체적인 기능으로 구현할 수 있도록 백로그를 쌓기 위해 유저스토리를 작성해 보았습니다. 유저스토리란, 애자일 기반의 조직에서 고객의 요구를 기능으로 구현하기 위해 백로그를 쌓는 방법이라고 볼 수 있습니다. 유저스토리는 아래와 같은 형식을 갖습니다.
- As a [type of user]
- I want to [action]
- so that [benefit]
즉, [사용자]는 [목적]을 위해 [활동/작업]하기를 원합니다.
위의 형식에 맞추어 고객의 요구를 정의해 보겠습니다.
- 스스로의 취향을 기반으로 새로운 곡을 탐색하고자 하는 플로 사용자는
- 새로운 곡을 탐색한 후 취향에 맞는 곡을 적절한 플레이리스트에 추가하기를 원한다
- 다른 사람들의 플레이리스트를 스스로의 플레이리스트로 커스텀하기 위해서
2. 기능 정의서
다음으로, 위의 유저스토리를 구체적인 기능으로 개발하기 위해 개발자, 디자이너분들께 기능을 설명할 문서를 작성했습니다. 애자일 기반 조직에서는 유저스토리를 기반으로 개발자, 디자이너분들과 소통해 기능을 만들어나간다면 워터폴조직에서는 PM혹은 서비스기획자가 기능을 정의해 개발자, 디자이너분들께 전달하게 됩니다. 때문에 위의 유저스토리(애자일 기반)와는 다른 목적을 가진 문서이지만, 합류하게 될 회사가 어떤 문서로 커뮤니케이션하는지, 어떤 문화를 가지고 있는지 모르기 때문에 모두 연습해본다는 의미로 작성해 보았습니다.
작성하며 가장 크게 느꼈던 점은, 규모가 작고 실행 주기가 빠른 조직일수록 기능 정의서를 작성하는 것보다 유저스토리 단계에서부터 함께 소통하는 것이 더욱 효율적일 것이고, 큰 프로젝트를 오랜 주기로 진행하는 워터폴 조직일수록 이전 단계로 돌이키기 어렵기에 세세한 기능 명세가 중요할 것 같다는 점이었습니다. 물론 아무리 세세해도 개발자, 디자이너 분들이 보시기에 터무니없는 내용은 있기 마련이니 일을 여러 번 하지 않으려면 사전 소통이 중요할 것 같습니다.
3. 정보(계층)구조도 (IA, Information Architecture) 설계
다음으로는 정보 계층 구조도입니다. 이 또한 워터폴 기반의 조직에서 유효한 문서일 것 같은데요, 사실상 개발자, 디자이너 분들과 함께 과제를 디벨롭할 수 있는 환경이 아니다보니, MVP를 위한 기획 산출물을 (어찌됐든) 보여주려면 필요한 과정이 아니었을까 생각해 보았습니다. 해당 문서에는 Depth별로 페이지의 위계를 정리해둔 후, 해당 페이지의 구성 요소와 페이지에 대한 간략한 설명이 추가되어 있습니다.
4. 화면 디자인 (Wireframe)
다음으로는 MVP를 구현하기 위한 화면디자인입니다. 직접 디자인을 입히지 않은 mid-fi입니다. 완벽한 결과물을 만든다기 보다는 '이런 플로우로 기능이 구현되었으면 좋겠다'를 이해하기 쉽게 시각적으로 보여준다는 의미에서 작성해 보았습니다.
5. 스토리보드 (기능명세서) 작성
마지막, 최종 산출물인 스토리보드입니다. 스토리보드는 위의 와이어프레임의 각 화면에 해당하는 상세 요구사항을 함께 기록한 문서입니다. 화면을 구성하는 컴포넌트에 특이사항이 있을 시 숫자를 달아 표기했고, 위의 IA(정보구조도)에서 정의했던 페이지 넘버를 활용해 이동해야하는 페이지를 나타냈습니다.
'Product Manager > 위클리 과제' 카테고리의 다른 글
| W8. 쓱닷컴 스크럼 팀의 스프린트 플래닝은 어떨까? (0) | 2022.10.21 |
|---|---|
| 플로의 MVP 변천사와 스케일업 (0) | 2022.10.14 |
| W5. 기획한 MVP가 플로의 성장에 도움이 될까?(feat. Growth, AARRR) (0) | 2022.09.28 |
| W3. 솔루션 정의와 MVP 기획 (0) | 2022.09.13 |
| W2. 플로, 취향을 발견하면 떠나는 고객을 잡아라! (0) | 2022.09.04 |
