2년차 PM의 하루
다이내믹하고 옹골차게 흘러가는 8시
01. PM은 어떤 일을 하나요?
지인들에게 명함을 드릴 때면 "PM은 어떤 일을 해?"라는 질문을 종종 받았습니다. 직무명 자체가 생소한 것일 수도 있고 업계나 회사마다 PM의 역할 범위가 매우 다를 수 있기 때문에, 궁금해하실 수 있는 부분인 듯 합니다. 저도 PM이 되기 전에는 'PO도 있고, 기획자도 있고, Project Manager도 있고.. Product Manager는 어떤 일을 하는 거지?' 궁금했는데요, 여러 아티클을 읽어봐도 사실 크게 와닿지는 않았던 것 같습니다. 그러다 우연히 (알고리즘의 선택을 받아) 해외에서 PM으로 일하시는 분의 하루 일상을 담은 브이로그를 보게 되었는데, 그 때 처음으로 PM이 어떤 역할인지 조금은 알 것 같다는 느낌을 받았습니다.
"PM이라는 직업이 무엇인지"는 너무나 큰 주제이고, 제 경험치에 따라 답이 계속 달라질 것 같아 별도의 주제로 작성해보려고 합니다. (매년 그 글로 돌아와, 달라진 제 생각을 기록해봐도 재밌겠네요!) 그래서 이번 글에서는 하루의 큰 패턴을 돌아보며 어떤 일들을 통해 제가 PM이라는 역할을 만들어가고 있는지 돌아보는 정도를 목표로 하려 합니다. 더불어, PM 직무가 궁금하신 분들께 약간의 참고 자료가 될 수 있다면 기쁠 것 같습니다.
02. 오전 : 장전 시간
저희 팀은 8시 ~ 10시 사이 시간을 자율적으로 선택해 출근하는데, 저는 8시 출근을 선호합니다. 처음에는 퇴근 후 글도 쓰고 운동도 하려고- 오후 시간을 확보하기 위해 8시 출근을 택했는데요. 하다보니, 업무에서도 장점이 체감되었습니다. 일찍 출근해 프로젝트 현황을 파악하고 업무 요청에 필요한 자료를 미리 준비해둘 수 있기 때문입니다. 협업 요청이 잦은 직무 특성상, 오전에 집중해서 자료를 파악할 수 있는 시간이 있다는 것이 업무 효율성에 큰 도움이 되었습니다.
(1) 하루 시간표 짜기
구글 캘린더, 태스크 관리보드를 참고해 오늘의 미팅 / QA / 배포 일정 등을 확인합니다. 프로젝트 문서에 접속해 그 프로젝트 진행을 위한 태스크별 현황을 확인하고, 혹시 관리가 필요한 회색 지대는 없는지도 체크해봅니다. 그리고 오늘 하루 세세한 타임라인을 짜는데요. 저는 업무를 크게 [소통이 중요한 협업]과 [집중이 필요한 기획]으로 나누고, 모두가 출근한 코어 시간대를 기준으로 집중력 전환이 될 수 있도록 하루 계획을 세우는 편입니다. 물론 지키기 어려울 때도 많지만, 하루 그림을 그려보는 것이 저의 업무 안정성에는 큰 도움이 됩니다.
중학생 때부터 쓰는 다이어리. 대충 휘갈겨 씁니다. 노션도, 캘린더도 있지만 중요 일정은 다이어리에 써두어야 마음이 든든해집니다.(2) 배포건 현황 분석하기
지난 주에 배포한 기능 또는 실험의 데이터를 확인하고 분석합니다. 저희 팀은 실험 진행을 위해 Hackle을 사용하는데요, Hackle에 접속해 AB test의 p-value 추이가 어떤지 살펴보며 최소 실험 기간의 수정이 필요한지를 판단하기도 합니다. 아침마다 루틴으로 현황 분석을 하는 주 목적은 배포건의 임팩트를 촘촘하게 체크하는 것이지만, 가끔은 로깅 오류나 가드레일 지표의 악화 등 위험 신호를 찾아내기도 합니다. 문제가 더 악화되기 전에 기능 수정 요청을 빠르게 드릴 수 있습니다.
현황 분석 후 실험 종료를 제안할 때(3) 기획서 작성하기
오전 시간의 후반부는 집중이 필요한 기획 문서 작성에 주로 활용합니다. 제가 작성하는 기획서는 크게 1) 정책 문서, 2) 제작요청 문서 로 나뉘는데요. 업무 단위가 '태스크'인 경우에는 바로 제작요청 문서부터 작성하기도 하지만, 새로운 기능 도입 관련 업무이거나 여러 태스크가 얽혀있는 '프로젝트' 단위의 업무인 경우에는 정책 문서 작성에 상당의 시간을 할애합니다. 특히 새롭게 익혀야 하는 기능과 관련된 정책 설계의 경우, 배경이 되었던 슬랙이나 문서의 링크를 먼저 보고 필요하면 유관 부서에 합의 또는 질문을 하러 사무실 이곳 저곳을 돌아다닙니다.
제작 요청 문서의 경우에도 어떤 문서이느냐에 따라 작성법을 조금씩 달리 하고 있는데요. 디자인 요청 문서의 경우, 기획 의도를 최대한 핵심만 작성하고 기획 배경이 되었던 참고 자료 (ex. 최근 N주 리드 분포 변화 및 그에 따른 전환율 악화)를 문서에 첨부합니다. 그리고 디자인에 대한 '제안'을 작성하되 어떤 부분에서 디자이너의 주도적인 결정/조언이 조금 더 필요한 내용인지 언급하는 편입니다. 저희 팀의 디자이너 분들은 프로덕트 디자이너로, 디자인의 시각적인 기능 뿐 아니라 제품 내에서 고객 경험에 기여하는 부분까지 총괄적으로 설계하시는 분들이기 때문에 세세한 기획서가 모두 완성되기 전부터 조언을 구하는 것이 협업에 큰 도움이 되더라고요! 그래서 문서는 간결하게 작성하고, 같이 화면을 보며 구두로 논의하는 시간이 좀 더 긴 편입니다.
개발 요청 문서의 경우, 제가 책상에 앉아있는 시간이 좀 더 긴 편인데요. 보통은 [백엔드, 프론트엔드, (중요해서 별도로 문서 작성) 로그, (필요시) 실험 세트 연결]로 구성된 요청 문서를 작성합니다. 전체 흐름을 이해하는 데에 도움이 될 만한 참고용 플로우 차트도 종종 첨부합니다. (쓰다보니 제작 요청 문서와 관련해 기록해두고 싶은 내용이 많이 떠오르는데, 별도 주제의 글로 작성해보겠습니다!)
기획서 작성 중, 여러 유관 부서 간 합의나 인지가 반드시 필요한 내용이 예상치 못한 곳에서 나오기도 하는데요. 이럴 때는 기획서 공유 미팅 일정을 잡습니다. (구글 캘린더를 누비는 하이에나가 됩니다.)
(4) 실험 세팅하기
저희 팀은 스프린트 단위가 짧아 단기간 내에 많은 건들이 새롭게 배포됩니다. "당연히 잘 될 거야" 싶은 것들도 실제로 고객에게 노출되면 전혀 예상과 다르게 흘러가기도 하고, "일단 무언가 많이 했다!"로 끝내지 않기 위해- 대부분의 배포건에 모두 AB test를 진행합니다. (Apple to Apple 비교가 정말 어렵거나, 테스트 세팅을 위해 수정해야 할 것이 너무 많아 실험에서 얻는 이득보다 비용이 큰 경우에는 예외적으로 Before & After로 지표를 비교합니다.) 실험 가설에 맞춰 Hackle에서 실험 설명 문구 작성, 지표 (성공지표, 가드레일 지표, 보조지표)를 선정합니다. 그리고 엔지니어가 실험 세트를 연결할 수 있도록 실험 Key를 전달하고, 지표에 대한 피드백이 필요한 경우에는 Business Analyst에게 실험 링크를 사전에 공유합니다. 가설 입증에 참고할 만한 추가 지표 또는 해당 실험군의 매출 기여도를 판단할 수 있는 보조 지표를 제안해주시면- 지표를 추가하며 '이런 관점으로 볼 수도 있구나' 배우기도 합니다.
03. 오후 : 발사 시간
오전에 정리한 것을 바탕으로 오후에는 주로 협업이나 미팅에 참여합니다.
(1) 주간 회고 미팅
저는 마케터 1명, 디자이너 1명, 개발자 2명, 그리고 저 PM 1명 으로 구성된 스쿼드를 리드하는데요. 보통 스쿼드 단위로 구체적인 액션을 결정하되, 제품 전체의 전략에 대해 논의할 때는 스쿼드 간 지식/의견 공유가 가능하도록 스쿼드별 PM끼리 모여 미팅을 진행합니다. '이런 데이터는 매일 체크합시다'라고 정한 스쿼드별 대표 지표의 주간 추이를 보고 특이사항이 없었는지 검토합니다. 이 때 지난 주 배포건의 액션 로그를 함께 보며 지표 변화가 어떤 요인의 영향으로 말미암아 발생했는지 추론합니다. 이렇게 지난 액션의 영향력을 파악해 러닝을 쌓고, '그래서 다음 주에는 / 다음 챕터에는 어떻게 그 러닝을 확장 적용해나갈 것인지?' 논의하는 시간입니다. 매주 있는 미팅인데요, 늘 심각한(?) 이야기만 하는 것은 아닙니다. 보통의 경우에는 주 단위 액션을 회고하고 월말이나 챕터 말에는 회고와 함께 전략을 설계하는 미팅 역할을 합니다.
(2) QA 및 배포 공유
기획한 기능의 개발이 완료되면, 엔지니어가 QA 요청 채널에 슬랙을 올려주십니다. 기획서 작성하며 확인했던 Critical Path를 중심으로 Test Case별 QA를 진행합니다. 제작한 기능에 오류는 없는지, 의도했던 바가 정상적으로 구현되었는지를 확인하는 과정입니다. 저희 팀의 경우 디자이너가 프론트엔드에 표현된 UI 중심의 QA를, PM이 로직 변경을 포함한 기능 중심의 QA를 진행합니다. 시정 필요한 케이스를 발견하면 디바이스, 브라우저, 해당 케이스 재현이 가능한 시나리오 (가능하다면 사진이나 영상 첨부) 를 작성해 QA 후 엔지니어가 확인할 수 있도록 합니다. 배포 후에 발견될 수 있는 에러에 기민하게 대응하기 위해, QA 완료 시각이 퇴근 직전인 경우에는 실배포 시각을 다음 날 오전으로 조정하기도 합니다. 배포가 완료되면 유관 부서를 태그해 각 부서나 스쿼드에서 지표 해석시 참고할 수 있도록 합니다.
(3) 밍글링
저는 PM이 스쿼드를 리드하는 역할이라 생각하는데요. 리더라면 설령 후에 틀린 방향으로 밝혀진다 하더라도 구성원 모두가 한 방향을 보고 집중해서 달릴 수 있게 도와야 한다고 믿는 편입니다. 물론 의사결정의 성공타율도 리더의 중요한 역량이지만, 언제나 옳은 결정만 할 수는 없기 때문에- 실패하든 성공하든 '후회없이 해봤다'라는 느낌과 '00을 배웠다'라는 러닝이 쌓일 수 있게 모두를 합심시키도록 노력하는 게 더 의미있는 노력이라고 생각합니다. 합심의 기반 중 하나는 유대감입니다. 그래서 함께 일하는 구성원 (저에게는 스쿼드원) 들과 다른 층 간식도 같이 먹으러 가고, 종종 점심도 같이 먹고 시시콜콜한 일상 이야기를 하기도 합니다. (동료로서의 신뢰와 유대감에 대해서는 별도의 주제로 생각을 정리해보겠습니다!)
사이 좋은 발들04. 하루를 마치며
단 하루도 예상 가능한 패턴으로 똑같이 흘러가는 날이 없었기 때문에 가장 전형적인 하루는 어떤 모습인지 돌아보는 것이 조금은 어렵기도 했고 새로웠는데요. 서비스를 만들고 성장시키면서 일어날 수 있는 회색지대의 업무를 채우는 것도 PM의 역할이기 때문에- 예상치 못하게 생기는 운영 업무 공백을 채우거나 버그에 대응하면서 하루가 다 가는 날도 있습니다. 그러면서 문제가 해결되고, 전주보다 지표가 개선되는 것들을 목격하면 하루 참 알차게 잘 보냈다는 뿌듯함이 차오르는 것 같습니다. 앞으로도 이 직업의 장점을 마음껏 만끽하고 힘든 점도 의연하게 받아들이며 더 좋은 PM이 되고 싶습니다.
