PM 준비생이라면 무조건 봐야 할 핵심 역량 5가지
"PM 채용 공고를 100개쯤 봤는데 회사마다 요구하는 게 다 달라서 뭘 준비해야 할지 모르겠어요."
PM을 준비하는 분들이라면 한 번쯤 해봤을 고민입니다.
스타트업 공고에는 '기획부터 그로스까지'라고 적혀 있고,
대기업 공고에는 '데이터 기반 의사결정'이 강조되고,
에이전시 공고에는 '클라이언트 커뮤니케이션 역량'이 들어갑니다.
같은 직무명인데 요구하는 역량이 이렇게 다르다 보니, 무엇부터 준비해야 할지 막막해지는 게 당연합니다.
PM 역할이 회사마다 다른 이유
PM이라는 직무가 이렇게 다양하게 정의되는 이유는 PM의 본질이 '특정 업무'를 수행하는 사람이 아니라 '팀이 올바른 방향으로 나아가도록 조율하는 사람'이기 때문입니다.
스타트업은 인력이 부족한 만큼 PM 한 명이 기획, 마케팅, 운영까지 넓게 커버해야 합니다. 대기업은 이미 갖춰진 시스템 안에서 데이터를 보고 우선순위를 정하는 의사결정자 역할이 더 강조됩니다. 에이전시는 클라이언트라는 또 다른 이해관계자가 있어서 조율 능력이 핵심 역량이 됩니다.
그런데 신기하게도 이렇게 다른 환경에서도 빠지지 않고 등장하는 역량들이 있습니다. 회사가 PM에게 진짜로 기대하는 본질적인 능력이기 때문입니다.
1. 내 생각이 아닌 유저의 언어로 말하는 법
PM 준비생들이 가장 흔하게 하는 실수는 "내가 써보니 이게 편할 것 같다"는 직관으로 기획을 시작하는 것입니다. 문제는 PM 본인이 타겟 유저가 아닌 경우가 대부분이라는 점입니다.
실무에서는 설문, 인터뷰, 데이터 분석 등 방식은 다양하지만 공통적으로 요구되는 건 하나입니다. "이 기능이 왜 필요한가"라는 질문에 직관이 아니라 실제 유저의 목소리로 답할 수 있어야 한다는 것입니다.
가령 "다크모드를 추가해주세요"라는 요청이 들어왔다고 가정해봅시다.
경험이 부족한 PM은 바로 개발 일정을 잡지만, 경험 있는 PM은 한 걸음 더 들어갑니다. 이유를 물어보면 "밤에 화면이 너무 밝아서 눈이 아프다"는 답이 나올 수 있는데, 이 경우 다크모드보다 자동 밝기 조절이 더 본질적인 해결책일 수 있습니다.
유저가 말한 솔루션과 유저가 겪는 진짜 문제는 다를 때가 많습니다.
면접에서 "왜 이 기능을 만들었나요"라는 질문에 "사용자들이 원해서요"라고만 답하는 것과, 리서치 과정과 근거를 구체적으로 설명하는 것은 완전히 다른 인상을 남깁니다.
2. 아이디어를 문서로 만드는 일
머릿속의 아이디어는 누구나 가질 수 있습니다. 그걸 개발자와 디자이너가 똑같이 이해할 수 있는 문서로 바꾸는 게 PM의 일입니다.
이 과정의 핵심은 세 가지입니다.
- 기능을 명확하게 정의하는 것
- 어떤 기능부터 만들지 우선순위를 정하는 것
- 요구사항을 빠짐없이 전달하는 것
PRD를 한 번도 써본 적 없는 사람과 써본 사람의 차이는 면접장에서 바로 드러납니다.
"왜 이 순서로 개발했나요"라는 질문에 머뭇거리는 것과 우선순위를 정한 기준(임팩트, 개발 난이도, 비즈니스 영향도 등)을 설명하는 것은 다르게 평가받습니다.
많은 PM 준비생들이 처음 PRD를 쓸 때 모든 기능을 똑같이 중요하다고 적어놓는 실수를 합니다. '로그인, 알림, 결제 다 중요합니다'라고 쓰면 개발자 입장에서는 뭐부터 만들어야 할지 알 수가 없습니다.
PRD의 가치는 우선순위에 있습니다.
3. 팀의 중심을 잡는 힘
기획서를 잘 쓰는 것과 그 기획서대로 팀을 끌고 가는 것은 다른 능력입니다.
매주 목표를 세우고, 일정을 점검하고, 갑자기 터지는 이슈를 해결하는 게 스프린트 운영입니다.
여기서 PM의 진짜 역할이 드러납니다. 계획이 틀어지지 않게 막는 게 아니라, 계획이 틀어졌을 때 팀이 방향을 잃지 않도록 중심을 잡아주는 것입니다.
개발 일정이 예상보다 밀렸을 때, 경험이 부족하면 당황해서 다그치기 쉽지만 경험 있는 PM은 먼저 어디서 막혔는지 파악하고 기능 범위를 줄일지 일정을 늦출지 팀과 함께 결정합니다.
이 판단을 직접 해본 사람과 해보지 않은 사람의 차이는 실무에 투입되자마자 드러납니다.
4. 사람과 사람을 연결하는 일
PM은 종종 조율자라고 불립니다.
추상적으로 들릴 수 있지만 실제로는 매우 구체적인 역량입니다.
개발자와 디자이너는 같은 문제를 다른 언어로 이야기합니다. 디자이너가 "이 인터랙션이 부드러웠으면 좋겠다"고 말할 때와 개발자가 "이 애니메이션은 리소스가 많이 든다"고 말할 때, 두 사람은 같은 화면을 보고도 다른 우려를 하고 있습니다.
PM의 역할은 이 두 언어 사이를 통역하는 것입니다. 디자이너의 의도를 개발자가 이해할 수 있는 기술적 맥락으로, 개발자의 제약을 디자이너가 받아들일 수 있는 디자인적 대안으로 바꿔주는 일입니다.
이걸 직접 해본 적이 없으면 "다른 직군과 협업한 경험이 있나요"라는 질문에 구체적으로 답하기 어렵습니다.
"사이가 좋았어요"는 협업 경험이 아니라 친목입니다.
면접관이 듣고 싶은 건 의견이 충돌했을 때 어떻게 풀었는지, 그 과정에서 무엇을 배웠는지입니다.
5. 출시 이후가 진짜 시작이다
PM 준비생들이 가장 많이 놓치는 부분입니다.
기획하고 만들고 출시하면 끝이라고 생각하지만,
실무에서는 출시가 새로운 시작입니다.
출시 직후 유저 반응을 모니터링하고,
예상치 못한 버그를 발견하면 우선순위를 정해 수정하고,
데이터를 보면서 다음 방향을 결정하는 것까지가 PM의 일입니다.
이 사이클을 직접 경험해본 사람은 면접에서 완전히 다른 깊이의 답변을 합니다.
예를 들어 출시 후 특정 기능의 사용률이 예상보다 낮다는 데이터를 발견했을 때,
'왜 안 쓰일까'를 가설로 세우고 검증하는 과정 자체가 PM의 핵심 업무입니다.
UI가 직관적이지 않은지, 애초에 유저가 필요로 하지 않는 기능이었는지, 발견하기 어려운 위치에 있었는지 등 여러 가설을 두고 추가 데이터나 짧은 인터뷰로 원인을 좁혀가는 것입니다.
회사마다 다르지만, 본질은 같다
PM의 역할은 회사마다 다르다는 말은 틀리지 않았습니다.
그러나 회사의 규모나 형태와 무관하게 PM이라는 직무의 본질을 이룹니다.
- 유저의 언어로 문제를 정의하는 능력
- 아이디어를 문서로 구체화하는 능력
- 팀의 중심을 잡는 능력
- 사람과 사람을 연결하는 능력
- 출시 이후까지 책임지는 능력
문제는 이 다섯 가지를 머리로는 이해해도 직접 해볼 환경을 찾기가 쉽지 않다는 점입니다. 다양한 직군과 실제로 부딪혀봐야 생기는 감각인데, 정작 그런 환경을 마주하기 어려운 게 현실입니다.
PM 준비생이라면 이 다섯 가지를 이론으로만 익히기보다,
직군이 다른 사람들과 실제로 부딪혀보는 게 가장 빠른 길입니다.
머리로 아는 것과 손으로 해본 것은 분명하게 차이가 납니다.
스위프는 PM, 디자이너, 개발자가 한 팀이 되어 6주 동안 실제 서비스를 기획부터 출시까지 완성하는 프로그램입니다.
유저 리서치로 문제를 정의하고,
PRD를 직접 작성하고,
스프린트를 운영하며 팀의 중심을 잡고,
다른 직군과 부딪히며 조율하고,
출시 이후까지 책임지는 과정을 6주 안에 그대로 거치게 됩니다.
이론만 아는 PM과 직접 부딪혀본 PM, 그 차이를 만드는 6주가 될 거예요.
이번 PM 편에 이어 디자이너 편, 개발자 편도 시리즈로 준비하고 있으니 기대해주세요.
이론을 경험으로 바꾸는 6주, 지금 시작해보세요.
