PM 이력서 작성법 - 출시한 기능 대신 책임진 지표를 적습니다

여기서 말하는 PM은 제품의 한 영역을 맡아 무엇을 만들지 정하고 그 결과를 지표로 책임지는 프로덕트 매니저입니다. 회사에 따라 PO(프로덕트 오너)라고도 부릅니다. 이 직무의 이력서에는 비슷한 문장이 자주 나옵니다. 신규 회원 온보딩 개편 기획과 출시, 결제 플로우 개편 리드, A/B 테스트 진행 같은 문장입니다. 담당자는 이 문장만으로 지원자가 PM으로 일했는지 판단하기 어렵습니다. 기능을 정의하고 출시를 관리하는 일은 서비스 기획자나 프로젝트 매니저도 하기 때문입니다. PM 경력에서 담당자가 알고 싶은 것은 지원자가 어떤 숫자를 맡았고 그 숫자를 움직이려고 무엇을 정했는지입니다.

기능 이름 대신 책임진 지표를 적습니다

담당자가 PM과 서비스 기획자를 구분할 때 보는 것은 제품 지표를 맡았는지입니다. 리텐션, 활성화율, 전환율, 거래액처럼 그 영역의 성패를 재는 숫자가 지원자의 목표였는지를 확인합니다. 기능 출시만 나열된 이력서로는 이것을 알 수 없습니다. 같은 온보딩 개편이라도 "온보딩 개편 출시"라고만 쓴 문장과 "신규 가입자의 7일 리텐션을 맡아 온보딩을 개편했다"고 쓴 문장은 다른 경력을 말합니다. 뒤 문장에는 지원자가 무엇을 책임졌는지가 들어 있습니다. 실제로 한 커머스 PO 공고는 단일 기능이 아니라 거래액과 전환율 같은 비즈니스 지표에 오너십을 갖고 개선한 경험을 자격 요건으로 적었습니다. 지표를 맡아 본 경험을 기능 경험과 구분해서 보는 회사가 있다는 뜻입니다. 지표를 적을 때는 기간과 출발점을 함께 씁니다. 몇 달 동안 맡았고 시작할 때 숫자가 얼마였는지가 있어야 담당자가 변화의 크기를 가늠합니다.

실험은 결과와 결정까지 씁니다

"A/B 테스트 진행"은 PM 이력서에 자주 나오는 문장이지만 담당자가 이 문장에서 얻는 정보는 거의 없습니다. 담당자에게 필요한 것은 실험을 했다는 사실이 아니라 무엇을 확인하려 했는지와 그 결과로 무엇을 정했는지입니다. 실험 하나를 적을 때는 네 가지가 있으면 충분합니다.

• 세운 가설
• 비교한 안
• 결과 숫자(전환율이 몇 퍼센트포인트 달라졌는지, 통계적으로 의미가 있었는지)
• 그 결과로 내린 결정

가설이 틀린 실험도 이력서에 적을 수 있습니다. 바꾼 안이 이기지 못해 원래 화면을 유지했다면 그것도 PM이 내린 결정입니다. 실험을 근거로 무엇을 하지 않기로 했는지가 적혀 있으면 지원자가 숫자를 보고 판단하는 사람이라는 근거가 됩니다. GridResume 기업 채용 분석에 있는 PM 공고 가운데 무신사, 카카오페이, 페이타랩 공고는 실험을 설계하고 실행한 경험을 자격 요건으로 요구했습니다. 이런 회사에서는 실험 경험이 우대 사항이 아니라 지원 조건입니다.

미룬 과제와 그 이유를 적습니다

PM의 판단은 무엇을 만들었는지보다 무엇을 미뤘는지에서 더 분명해집니다. 로드맵에 넣고 싶은 일은 늘 개발할 수 있는 시간보다 많습니다. PM은 그중 일부만 고릅니다. 이력서에 우선순위를 적을 때는 고른 과제와 미룬 과제, 그리고 그 근거를 함께 씁니다. 근거는 RICE(도달 범위·영향·확신·공수로 점수를 매기는 방식) 같은 틀이어도 되고 예상 효과와 개발 공수를 비교한 판단이어도 됩니다. 담당자가 보려는 것은 틀의 이름이 아니라 지원자가 직접 세운 근거입니다. 다른 팀이 낸 요청을 분기 목표와 관련이 적어 미뤘다면 그것도 적을 수 있습니다. 어떤 기준으로 미뤘고 나중에 그 판단이 맞았는지까지 적으면 제품의 방향을 정해 본 경험이 드러납니다.

데이터를 어디까지 직접 다뤘는지 밝힙니다

