주니어 PM이라면 반드시 챙겨야하는 6가지
건강하게 피드백을 받아들이는 법
사이드프로젝트 왜 해요??
에이전시에서 UX디자이너로 일한지 1년6개월째.
'너 어떤 일 해?' 라는 질문에 나는 000 서비스 만들고 있어! 라고 한 마디로 설명하고 싶었다. 에이전시에서 1년 6개월째 일하고 있지만 지금까지 내가 만든 서비스가 아직 세상에 빛을 본 적이 없다.
대기업의 일을 받아서 서비스를 만들다 보면 핵심 기능을 가진 MVP가 아닌 완성형 MVP를 원했고, 이상적인 MVP설계는 구축으로 이어지지 않아 종이로 남아있는 서비스, 서비스를 진단하고 개선안 제안으로 끝나기도 한다.
물론 에이전시에서 일하면 다양한 도메인을 다룰 수 있다. 일한지 2년도 안되었지만, 지금까지 금융, 항공, 전기차와 관련한 서비스가 내 손을 거쳐갔다. 서비스 출시 이후 사용자 반응을 보지 못하여 일에 대한 만족감을 떨어뜨렸다. 물론 사용자 인터뷰를 통해 정성적인 데이터를 추출하여 사용자의 반응을 볼 수 있지만, 정량적인 데이터를 근간으로한 가설 검증과 반응을 알 수 없었다.
내가 만든 서비스가 실시간으로 사용자에게 얼마나 임팩트를 줬는지 증명하고 싶었다. 거기서 일에 대한 만족감을 찾을 수 있을 것 같았다. 물론 내가 만든 모든 서비스가 성공할거라는 보장은 없지만, 실패든 성공이든 직접 내 눈으로 확인하고 싶었다.
사용자를 위한 서비스를 만드는 사람이라고 말하지만, 사용자의 반응을 보지 못하는 환경에 있다보니 사용자와 거리두기를 실행 중인듯 하다. 사용자와 제일 가까이 있는 기획자가 되어 그들의 어려움 나의 능력으로 더 나은 경험을 제공하고 싶다.
언제까지 "~되고 싶었다."라고 과거형으로 말할 수 없다. "~하고 있다" 현재형으로 하는 일에 자부심을 가지고 말하기 위해 3년 차, 22년 12월을 기준으로 역순으로 커리어 계획을 세웠다. 구체적이지는 않지만, 내가 그리는 3년 차의 모습은 내가 주체적으로 설계한 서비스로 n명의 사용자가 가치를 느끼고 사용하고 있는 것이다. 물론 다양한 사람들의 모여 서비스를 만들지만 한명의 역량으로 다수가 가치를 느끼는게 얼마나 효율적이고 생산적인 일인가.
지금 환경에서 사용자의 반응을 직접 관찰하고 싶은 갈증을 해소할 방법은 사이드 프로젝뿐이었다. 이 상태로 불평불만만 가지고 있다면, 3년 차가 되었을때도 지금과 비슷한 것 안봐도 뻔하다. 불안한 생각이 나를 움직였다.
사용자가 필요한 서비스를 만들어 런칭하는 것이 최종 목표지만 개발자와 협업하여 실제로 앱스토어에 내가 만든 서비스를 올리는것 까지, 전체적인 서비스 제작 경험이 필요했다. 핵심 MVP를 기획해서 시장에 런칭하는 것을 1차 목표로 설정했다.
지금 당장
100번 실패해보기
사이드프로젝트 목표를 서비스 출시와 더불어 빠르게 실패해보자고 덧붙였다.
내 주변에 자사 서비스를 가진 대표님들과 이야기해보면 하나같이 입 모아서 처음부터 이 서비스가 짠! 하고 나온게 아니라고 말씀하신다. 100번은 시도해봐야 97번 망하고 2-3개 사용자가 원하는 서비스를 런칭했다고 말했다. 토스 이승건 대표는 수도 없이 사업에 실패하고 투자금액이 3개월분밖에 남지 않은 상태에서 마지막 시도한 서비스가 토스였다고 한다. "실패는 성공의 어머니이다." 진부한 이야기로 들릴 수 있지만, 진리이며 성공을 향하는 길이다. 그 순간 "성공해야겠다!"가 아닌 "빨리 실패해봐야겠다." 고 생각했다.
빠르게 실패를 맛보기위해 밤 10시, 개발자 친구에게 전화했다. 사이드프로젝트 같이 하자는 제안에 고맙게도 해보자! 고 답했다. 인하우스에 근무중인 개발자 친구는 자사 서비스에서 비슷한 개발 코드만 사용한다고 한다. 사이드프로젝트를 통해 새로운 코드를 공부하고 싶은 니즈가 있었다.
회사에서 이미 앱 런칭 경험이 있는 직장 동료를 설득하여, 디자이너 베이스 기획자2명, 개발자 2명 총 4명의 Monday Talker 사이드프로젝트팀이 꾸려졌다. (Monday Talker는 월요일 회의할 때마다 말을 많이 해서 지어진 팀 이름이다.)
서버 없이 할 수 있는 글쓰기 서비스_
"일단쓰자!"
첫 프로젝트인 만큼 욕심 없이 빠르게 앱 런칭 경험을 1차 목표로 삼은 만큼 서버가 붙지 않은 서비스를 만들기로 했다. 서버가 붙지 않는 제약사항에 기획 한계가 있지만, 그럴때마다 욕심없이 빠르게 앱 출시하자라는 내 목표를 되새겼다.
여러 씨드 아이디어를 개발자와 일정 및 공수를 검토한 끝에, 부담 없이 글 쓸 수 있는 서비스를 만들기로 결정했다. 사회생활하면서부터 글쓰기는 피할 수 없음을 깨달았고, 글을 잘 쓰기위해서는 다들 다독, 다작 뿐이라고 입모아 말한다. 글을 잘써야한다는 부담감을 덜어주고 글쓰기 습관을 길러주는 서비스 기획했다.
프로젝트를 진행하면서 팀원들의 뼈 때리는 피드백을 많이 받았다.
사회에 나와보니 막상 나의 성장에 관심을 가지는 사람이 없다. 학창시절때와 달리 나의 성장은 오롯히 내가 챙겨야한다. 성장을 이끄는 날카로운 피드백은 애정이 있어야 가능한 일인것을 알기에 하나도 빠뜨리지 않고 기록으로 남겼다.
지금보면 이 사이드프로젝트에서 가장 유의미했던 일을 찾으라면 개인적인 도약을 이끈 팀원들의 날카로운 피드백이다.
누구에게는 너무나 당연한 이야기일지 모르겠다. 하지만 이 당시 서비스를 처음부터 끝까지 책임지는 경험이 처음이이었던 나에게는 모든 것이 당연한 일이 아니었다.
첫 사이드프로젝트 레슨런_
당연하지만 당연하지 않았던 것
1. 팀원의 목표 인지하기
효율을 중요한 가치로 두는 나에게 '왜?'하는지 모르는 비생산적인 활동을 제일 경계한다. 따라서 어떤 일을 하기에 앞서, 같이 하는 팀원들의 목적 공유를 가장 중요하다. 왜 하고 싶은지? 해당 프로젝트을 통해 이루고 싶은 것이 무엇인지? 가장 먼저 묻는 질문이다. 상호 간 목표 인지는 협업과 시너지 발생에 중요한 요소이다.
총 4명이 모여 프로젝트를 진행하기에 앞서 목표를 공유하는 시간을 가졌다.
4명 모두 프로젝트 구축 경험에 대해 목적이 동일했다. 더 나아가 기획과 디자인을 하는 나와 내 직장동료는 데이터를 보고 싶은 니즈가 있었다. 개발자들을 회사에서 항상 사용하는 분야의 개발만 한다고 한다. 이 프로젝트를 통해서 새로운 분야의 코드를 개발하고자 했으며, 추후 광고를 심어 수익화를 하고자 했다. 욕심을 내지 않기로 했으니 무엇이 되든 구글 플레이에 런칭하는 것을 공통의 목표로 잡았다.
2. 모두가 공감하는 서비스 만들기
사이드프로젝트를 할 때 팀원 간 '목적 공유' 다음으로 중요한 것은 '공감대' 형성이다. 공감하지 않는 서비스를 만들 경우, 진행률과 참석률이 현저히 더뎌진다. 본업을 마치고 지친 몸과 정신 상태로 추가로 진행하는 사이드프로젝트인 만큼 동기부여가 확실해야 하기 때문이다. 공감하지 못한 채로 진행한다면 구성원 참여율이 낮아진다.
사실 우리가 공감 가는 서비스가 아니라 사용자의 공감대가 필요한 서비스를 만들어야 한다. 하지만 데이터를 가지고 가설을 세우고 검증하는 과정을 건너뛰고 서비스 런칭이 목표였다. 따라서 해당 서비스의 사용자는 팀원이라고 생각하고 공감대를 형성했어야 했다.
다음 프로젝트에서는 가설은 내부에서세우더라도 1차적으로 사용자로부터 검증한 데이터로 팀원들이 공감하는 서비스 기획을 해야겠다고 생각했다.
3. 모든 기획에는 근거가 있어야한다.
너무나도 당연한 이야기 아닌가? 그렇다. 하지만 이 당연한 이야기를 간과했다.
버튼 하나에도 근거가 필요하다. 그 근거가 "메이저 서비스에서는 이러니까..’ 같은 생각이 제일 큰 문제였다. 요소 하나하나 ‘왜?’라고 생각하지 않고, 습관처럼 하는 카피 기획이었다.
개발자의 피드백 중 "글쓰기를 완료하고 저장 버튼을 눌렀을 때, 토스트 대신 왜 확인 알럴트를 두었나요?" 라는 질문에 대답을 못했다.
브런치에 글 발행할때를 생각해보자.
브런치에서 글을 발행시, “발행하시겠습니까?” 확인 알럴트를 사용자에게 노출한다. 하지만 메모장에 글을 쓰고 저장할 경우, 토스트 혹은 어떠한 알림을 받지 않는다.
동일한 글쓰기 저장 기능인데 태스트가 다른 이유는 무엇일까?
브런치 글의 경우 퍼블릭한 공간에 발행되는 것이며구독한 독자에게 알람까지 간다. 하지만 메모장에 저장 기능은 개인만 보는 저장공간에 저장되기때문에 사용자에게 재확인을 받을만큼 신중하지 않아도 된다.
우리 서비스의 첫 기획을 봤을 때, 글작성을 완료하고 완료 버튼을 터치하면 알럴트를 호출된다. 서버를 붙이지 않은 상태라 글이 나에게만 공개되는데도 확인 알럴트는 호출하는 것은 댑스를 추가하는 꼴이 된다. 왜? 라고 구체적으로 정의해본 적이 없기 때문에 발행한 습관적인 기획이었다.
왜? 하는지 모르는 비효율적인 테스크를 가장 싫어한다고 말해놓고 기획에서는 놓치고 있는 나를 발견해서 적잖이 충격이라 빠르게 태도를 고쳤다. 앞으로 모든 서비스를 만드는 데 있어서 최우선 순위로 두게 되었다. 피드백 받은 다음 날 회사에 돌아가자마다 기획한 화면을 보고 "엑스버튼은 왜 오른쪽에 두면 안되지? ", "햄버거 버튼을 꼭 왼쪽에 두어야 할까?", " 약관 동의 화면에서 체크박스를 왼쪽에 배치한 근거는 무엇이지?" 등 컴포넌트 하나 만들때마다 '왜?'라고 문하며 근거를 생각하는 태도를 취했다. 이 기조로 다른 서비스 벤치마킹과 관련된 글을 읽으면서 근거를 정리해나갔다.
한 번에 고쳐질지 만무하다.
그럴 때마다 "개발자를 설득하지 못하는데 어떻게 사용자들한테 설득력 있는 서비스를 만들 수 있을까요?" 날카로운 피드백으로 등에 식은 땀이 마를 날이 없었다.
개발자가 역기획 제안을 줄 때도 있지만, 개발의 복잡성 낮추기위해 기획자를 설득하기도 한다고 솔직하게 말씀해주셨다. 그럴 때는 기획자가 근거를 가지고 기획했다면, 완고하게 사용자에게 어떤 경험과 효익을 제공하기 위해 해당 기획안처럼 해야 한다고 말하면 개발자도 설득된다고 피드백해주었다.
어디서 누가 이렇게 솔직한 피드백을 해주겠는가? 피드백 들을때는 멘탈이 흔들릴 정도였지만 내가 잘되길 하는 마음에서 해주신 피드백이 너무 감사했다. 이때 받은 피드백 이후로 내가 일하는 방식이 180도 바뀌게되었다.
4. 모든 경우의 수 최대한 고려하기
"100% 완벽한 화면 설계서는 없어요. 하지만 기본적인 케이스는 좀... 고려해야 하지 않을까요? 사용자가 사용하는 서비스를 만들기 이전에 기획한 본인이 사용하고 싶은 서비스인지 한 번 더 생각해보고 케이스를 정의해주세요."
100% 완벽한 화면 설계서는 없다.
처음부터 모든 경우의 수를 고려한 기획서가 나올 수 없다. 하지만 내 선에서 최대한 경우의 수를 고려하기위해 모든 화면 핸드폰으로 옮겼다. 내가 사용자라고 생각하고 화면을 시뮬레이션해보면서 최대한 모든 경우의 수를 생각해보면서 불완전한 기획서를 보완했다.
5. os 체계는 확실하기 인지하기
버전1에서는 안드로이드 개발만 진행했다. 하지만 오랜 시간 동안 아이폰을 사용하여 ios에 익숙했으며, 어떤 컴포넌트가 ios에서 차이가 많은지 인지 못했다. 기획 업무만 한다고 하면 os체계의 대한 이해의 중요성이 떨어질 수 있다. 디자이너가 화면설계서를 보고 케이스를 나누어 시안을 작업할 수 있기 때문이다. 안드로이드 개발인데 사용하는 디자인도 컴포넌트 요소들도 ios기준이라 개발자 입장에서는 다소 이해하기 힘들었던 부분이었다. 예를 들어 년도와 날짜를 선택하는 date picker가 안드로이드에서는 팝업, 애플에서는 바텀 시트가 기본적인 시스템 컴포넌트 정의이다.
알다시피 AOS/IOS의 가장 큰 차이 중 하나는 system backspace 유무이다. 안드로이드 폰에서는 사용자가 시스템 백스페이스를 선택했을 때 어떤 데이터를 가지고 있어야하지 추가 정의가 필요했다. 구글 디자인 시스템 정의를 참고도 좋지만 실제로 사용해보고 os차이를 체화하려고 공기계를 구했다.
그렇다면 화면 디자인은 AOS/IOS용 두벌이 나와야 하는 것일까?
이 질문은 회사에서 구축 때 개발자와 직접적으로 소통한 GUI디자이너분들께 여쭤보았다. os 상관없이 동일하게 사용되는 화면에서는 하이브리드로 개발하고 한 화면으로 시안을 만들면 된다. 하지만 os별로 차이가 있는 화면은 두가지 버전으로 디자인 시안을 만들고 개발자와 커뮤니케이션을 한다고 말해주셨다. 예를 들어 date picker에 디자인을 입힌 화면을 os별로 2벌을 만들어야한다. 결론은 os시스템의 이해가 되어있어야 힌다. 지금 생각하면 매우 부끄러운 일이지만 이번 경험이 없었으면 아직도 깨닫지 못했을 것이다.
6. PM(Product Manager)의 역할은 프로젝트 시작부터 앱 배포 이후까지 책임지는 사람임을 명심하자
"네가 실질적으로 지금 PM인데, 처음부터 앱 런칭 이후까지 책임져야 하는데 너무 손을 뗀 느낌이다. 기획과 디자인 끝나면 할 일이 많이 없는 건 아는데 개발 진행 상황에 너무 관심이 없고 손을 뗀 느낌이 들었어."
개발자 친구가 가감없이 해준 피드백이다.
앱 런칭하는 과정도 어떻게 되는지 능동적으로 찾아보고 개발자가 이미지 요청하는 게 아니라 구글 조금만 찾아보는 태도를 가졌으면 좋겠다고 했다.
PM이 앞으로 일정을 생각하고 챙겨야 할 것들을 챙겨야하는데 개발자들이 챙기니까 당연히 그들의 몫이라고 생각하고 아무 생각이 없었다. 일례로 구글 플레이 스토어에 올라가는 서비스 소개 이미지도 내가 미리미리 챙겼어야했는데, 개발자들이 만들어야 하는 이미지와 사이즈를 다 알려줬다. 처음이라는 핑계로 주체적으로 찾아보지 못했다. 경험도 노하우도 없는 PM으로 인해 여기 모든 팀원이 PM이 된 셈이다. PM은 시작부터 앱배포 이후, 관리까지 책임지는 사람임을 명심했다.
앞으로 남은 일
아무리 간단한 프로젝트라도 본업을 가진 채 다른 서비스를 만드는 게 얼마나 많은 노력과 의지가 필요한 일이지 직접 깨달은 지금은 개발 막바지 단계이다. 그 동안 QA하는 법을 알아보고 목록을 짜고 일정에 맞춰서 테스트하려고 한다. 지금 만드는 서비스의 phase 2를 계획하고 있다. 일정에 맞추다 보니 핵심 기능이 빠졌고 아직 부족한 점이 있다. 버전 2에서는 서버를 붙여서 서비스네 네트워크 형성을 핵심으로 사용자가 광고를 볼 수 밖에 없는 플로우 설계와 정성적 데이터를 통한 페인포인트와 문제 해결방법을 적용할 것이다.
더 나아가 내 니즈에서 시작된 서비스를 만들었지만, 다음 단계에서는 정성적 수치를 모아서 탄탄한 근거를 기반으로 서비스를 만들 것이다. 그 과정에서 또 얼마나 모르는 것에 직접 부딪치고 해결할지 두려움과 기대가 공존한다.
솔직히 시행착오를 글로 남기는 것은 나의 부족함을 필터없이 드러내는 것 같아서 매우 부끄럽다. 배우고 느낀점을 남 이야기하듯 담백하게 올릴 수 있었지만, 날것 그대로 내 솔직한 생각과 상황을 생생하게 기록했다. 더 이상 내가 저 상태가 아니고 과거형으로 말할 수 있기 때문에 가능한 일이다.
말로만 성장했다고 하는 게 아닌 다른 프로젝트를 하면서 내가 이번 사이드프로젝트으로 얼마나 성장했는지 다음 프로젝트를 하면서 실로 체감했다.
말로만 성장했다!가 아닌
실제로 성장했음을 체감했을 때
글쓰기 서비스에 이어 다른 사이드프로젝트에도 참여하게 되었다. 가상부동산 거래 플랫폼 서비스를 만들고 있고, 여기서는 PM은 아니지만 기획-디자인을 하고 있다.
근거를 가지고 와이어프레임을 리뷰하고 개발자분들의 질문을 해도 기획 시 생각한 근거를 통해서 설득하면서 대응하고 있는 내 모습을 회의시간마다 발견한다. 기획할 때부터 하나하나 왜? 라는 질문을 가지고 화면을 설계했기 때문이다. 낯간지럽지만 "나 진짜 성장했구나..!"를 몸소 느꼈다.
실행에 옮기지 않았다면 성장할 기회는 없었을 것이고, 부끄러운 회고 글도 없었을 것이다. 역시 생각과 동시에 실행해야 하는 게 맞는 것 같다. 덕분에 3년 차 그리는 나의 모습이 Opacity 10%에서 대략 42%(?)까지 선명하진 느낌이다.
21.11.21
11월 21일 지금, 이 글의 초안을 다듬으며 다시 읽었다.
첫 문단에 사이드프로젝트를 시작한 이유에 이런 문장이 있다.
'너 어떤 일 해?' 라는 질문에 나는 000 서비스 만들고 있어! 라고 한 마디로 설명하고 싶다.
이제 이 질문을 답을 할 수 있게 되었다.
3일전에, 두번째 사이드프로젝트로 진행한 서비스가 런칭했다.
런칭 24시간만에 가입자수 1만명,
48시간만에 신규 가입자수가 10만명을 돌파했다.
(21.12.27 업데이트_ 26만명 돌파)
두번째 사이드프로젝트할때도 배웠던 점이 많았다. 후기도 조만간 올리봐야겠다.
