사이드 프로젝트에서 PM으로
살아남기
기획부터 런칭까지의 여정
졸업 후, 입사를 기다리는 동안, 대학생 때 들어간 IT 연합 동아리 'Nexters'에서 2번째 UX/UI 사이드 프로젝트'를 하게 되었다. 이전에는 디자이너로만 활동했었는데 이번 활동은 PM을 목표로 활동을 지원하게 되었고, 두 가지 역할을 병행하게 되었다. 해당 글은 첫 Product Manager으로 사이드 프로젝트에 참여했던 경험을 작성했다.
1. 발견하기
넥스터즈에서는 한 프로덕트를 8주의 짧은 기간 동안 '기획-디자인-개발'을 모두 해야 한다. 하지만 짧은 시간에 쫓겨 쉽게 찾을 수 있는 서비스를 만들기는 싫었고, 재치 있는 콘셉트를 가진 알맹이 있는 서비스를 만들고 싶었다.
아이디어 고민 중에, 친구들과 여행에 대한 썰을 풀면서 여행을 준비할 때부터 지인과 성향이 달라 삐그덕하는 상황을 듣게 되었고, 그에 대한 구체적인 이유에 대해서 정리해 보았다.
여행을 준비하는 (MBTI) J/P별 밈이 한창 등장했었다
이러한 문제점들을 개선하고, MBTI에서 계획을 필수로 하는 J와 즉흥적으로 즐기는 P가 함께 여행을 준비할 수 있는 서비스를 제안했다.
2. 아이디어 어필하기
세션 첫날, 아이디어가 선정된 PM들이 발표를 진행했고, 발표 후에는 동아리 부원들이 궁금한 점을 물어보는 시간을 가졌다. 생각보다 많은 분들이 나의 아이디어에 대해 공감을 해주셨고, 타깃도 흥미로워하셨다. 중간중간에 날카로운 질문 또한 있었는데,
여행 계획조차 세우는 것을 귀찮아하는 P도 있을 텐데, 이 부분은 어떻게 해결하실 건가요?
이에 대한 답변은 그룹 여행의 경우, P가 추구하는 무계획으로는 떠날 수가 없으며 J 또한 계획을 강요할 수 없는 상황임을 설명했다. 이 과정에서 다른 성향을 가진 멤버들은 각자만의 스트레스를 받기 때문에 이에 대한 절충안이 필요하며, 여행을 준비하는 과정에서 피로감을 덜어주는 콘셉트와 기능을 가지게 될 것임을 전달했다.
메인 기능은 아래와 같다.
1. 취향 태그(좋아요/싫어요)
해당 기능을 활용하여 멤버들에게 본인의 취향을 빠르게 표현할 수 있도록 했다. 이를 통해 P는 본인의 의사를 빠르게 전달할 수 있고, J는 해당 내용을 참고하여 계획을 세울 수 있다. ('상관없어', '모두 찬성' 태그와 같은 중의적인 태그를 통해 모든 의견을 수용하겠다는 표현 또한 할 수 있다)
2. 후보 방문 장소 공유 및 투표하기
J가 가고 싶은 여행 장소를 동행자들에게 공유 시, 투표 기능으로 투표율이 높은 여행 장소를 빠르게 확인해 볼 수 있고, 투표율이 높은 장소를 중심으로 빠르게 플랜을 세울 수 있는 구조를 만들었다.
당시에는 위 내용의 구체적인 기능을 설명하진 못했으나 방향성을 러프하게 전달했다. 날카로운 질문 덕분에 콘셉트를 명확하게 세우는 기회가 되었다.
3. 두근두근, 팀 빌딩
감사하게도 여러 팀들 중, 가장 많은 분들이 지원해 주셔서,
계획대로 나를 포함한 Design/ iOS/Androird/Server 별로 2인씩 계획대로 팀빌딩할 수 있었다.
그리고 신기하게도 팀원들의 비율이 J(50%), P(50%)로 나뉘었다.
팀원을 선정할 때, '열정'을 가장 중요하게 생각했다. 이전 사이드 프로젝트에서 한 두 명씩 이탈이 되고, 결국 사이드 프로젝트가 무마되었던 아픔... 이 있었기 때문이다. 기간 내에 론칭을 못하더라도 끝까지 작업할 의지가 있는 사람들끼리 한 배를 탔으면 했다.
4. 팀 Ground Rule, 타임라인 세우기
팀원들과 정기 회의 날짜를 정하였고, 디자인, 개발 일정을 주단위로 정리했다.
그리고 일반 소통 채널 / 업무 소통채널을 분리해서 디스코드와 노션을 활용하기로 했다.
각 파트 별 앞으로의 To-do List 작성 후, 우리 팀은 동아리 활동 외, 4주를 추가해서 총 12주 동안 진행하는 것으로 결정을 지었다(목표와 달리 10개월 동안 진행하게 되었지만...). 그리고 정의한 정책들과 파트별 회의록은 노션에서 관리될 수 있도록 했다.
5. 모두가 같은 서비스 이해도 가지기
첫 회의는 모두가 오프라인으로 참여할 수 있는 날짜와 장소를 정해서 만났다. 구체적인 기능과 구현 범위를 고려해서 최종 서비스 MVP를 선정했다. 이후 디자이너 팀원과 함께 IA와 User flow를 작업한 후, 개발 팀원들이 서비스에 대한 흐름과 구조를 빠르게 파악할 수 있도록 도왔다.
6. QA 및 배포하기
개발이 80% 진행된 후, QA를 진행했다. 발생한 디자인/기능 구현 오류의 우선순위와 어떤 사유인지 구분하여 개발 팀원들이 빠르게 인지할 수 있도록 도왔다.
이후 앱스토어 소개글, 키워드(Chat GPT를 활용), 개인정보 처리 방침 등 여러 항목들을 작성한 후, 심사를 신청했다. 안드로이드에 비해 iOS가 확실히 더 체크해야 하는 항목들이 더 많다는 걸 알 수 있었다.(심사 중, 로그인에서 버그가 발생되었지만 심사원들도 정확한 이유를 찾기 어렵다는 답변만 와서, 개발 팀원들이 많은 고생 했다ㅠ)
7. 회고하기
스토어에 론칭한 후, 팀원들과 오프라인 회고 회의를 진행했다. 회고 방식은 KPT 프레임 워크 형식으로 진행했다.
KPT : Keep (유지), Problem (문제), Try (시도)
개인&팀의 관점에서 생각하는 내용들을 자유롭게 작성하고, 구두로 좀 더 자세히 이야기했다. 이를 통해 향후 사이드 프로젝트에서 개인&팀이 가져가야 하는 목표를 세울 수 있었다.
모든 팀원들이 꼽았던 좋은 점은 끝까지 포기하지 않고 마무리한 점이었다. 예상보다 장기적으로 진행되었기 때문에 현생(회사/이직 등등)과 함께 병행해야 하는 '마음속 숙제'처럼 남아있었다. 하지만 개발 팀원들이 기획/디자인 덕분에 마무리를 꼭 짓고 싶었었다고 했다. PM으로써 팀원들에게 정말 감사했던 순간이었다. 팀원들이 진행한 작업들에 대한 존중 그리고 책임감이 있었기에 런칭에 대한 목표가 오랫동안 지켜질 수 있었다고 생각한다.
나또한 개인적으로 해당 프로젝트를 매니징 하면서 좋았던 점과 아쉬웠던 점을 정리했다.
[Keep]
1. 근본적인 질문은 콘셉트를 강화시킨다 - 모두가 공감할 수 있는 내용이 필요
2. 장기로 프로젝트가 진행될 때, 팀원들이 포기하지 않도록 끊임없이 동기부여를 주는 것이 중요하다 - 1주에 한번 온라인/오프라인 모각작 진행, 벌금 제도, 작업 내용 적극적 공유 등을 통해 팀원들에게 끊임없이 동기부여를 줄 수 있는 방법에 대해 고민했었다.
[Problem/Try]
1. 프로덕트 기획 전, 개발 Scope에 대한 점검이 필요하다
2. Manager로써 의사결정이 필요한 순간 결단력이 필요하다
(모두의 의견을 물어보면서 진행하는 경우, 진행이 무뎌질 수 있다)
3. 비즈니스에 대한 고려가 필요하다(운영에 필요한 비용 및 수익 창출)
8. 마무리
첫 PM 경험이었기 때문에 정말 부족함이 많았지만, 팀원들로부터 많은 것들을 배울 수 있었다. 사이드 프로젝트는 환경 상, 매스감이 큰 프로덕트를 만들 수는 없지만, 소수의 팀원들과 서로 임팩트를 줄 수 있는 기회는 많기 때문에 내실 단단하게 채울 수 있는 좋은 기회가 된다고 생각된다. 하지만 프로덕트 퀄리티와 사용자에게 주는 임팩트에서는 항상 아쉬움이 남는다. 이후 사이드 프로젝트에서는 이러한 부분을 보완하고 싶다.
[서비스 사이트]