GridResume 기업 채용 분석의 PM 공고 13건 가운데 9건이 자격 요건에 데이터를 다루는 역량을 적었습니다. 담당자가 여기서 확인하는 것은 데이터를 직접 봤는지입니다. 분석가가 만든 대시보드를 받아 본 PM과 SQL로 가입 월별 사용자를 직접 나눠 이탈 구간을 찾은 PM은 이력서에 모두 "데이터 기반 의사결정"이라고 적어도 한 일이 다릅니다. 직접 쓴 도구와 직접 만든 분석을 적어 두면 데이터를 어디까지 다뤘는지가 분명해집니다. 분석가에게 분석을 맡겼다면 그 사실도 그대로 적으면 됩니다. 어떤 질문을 정해 분석을 요청했고 그 결과로 무엇을 바꿨는지를 함께 적습니다.

같은 경력을 이렇게 적으면

• 약한 문장: 신규 회원 온보딩 개편 기획 및 출시

• 강한 문장: 신규 가입자 7일 리텐션(시작 시점 18%)을 책임 지표로 맡아 온보딩 단계별 이탈을 분석했고, 단계를 5개에서 3개로 줄여 6개월 동안 리텐션을 24%로 높였습니다.

• 약한 문장: 상품 상세 페이지 A/B 테스트 진행

• 강한 문장: 리뷰 요약을 상단에 노출하면 구매 전환이 오른다는 가설로 2주 동안 A/B 테스트를 진행했습니다. 전환율 차이가 통계적으로 유의하지 않아 기존 화면을 유지하고 리뷰 필터 개선으로 방향을 바꿨습니다.

• 약한 문장: 분기 로드맵 수립

• 강한 문장: 결제 영역 분기 로드맵을 세우며 요청 과제 12건을 예상 효과와 개발 공수로 비교해 4건을 골랐고, 거래액 목표와 관련이 적은 8건은 다음 분기로 미뤘습니다.

• 약한 문장: 데이터 기반 의사결정

• 강한 문장: SQL로 가입 월별 사용자를 직접 나눠 첫 결제 뒤 30일 안에 이탈하는 구간을 찾았고, 그 분석을 근거로 재구매 쿠폰 실험을 제안해 30일 재구매율을 4퍼센트포인트 높였습니다.

강한 문장에는 맡은 지표나 결과 숫자, 그리고 직접 정한 것이 함께 있습니다. 그래서 담당자는 지원자가 어떤 숫자를 맡았고 무엇을 근거로 결정했는지를 문장 하나로 확인합니다.

지표를 맡지 못한 자리라면

주니어 PM이나 APM은 기능 명세와 QA, 출시 일정 관리를 맡고 지표는 리드가 갖는 경우가 많습니다. 회사에 따라서는 PM이라는 이름으로 일정 관리만 맡기도 합니다. 이런 자리에서는 책임진 지표가 없으니 이력서에 적을 것이 없다고 느끼기 쉽습니다. 그래도 남길 수 있는 기록이 있습니다. 맡은 기능에 지표가 정해져 있지 않다면 그 기능의 성공 기준을 직접 정하고 매주 추적한 기록을 이력서에 적으면 됩니다. 이탈 구간을 분석해 실험을 제안했고 그 제안이 채택됐다면 그것도 가설과 실험을 다뤄 본 경험입니다. 다만 지표 없이 기능 출시만 반복하는 구조가 몇 년째 이어진다면 원인은 개인보다 조직에 있습니다. 실험에 쓸 데이터 환경이 없는 회사라면 더 그렇습니다. 그럴 때는 실험 문화와 데이터 도구가 갖춰진 회사로 옮기는 것도 방법입니다. 지금까지 다룬 도메인을 이어 갈 수 있는 곳이면 더 좋습니다.

실험이 끝날 때마다 숫자를 남겨 둡니다

실험이 끝난 날이나 분기 리뷰를 마친 날에는 위에 적은 숫자를 PM이 대부분 정확히 알고 있습니다. 시작 시점의 지표, 실험 결과, 미룬 과제와 그 이유입니다. 그런데 이력서를 쓰는 날에는 이 숫자가 실험 도구와 사내 문서에만 있습니다. 회사를 옮기면 그 문서를 다시 열어 볼 수도 없습니다. 기억에 남는 것은 출시한 기능 이름뿐이라 PM 이력서가 기능 목록이 되는 경우가 많습니다. 실험이나 분기가 끝날 때마다 몇 줄씩 적어 두면 이 문제를 줄일 수 있습니다. 맡은 지표와 출발점, 세운 가설, 결과, 내린 결정 정도면 충분합니다. GridResume 커리어 기록에 이렇게 남겨 두면 이력서를 쓸 때 책임진 지표가 들어간 문장을 바로 만들 수 있습니다.

정리하면

PM 이력서에서 담당자가 확인하는 것은 네 가지입니다. 책임진 지표와 그 출발점이 있는지, 실험이 결과와 결정까지 적혀 있는지, 무엇을 미뤘고 왜 그랬는지가 나와 있는지, 그리고 데이터를 어디까지 직접 다뤘는지입니다. 기능 목록은 PM이 아니어도 쓸 수 있는 문장입니다. 맡은 숫자와 그 숫자를 두고 내린 결정이 적혀 있으면 담당자는 지원자가 PM으로 일했다는 것을 이력서만으로 확인할 수 있습니다.