PM 직무 알아보기
PM은 제너럴리스트를 위한 직무일까?
제너럴하다고 평범한 건 아니다
제너럴리스트의 고민
이른바 제너럴리스트 generalist는 특정 분야의 전문가에 비해 인식 혹은 대우가 아무래도 부족하다는 생각을 종종 한다. 이는 비단 "이런 일 저런 일 다 한다"라고 하는 스타트업에서 재직자만의 고민 혹은 불평은 아닌 것 같다. 공기업과 사기업 그리고 규모를 막론하고, 대부분의 일반 사무직이라면 스스로를 제너럴리스트라고 표현하거나 혹은 '저도 제가 무슨 일하는지 모르겠어요'라며 한탄한다.
-
"저는 전문성이 없어요."
"가르쳐주면 아무나 다 할 수 있어요."
"이 일 저 일 다 해서, 제가 뭐 하는 사람인지 모르겠어요 저도."
"잡부죠 그냥, 잡부."
학창 시절부터 대학에 이르기까지 우리의 교육은 모두 전인(全人) 교육이다. 그러나 대학 졸업장을 따는 순간부터는 급작스레 (준) 전문가가 되라고 한다. 좋은 대학에 가려면 국어, 수학, 영어, 과학, 사회, 음악, 체육, 미술까지 모두 잘하라고 하며, 대학은 이중 전공과 부전공, 필수 교양을 요구하지만 채용 시점이 되면 어떤 전문가가 되겠느냐고 묻는다. 평생을 제너럴리스트로 교육하지만 그 교육이 끝난 시점엔 특정 분야의 전문가가 되어있기를 바란다. 타인에게도, 그리고 스스로에게도.
그래서 늘 우리는 정체도 모호한 '전문성'이라는 것에 늘 메말라있다. 퇴근 후엔 자격증, 학위, 특정 기술을 탐색한다. 그것만 있으면 커리어의 많은 고민이 해결될 거라고 믿으며. 그것만 따면 성공 내지는 더 많은 보상이 뒤따를 거라는 기대도 하면서.
제너럴리스트로서의 PM
몇 해 전부터 개발자 구인 열풍이 불고 있는 가운데, 예상한 것처럼 PM 직군에 대한 수요도 늘고 있는 걸 체감한다. 당연한 수순이었다. 만들 사람이 있으면, 조율하거나 관리할 사람도 있어야 하니까.
공사현장으로 이해하면 쉽다. 10명의 작업자가 있으면, 감리도 1명 필요한 법이다. 아무리 잘 만드는 사람을 모아놔도, 무엇을 어떻게 언제까지 만들지를 논의하고 조율할 사람도 필요하다. 동네 가게가 아니고서야 지배인이 없는 주방, 감리가 없는 시공현장, 팀장이 없는 팀은 없다. 그래서 개발자가 많아지면 프로덕트 매니저도, 디자이너도, 데이터 분석가도 함께 필요해진다.
그러나 그 가운데 PM만 오로지 '제너럴리스트'다. 구체적인 기술 또는 도구를 필요로 하지 않기에, 그리고 눈에 보이는 결과물을 내놓지 않기에 전문가로 불리지 않는다. 서비스 기획을 처음 접하고, 또 PM으로의 직무 전환을 알아보던 당시 가장 자주 접했던 후기 혹은 경험담 역시 상당수는 '제너럴리스트'로서의 고민이었다.
현재 일하는 회사에서, 대표님과 점심 식사 자리에서도 이런 말들이 농담처럼 오고 갔다. "옆에 있는 디자이너님이 가설도 세우고, 문제 정의도 하면 기획자는 필요 없어질 수도 있어요. 기획자란 게 그런 거예요."
“옆에 있는 디자이너님이 가설도 세우고, 문제 정의도 하면 PM, 기획자는 필요 없어질 수도 있어요. 기획자란 게 그런 거예요.”
PM이 하는 일
과연 그럴까. 애초에 PM이 하는 일은 무엇이길래 그건 디자이너도 할 수 있을까. 물론 이론상 디자이너 출신이 아닌 PM 역시 디자인을 할 수 있다. 툴은 배우면 그만이니까. 문제는 그런 식이라면, 아주 소수의 도제식 직업을 제외하고는 모든 일이 남들이 다 할 수 있다. 배우면 되니까. 세상에 배워서도 할 수 없는 일이란 없다.
그렇다면 핵심은 과연 그것이 '단기간에 배울 수 있는' 일, 혹은 '구조화된 형식으로 단기간에 가르칠 수 있는' 일이 맞느냐는 것이다. PM의 일을 누군가에게 단기간에 가르칠 수 있을 것인가?
“모든 일은 배우면 누구나 할 수 있다.
문제는 단기간에 배우거나 가르칠 수 있는 일이 맞느냐는 것이다.”
이미 온라인엔 프로덕트 매니저의 역할, 혹은 필요 소양과 능력에 대한 아티클들이 차고 넘친다. 문장과 어휘는 다소 다르지만, 결국 PM이 제너럴리스트라는 건 동일하게 진단한다. 이것도 잘하고, 저것도 잘해야 한다.
· Product managers for the digital world
· What It Takes to Become a Great Product Manager
이밖에도 프로덕트 매니저의 필요 소양과 역량, 역할에 대한 아티클이 다양하다.
나 역시 PM이라는 직무로 정식으로 전환한지는 이제 4개월밖에 되지 않았지만, PM으로서 아래의 일들을 해야 한다는 걸 체감하고 있다.
1. 비즈니스 이해
PM은 제품을 성장시키는 담당자다. 그리고 제품을 성장시키려면, 결국 이 제품이 몸담고 있는 비즈니스의 영역과 구조가 무엇인지 이해해야 한다.
- 우리는 어떤 비즈니스 모델로 수익을 창출하는가?
- 어떤 고객이 핵심 고객인가?
- 제품과 핵심 지표가 성장하기 위한 구조, 전략, 전술은 무엇인가?
2. 고객 이해
PM은 제품을 통해 고객의 문제 해결을 돕는 담당자다. 고객의 문제 해결을 도우려면, 고객이 누구인지, 그들이 겪는 문제는 무엇인지 이해해야 한다.
- 우리 제품의 고객은 누구인가?
- 그들은 어떤 문제를 겪고 있는가?
- 그들이 그 문제를 겪는 맥락과 배경은 무엇인가?
- 그들은 현재 그 문제를 어디서 어떻게 해결하고 있는가?
3. 제품의 이해
PM은 고객의 문제를 제품의 운영, 구현을 통해 해결한다. 고객의 문제 해결을 도우려면, 그걸 돕는 수단인 제품에 대해 이해해야 한다.
- 제품의 기존 정책 (우리 제품이 어떤 기능을 어떻게 제공하는지)
- 제품 관련 DB 구조 및 API에 대한 이해 (우리 제품이 어떤 데이터를 어떻게 주고받는지)
- 그렇게 구현, 운영되는 배경과 맥락의 이해
4. 제품의 기획과 제작 (좁은 의미의 서비스 기획)
마찬가지로 고객의 문제 해결을 도우려면, 새로운 제품 혹은 기존 제품의 개선 등이 필요하다. 이를 위해선 제품을 기획하고 제작하는 전 과정을 이해하고 총괄해야 한다.
- 어떤 기능을 제공할 것인가?
- 어디에 제공할 것인가? (퍼널 등)
- 언제 제공할 것인가? (프로젝트 우선순위, 론칭 시점 등)
- 어떻게 제공할 것인가? (세부적인 스펙 결정)
- 이를 표현하고 전달하기 위한 문서 작업 (스토리보드, 유저 스토리, IA, 정책문서, TC 등)
5. 데이터 문해력 data literacy 또는 분석 툴
PM은 제품이 의도한 대로 고객에게 전달되어 문제를 해결하고 있는지, 그 대가로 우리 제품이 성장하고 있는지 이해하고, 문제점 또는 개선점을 발굴하고 분석해야 한다.
- 기본적인 통계 이해도
- A/B 테스트의 이해
- 데이터 분석가가 없다면 엑셀을 활용한 분석, SQL을 통한 추출 정도
6. 가설 기반의 문제 정의 능력과 언어 능력
PM은 고객의 문제를 해결하기 위해 팀과 프로덕트가 해결해야 할 문제를 정의하고 이를 과제로 만들어내고 진행을 조율한다. 이를 위해선 무엇보다도 문제를 정의하고 가설을 세우고 수정할 수 있는 논리력이 필요하다.
- 문제 정의 능력과 가설 설정과 수정 능력
- 구두/서면으로 이를 전달할 수 있는 언어 능력
7. 커뮤니케이션
PM은 결코 혼자서 문제를 해결하지 못한다. 그렇기에 이를 관련된 이들과 공유하고, 설득하고 조율하기 위한 커뮤니케이션 능력이 필수다.
- 어떤 문제를 풀 것인가 (혹은 풀지 않을 것인가)에 대한 설득
- 이 문제를 지금/먼저 혹은 나중에 풀어야 하는 이유에 대한 설득
- 팀원의 제안, 산출물이 문제를 풀 수 있을 것인지, 의도에 부합하는지에 대한 피드백
- 프로젝트 및 이슈 사항에 대한 유관 부서와의 공유, 논의, 협조
- 진행 상황에 대한 보고 및 공유
8. 리더십
PM은 '직책'은 아니지만 그럼에도 팀에서 일종의 리더 혹은 중간관리자와 유사한 역할을 하게 된다. 팀의 성과가 프로덕트의 성과이자 PM의 성과이고, 프로덕트의 성공이 팀의 성공이기도 하다. 그래서 팀원의 이해관계, 애로사항 등을 이해하고 이를 조율하고 지원하여 프로덕트와 팀의 성공으로 이끌기 위한 노력이 필요하다.
9. 멘탈
프로덕트에 문제가 생기면 PM은 가장 먼저 소환되는 사람 중 한 명이다. 고객의 불만과, 이를 가장 먼저 대응하는 VOC 담당자의 문의와, 관련 운영 담당자의 볼멘소리를 감당해야 한다. 그러면서도 팀의 구성원들이 이에 직접적으로 노출되지 않도록 우산 역할을 해야 하기도 한다. 그래서 PM은 멘탈이 좋아야 한다.
제너럴하다고 평범한 건 아니다
위의 능력 중 그 어느 것도 '전문' 영역은 아니다. 국가 공인 자격증이 발급되거나, 학위로 증명할 수 있는 일도 아니다. 특정 도구로 보여줄 수 있는 일도 아니고, 깃허브에 소스 코드를 올리는 것처럼 문서를 올려둘 수도 없는 일이다.
구조화된 것은 쉽게 증명할 수 있지만, 따라 하는 방법이 정해져 있다. 구조화되지 않은 것은 증명하기 어렵지만 따라 하기도 어렵다. 누군가가 목차를 알려주고, 내용을 설명해 주고, 기출문제 풀이나 해설 강의를 해주지 않으니까. 오로지 자신의 학습력과 논리력, 그리고 이를 이어가게 할 성실성, 의지 혹은 끈기를 통해서만 천천히 쌓을 수 있는 능력이다.
그리고 이런 학습력과 논리력, 성실성과 의지는 어떤 식으로도 배우거나 따라 할 수 없는 영역이다. 어쩌면 이렇게 '제너럴'한 영역의 것들을 일정 수준 이상 하고 있다는 것 자체가 하나의 능력인 건 아닐까?
그러니 '제너럴리스트'로써 일을 하는 모두가, 특정 기술을 갖고 있지 않다고 해서 스스로를 낮게 보진 않았으면 한다.
“학습력과 논리력, 그리고 이를 이어가게 할 성실성, 의지 혹은
끈기를 통해서만 천천히 쌓을 수 있는 능력이다. 이것 역시 하나의 전문적인 능력인 건 아닐까?”
-
*이 콘텐츠의 원문은 플래터 님의 브런치입니다. 제로베이스 미디어에서 더욱 다양한 필진의 인사이트 콘텐츠를 만나보세요.
*해당 콘텐츠의 저작권은 원문 작성자에게 있으며, 무단 전재, 복사 및 배포 등을 금지합니다.
추천 컨텐츠