산타 마니또, 냅다 고객의 문제를 해결한 MVP
마니또 및 미션 매칭 MVP 서비스, '산타마니또' 기획 의도
데스크탑 환경에서 가장 편안하게 보실 수 있으며,
저의 브런치에 먼저 업로드된 이 글은 추후 재구성을 통해
프로덕트 데이터 분석 커뮤니티 PAP 블로그, 디스콰이엇, 커리어리에 업로드될 수 있습니다.
이 글을 읽기 전, iOS 앱 링크 혹은 Android 앱 링크에서 먼저 다운 받아 보시면 좋습니다. 이 프로덕트는 동아리 사이드프로젝트로 시작한 MVP 단계의 서비스임을 미리 알려드립니다.
들어가며
약 6개월 전, PM Book 메이커 박재은님께서 내가 만든 앱을 분석한 노션 글을 공유해주셨던 적 있습니다.
당시 재은님께서는 천부 PM답게 산타마니또 팀의 기획 포인트를 정확하게 짚어주셨습니다.
구독하고 있는 작가분이자 같이 스터디도 했던 분이 앱스토어에서 우리 서비스를 우연히 찾아 분석 글로 남겨주신 게 신기해서 슬랙과 운영하던 블로그를 통해 피드백글도 남겼습니다. 오늘은 그 피드백과 기존에 공부했던 내용을 추가하여 프로젝트 회고 및 레슨런을 정리하고자 합니다.
'고객의 문제'는 무엇일까
산타마니또는 2020년 말, 'SOPT'라는 IT 창업 동아리 운영팀 및 동아리 내 지인들과 함께 진행한 사이드 프로젝트입니다.
당시 저는 SOPT의 행사 운영을 주도하는 운영팀원이었습니다.
열댓명의 운영팀에서는 매주 마니또를 뽑아 서로 친목을 다져왔습니다.
매번 종이를 찢어 마니또 투표지를 만들고, 미션 투표지를 만들고,
(중복이면) 다시 섞어서 다시 뽑아야 하는 과정이 너무 불필요한 A4 낭비로 느껴졌습니다.
특히 인원수가 많았기 때문에 중복 매칭으로 재투표를 하는 일이 많았기 때문입니다.
그래서 실제 지인끼리 함께 있는 상황에서 마니또 게임을 할 수 있도록,
SOPT 앱잼에서 TI(전 서브PM/현 PM)들이 팀 매니징을 위해 설계한
마니또 게임에서 마니또 및 미션매칭을 고민하는 일을 줄여주는 서비스를 만들고자 했습니다.
핵심 고객과 문제를 정리하면 다음과 같습니다.
핵심 고객 :
1. (넓게 보면) 실제 지인이 함께 한 모임에서 마니또 게임을 여러 Round로 진행할 경우
2. (좁게 보면) 동아리, 학교, 스터디, 회사 등의 모임에서 마니또 게임을 여러 Round로 진행하며
아이스 브레이킹을 하는 상황
3. (정말 좁혀 본 당시의 핵심 고객군) SOPT 앱잼에서 TI(전 서브PM/현 PM)들이 팀 매니징 하는 상황에서 마니또 및 미션 매칭을 고민하는 상황
문제 :
1. 종이 투표를 통한 마니또 매칭은 중복매칭될 우려가 있다
2. 마니또 게임을 위한 미션 매칭을 고민한다
여담
여담이지만 서비스 기획을 하며 레퍼런스를 조사해보니
SOPT 졸업생들이 많이 진출하는 NEXTERS나 YAPP 등의 IT 서비스 동아리에서도 마니또 관련 서비스
프로토타입핑을 하거나, 실제 런칭한 경우가 많았습니다.
그러나 우리가 조사한 타이밍에 아쉽게도 다 샷다를 내린 상태였는데,
(샷다를 내린 이유는 진행하며 자연스레 알게되었습니다)
다른 IT 동아리엔 마니또 서비스가 있는데 SOPT에만 마니또 서비스가 없다?
이건 못 참지
.... 사실 이 생각이 제일 강한 트리거가 됐습니다...
MVP 프로젝트를 시작하게 된 이유
당시 저는 '앱잼' 이라는 동아리 해커톤에서 정식 PM으로 데뷔하기 위한 <PM 경선>을 준비하고 있었습니다.
SOPT 동아리 내 PM 지원자들은 'PM 경선'의 아이디어 경쟁 PT를 통해
득표순으로 일부 PM만이 선발되어, 앱잼 팀빌딩을 진행할 수 있었습니다.
팀을 이끌어보고, 하나의 서비스를 기획해보는 경험을 쌓는 것이 PM 준비생으로서는 매우 중요했기에
약 1달 반 안에 토이 사이드 프로젝트를 진행하며, 정식 앱잼 이전에 빠르게 기획부터 개발까지 마무리해야 했습니다. 그래서 부가 기능이 생략된 '정말 최소한의 MVP 기능'만을 설계하고자 했습니다.
그럼 리뷰해주신 고객 여정을 토대로 기획의도를 살펴보실까요?
1. 회원가입
출처 : 재은님 노션재은님의 분석 :
산타 마니또는 회원가입 단계에서 이메일 주소와 비밀번호 설정 없이 이름 정보만 받고 있다. 이는 두 가지 측면에서 설명할 수 있다. 크리스마스에 마니또를 공개하기 때문에 일회성 이벤트에 가깝다. 회원 DB를 별도로 유지하기엔 배보다 배꼽이 큰 격이다. 다른 하나는 마니또는 여럿이 모여야 할 수 있는 놀이이므로 쉽게 초대할 수 있게 해야 한다. 산타 마니또는 앱 기반이라 앱스토어에서 설치해야 하는 단점이 있다. 여기에 회원가입 단계가 무거우면 진입장벽이 높아진다. 다만, 사용 빈도는 적으면서 추천이 중요한 서비스라면 앱보다는 웹으로 서비스를 제공하는 것이 좋지 않을까 생각한다.
기획 의도
1. 회원가입의 Depth를 최소한으로 하며 진입장벽을 낮춘 의도는 (1) 마니또 게임 자체가 '일회성 이벤트'
에 가깝고, (2) 쉽게 참여자를 초대할 수 있어야 referral이 원활히 일어날 수 있기 때문이 맞습니다.
특히 주요 사용자가 10대 유저가 많을 것으로 예상하여 'Easy'를 서비스 Core Value로 선정했습니다.
그래서 별도의 회원가입을 두지도, 유저 행동 정보를 수집하지도, 별도의 서비스 탈퇴도 만들지 않았습니다.
물론 이후 서비스가 생각지도 않게 10대 사이에서 나름(?) 흥해버려서 유저 행동 정보를 수집하지 않은 것은 다소 아쉽게 느껴졌습니다.
2. 웹으로 만들지 않은 이유는.. 팀 구성원 인적자원 문제와 관련이 있습니다.
팀 내 개발자들이 Android, iOS 개발자 이기 때문입니다...
그리고 서비스 기획 당시 지인들끼리 같이 있는 상황(솝트 운영팀, 솝트 앱잼)을 가정하여 기획했기에
데스크탑 PC보다 앱으로 쓰는 상황이 많을 것이라 생각했기 때문입니다.
하지만 웹 유저가 더 많다는 가설을 증명할 수 있다면, 추후 웹서비스화할 생각은 있습니다.
2. 방 만들기
산타 마니또는 방이 생성되고 친구를 초대한 다음 매칭된 미션을 진행하는 방식으로 진행된다. 먼저 방 만들기를 누르면 방 이름과 종료일을 설정하는 화면이 나온다. 크리스마스에 마니또를 공개하는 컨셉인 만큼 기본 설정은 12월 25일로 지정되어 있다. 미션 만들기 단계에선 랜덤으로 매칭할 미션 목록을 입력할 수 있다.
기획 의도
서비스 진입 후 (1) 방장이라면 '방 만들기', (2) 방장이 초대한 친구라면 '방 입장하기'의 두가지 액션을 취할 수 있습니다.
방장이라면, 방 만들기 기능을 통해 방이름, 마니또 종료일(공개일), 종료 시간(공개시간)을 정한 후
미션을 추가, 삭제하면서 미션을 설정 하거나, SKIP(미션 없이 마니또만 매칭)할 수 있습니다.
기획 당시 크리스마스, 앱잼을 앞두고 있었고 마니또가 영어로 'Secret Santa'이기 때문에
디자이너 영진님께서 디자인, 컬러, 플레이스홀더 등에 크리스마스컨셉을 앱 곳곳에 녹여주셨습니다.
이 단계에서 미션을 입력하는 것이 어려웠는데, 친구들이 좋아할 만한 미션이 잘 생각나지 않았기 때문이다. 아마 여기서 마니또를 하지 못하고 이탈하는 사용자가 많을 것 같다. 앱스토어 스크린샷에 나온 예시처럼 어떤 미션을 할 수 있을지 목록으로 보여주면 작성하기 쉽지 않나 싶다.
기획 의도
이 단계에서 재은님이 말씀해주신 것 처럼, '미션 추천'기능을 염두에 두고 있었습니다.
사실 이 기능은 넣으려다가 도저히 시간적 여유가 없어서 제외한 부분이기도 합니다.
주사용자가 Z세대(10대)이기 때문에 이들을 위한 재미있는 미션추천 기능은 추후 버전 2에서 업데이트할 예정입니다.
방 만들기를 누르면 참여코드가 생성되며, 친구에게 쉽게 전달할 수 있도록 참여코드 복사 기능을 제공하고 있다. 생성된 방은 나의 산타 마니또에서 확인이 가능하며, 모임 상세 화면에서 몇 명이 방에 입장했는지 확인할 수 있게 했다.
기획 의도
방장 사이드에서 정보를 다 기입하면 참여코드가 생성되고,
참여코드 복사를 통해 친구들에게 보낼 수 있습니다.
이는 쉬운 Referral을 위한 의도 입니다.
3. 방 입장하기
방 생성하기와 달리 방 입장하기의 플로우는 매끄럽지 못한 인상을 받았다. 그 이유는 방을 생성한 후 어떤 액션을 취해야 하는지 명확하지 않기 때문이다. 산타 마니또는 초대코드만 복사가 가능한데, 친구에게 초대코드를 전달할 때 서비스에 대한 설명과 앱 스토어 다운로드, 입장하는 방법을 방을 생성한 사용자가 직접 안내해야 하기 때문이다. referral이 중요한 서비스인 만큼 앱 스토어로 이동하는 딥링크를 제공하는 것이 더 많은 사용자에게 공유되기 쉬울 것 같다.
기획 의도
이 부분은 말씀주신 부분처럼 최대한 빨리 배포하기 위해 모든 디테일을 생략했었던 (!) 이유입니다.
또한 마니또 게임을 하는 맥락 때문이기도 한데요.
최초 메인 타겟은 '앱잼을 하는 SOPT 동아리원'으로
지인끼리 함께 오프라인에서 대면하는 상황에서 이 앱을 사용할 것이라 생각했기 때문에 Referral 시 설명하는 부분을 생략했었습니다.
하지만 서비스 이용자가 많아진 만큼, 추후 업데이트에서는 딥링크를 제공하는 형식으로 바꾸려 노력해보겠습니다.
4. 랜덤 매칭하기
참여자가 모두 모이면 랜덤 매칭하기 버튼이 활성화된다. 랜덤 매칭하기를 누르면 매칭된 마니또와 미션이 공개된다. 산타 마니또는 마니또 종료일 전까지 별다른 액션을 제공하지 않고 있는데, 이왕이면 마니또를 하는 기간에도 자주 방문할 수 있는 요소를 넣으면 좋지 않을까 한다.
내가 이 서비스의 PM이라면 미션 완료를 체크할 수 있는 기능을 추가해 친구들의 미션 달성 여부를 확인할 수 있게 만들 것 같다. 친구의 미션 완료 표시를 보고 마니또를 추측하는 재미가 생기지 않을까 한다.
기획 의도
마니또 게임 중간의 리텐션을 위한 기능도 초기 기획단에 있었으나, 빠른 배포를 위해 미뤄졌습니다.
아무래도 필수적인 기능 중심의 MVP를 위해서는 기능 하나를 만들기 위해 드는 시간적, 기술적 리소스를 고려해야 했기 때문에 마니또 및 미션 매칭 여정에서 아주 필수적인 요소가 아니라고 판단이 들면 과감히 다음 버전2로 계획을 미루었습니다.
스포를 하자면 방장이 미션을 체크하는 기능st의 재미있는 기능을 추가할 예정입니다.
총평
마니또라는 진부할 수 있는 소재를 특별한 날(크리스마스)과 엮어서 흥미로운 서비스로 탄생한 산타 마니또. 사이드 프로젝트로 만든 앱으로 보이는데, 그래서인지 중간 중간 아쉬운 점이 보였지만 스펙을 줄이는 과정에서 핵심 기능에 집중하지 않았나 싶다. 최근 들어 눈에 띄는 앱서비스가 가뭄에 콩 나듯 하는 와중에 재밌는 서비스를 만들어주어 감사하다.
PM의 답변
재미있는 서비스를 만드는 것만큼 가슴 뛰는 일이 또 없습니다. 사용자로부터 '재밌어요~!'라는 피드백을 받을 수 있어서, 또 정말 유능한 분이 피드백해주셔서 저 역시 너무 감사했고, 진짜로 미뤄 둔 버전 2 업데이트를 ... 팀원들과 원만한 합의를 거쳐 진행해보겠습니다....
프로젝트 레슨런
1. 서비스 기획 초장부터 비즈니스 모델을 설계해야 한다.
운 좋게도 특별한 마케팅 없이 SNS 카테고리 중상위권에 랭킹되었던 적 있습니다. 토이 프로젝트로 진행했기에 비즈니스 모델에 대한 고려 없이, MVP만 달랑 출시했을 뿐이었는데 생각보다 Z세대 사이에서 많이 흥해서 서버비 과금이 .. 있었습니다.
포트폴리오를 쌓기 위한 사이드 프로젝트이더라도, 서버비 + 사기진작을 위한 투자비용을 위한 일종의 비즈니스 모델이 필요했었습니다. 물론 초기에 이 부분을 생각하지 않았던 것은 아니었고, 당시 기획파트장 한솔님으로부터 비즈니스 모델에 대한 조언을 얻을 수 있었습니다. 하지만 저희는 앱잼 빌드업을 하는 사이드 프로젝트 팀원이었고, 일회성 이벤트인 마니또에 어떻게 거부감없이 비즈니스모델을 넣을 것인가를 고민하기에는 시간적 여유, 개발 리소스가 부족했습니다.
2. 유저행동 데이터 수집은 매우 중요하다.
전혀 흥할 것이라 생각하지 않은 아이템이었기 때문에 별도의 회원가입도, 탈퇴도 없었습니다.
무조건 Z세대 사용자를 위해 '쉬운 게 좋은 것'이라 생각했습니다.
물론 진입장벽이 낮은 것이 더 많은 유입을 가져왔다고는 생각하지만, 프로덕트 개선을 위해서는
행동 데이터 수집을 선행했어야 했다는 점이 아쉬웠습니다.
추가적인 업데이트에서는 이런 세세한 유저 관리에 중점을 둘 계획입니다.
3. 사이드 프로젝트 팀 매니징에 대한 공부가 더 필요하다.
이 프로젝트를 진행한 지도 벌써 2년 정도가 흘렀습니다.
동아리 고인물, 썩은물 모임에서 만들었지만, 이제는 더 이상 '동아리'라는 공통분모가 없는, 취준생 혹은 회사원이 대다수인 팀이기 때문에 정기 미팅을 잡는 것도, 프로젝트를 위한 시간을 내는 것도 매우 어렵습니다.
각자 다른 곳을 바라보는 팀원을 (강제로라도) 같은 곳을 바라보고 같은 생각을 하게 만드는 것 또한 PM의 역할이라는 것을 몇번의 실패를 통해 느꼈었습니다.
각자의 현생을 사느라 바빠져 버린 팀원들을 어떻게 구슬려 다시 프로젝트를 시작할 지 프로젝트 빌드업을 위한 팀 매니징 고민을 해보아야 겠습니다.
