초보 PM이, PM이 되고 싶은 꿈나무 후배들에게
IT 서비스 기획, PM... 도대체 '무슨 일을 하는 사람' 일까?
'그럼 본인을 소개할 때 몇년차라고 이야기하세요?'
'PM이라는 직군으로 공식적으로 일한 것은 그렇게 오래되지 않았으니 저는 1년 차라고 이야기해요. 조금 있으면 2년 차가 되겠네요'
AWS (Amazon Web Services)에서 약 7개월간 인턴을 하고, 1년 조금 넘는 기간 동안 아무것도 모른 채로 창업에 도전했다가, AI를 공부하고 싶어서 대학 연구실에서 계약 보조연구원으로 일하며 논문을 준비했는데, '좀 더 유저와 서비스 관점에서 기술을 바라보고 싶다'는 생각에 결국 PM이 되기로 마음먹었다.
창업을 도전하던 중, 기존 아이템을 포기하고 '당장 수익보다는 실제로 사람들이 결핍을 느끼는 무언가를 발로 뛰어서 해소해보자!'라는 생각에, 약 1년 동안 '파인드'라는 커리어 네트워크를 운영했었는데, 실무나 현직에 대해 알 방법이 많지 않은 대학생들에게 최대한 많은 선배들을 만나게 해 주고. 이들의 이야기를 들려주자는 목표에서 인터뷰나 세션 등을 진행했었다.
공식적으로 'PM'이 되어 일하게 되면서 나도 배우고 느끼는 점들이 참 많고, 막연하게 IT 서비스의 PM이 되고 싶다고 생각했을 적에 답답하고 궁금하던 것들이 참 많았던 것 같아서 한 번씩 PM 꿈나무들을 위해 글을 남겨보기로 했다. 비록 팀원들 각자의 사정으로 공식적인 운영은 22년 1월 마무리하게 되었지만, 파인드 채널을 통해서도, PM이 되고픈 후배들에게 도움을 줄 수 있으면 하는 바람이다.
앞으로 내가 적게 될 글을 숙련된 PM이 노하우나 업계의 지식을 공유하기 위한 글이라기보다는, 나조차도 초보인 PM 이 몰랐던 것들을 배워가고, 느끼며 알아가는 과정에 대한 기록이다.
그래서 우선, PM은 뭘 하는 사람일까?
그래서, PM은 뭘 하는 사람일까? PM을 꿈꾸는 사람들이라면 (적어도 대학생이거나, 다른 직군에서 일을 하던 사람들이라면) IT 업계에서 흔히 말하는 PM / PO 들에 대해서 구체적으로 정의하기 어려울 것이라 생각한다. 사실 나조차도 그렇다. 그런데, 나는 실무 경력이 그렇게 다양하지 않은 주니어 PM이라 그렇다 해도, 실무를 하면서 경력이 매우 많은 시니어 PM/PO분들도 가끔 이 직군의 업무 범위와 정의에 대해 혼란스러워하시는 경우를 종종 보았다.
물론 PM/PO에 대해 매우 잘 설명해놓은 책들, 또는 인터뷰나 강연들을 찾아볼 수 있다. PM/PO를 꿈꾸는 사람들이라면 이런 자료들을 많이 찾아보았을 것이다. 조금씩 차이가 있지만 대체로 '프로덕트의 방향성에 대해 판단하고 결정하며, 현황에 대해 분석하고 책임을 지는 사람' 정도로 설명이 되는 듯하다. (사람마다 의견은 다르겠지만, PM이 되고 싶어 준비하던 당시에 나는 이 정도로 생각했다.) 그런데, 아이러니하게도 이렇게만 생각하고 실제로 PM 실무에 투입이 되게 된다면 적잖이 당황할 수도 있다고 생각한다. 최근에는 회사들마다, 그리고 어떤 경우는 회사에서도 서비스 조직마다 PM의 정의가 조금씩 다를 수 있기 때문이다.
3가지 키워드
우선, 요즘 많은 IT 서비스에서 이야기하는 PM의 영역에 걸쳐있는 3가지 키워드가 있다고 생각한다.
기획 / 구축
방향성 및 의사결정
운영
일반적으로 이야기하는, 또 많이 생각하는 PM의 정의는 주로 2번째에 많이 초점을 맞추고 있는 것 같다. 그런데 대부분의 경우는 실제로 위 세 가지 키워드에 주로 관여하게 되고, 회사에 따라서 어떤 부분에 PM이 집중하는지에 대한 차이가 꽤 있다고 느꼈다.
1. 기획 업무
기획 및 구축 업무는, 전통적으로 '서비스 기획자'라고 불리던 직군의 역할이다. 그런데 정작 미국에서는 '기획자'라는 직군을 찾아보기 어렵다는 이야기를 많이 들었다. (실제로 영문 이력서를 쓰다 보면 '기획자'를 뭐라고 써야 하지?라는 궁금증이 들 때가 있을 것이다.) 실제로 미국에서는 'Product Manager' 또는 'Product Designer'가 서비스 기획업무를 하는 경우가 많았다고 한다. 우리나라에서도 최근엔 'Product Manager'라는 이름의 직군이 '서비스 기획 / 구축' 업무를 진행하는 경우가 많다. 말 그대로 서비스 또는 기능의 '기획 문서'를 작성하고, 디자인에 이어 개발이 진행될 수 있도록 하는 역할이다. 이 과정에서 디자이너들, 개발자들과 수없이 소통하게 된다. 실제 기획이 어떻게 진행되는지에 대해서는 다른 포스트에서 자세히 다뤄보겠다.
2. 방향성 및 의사결정
방향성 및 의사결정은, 서비스 또는 기능과 관련된 지표를 분석하고, 테스트하며 실제로 담당한 서비스 / 기능이 어떻게 발전되어야 하는지, 유저에게 가치가 제대로 전달되고 있는지를 파악하는 역할이다. 사실 이 역할은 기획 업무와 뗄 수 없는 관계에 있다고 생각한다. 예를 들어 서비스에 새로운 로그인/가입 수단을 추가하는 업무를 한다고 가정해보자. 이를 '기획'만 한다면 유저가 로그인하는 방식이나 이 수단으로 가입된 회원 정보에 대한 정책 등을 구체적으로 정의한 기획 문서를 작성한다. 그런데 기능이 '어떤 식으로' 기획되는지 어떤 기준으로 결정해야 할까?
이때 기준이 되는 것이 바로 목표와, 데이터이다. 새로운 가입수단 추가를 통해서 가입자를 늘리는 것이 목표라면 유저가 더 쉽고 빠르게 가입할 수 있는 방식으로 기획해야 할 것이다. 더 쉽고 빠르게 가입할 수 있는 방식을 파악하기 위해 PM은, 현재 가입수단들의 지표를 분석하고, 지금 가입수단에 존재하는 허들을 찾아야 한다 - 어느 지점에서 유저가 많이 이탈할까? 어느 지점에서 필요 이상으로 많은 시간을 쓰고 있을까?. 실제로 개발이 완료된 이후에도 지속적으로 지표를 보며 목표가 제대로 이루어져 있는지, 유저들에게 어떤 영향을 미치는지 파악해 이어질 행동을 결정해야 한다.
3. 운영
마지막으로 운영에 대한 부분은, 앞의 두 가지와 다르게 회사나 조직에 따라서 PM이 깊게 관여를 하는 경우도, 아닌 경우도 있다고 생각한다. 서비스의 '운영'은 '방향성 결정'과는 조금 다른 이야기이다. '만들어진 서비스를 유저들이 사용하면서 발생하는 이슈들, 불편함 등을 어떻게 해소할 것인가?'에 대한 영역이다. 단편적으로는 서비스나 기능에 대한 유저들의 CS (Customer Service - 유저들이 고객센터에 도움을 요청하는 부분) 처리부터, 지속적으로 서비를 운영하기 위해 필요한 것들 (이벤트 진행, 고객 관리, 보상 지급 등)을 포함한다.
'운영' 이 PM의 업무 범위에 포함되는가? 에 대해서는 회사 마다도 차이가 있다고 생각하지만, '운영'을 PM이 깊게 고려해야 하는가? 에 대해서는 대부분의 경우 맞다고 생각한다. 운영에도 내부 리소스 (시간, 비용, 인력 등...) 이 당연히 들어가고, 서비스를 지속하는 한 이러한 운영 리소스는 불가피하게 발생한다. 따라서 운영을 효율적으로 처리하기 위해서 '기능 개발'로 이어지는 경우가 많다. 예를 들어서, 어떤 서비스에서 매달 이벤트를 통해 당첨자들에게 보상을 지급한다고 가정해보자. 운영 업무를 담당하는 팀 (운영팀이 따로 있거나, 보통 비즈니스 성격의 조직에서 이러한 업무를 하게 된다)은 매달 이벤트 참여자들의 정보를 받아서 엑셀로 정리한 뒤, 이메일을 통해 유저들에게 당첨 사실을 공지한다. 혹시 휴먼 에러 (사람의 실수로 발생하는 오류)가 일어나면 이에 대한 고객의 불만까지 응대한다.
이를 더 효율적으로 처리할 수 있는 방법은, 서비스 운영자들이 사용할 수 있는 어드민 (관리자) 기능을 만드는 것이다. 자동으로 전체 유저 목록을 불러와서, 조건에 충족하는 유저들을 당첨자로 설정하고, 알아서 당첨 정보를 공지하고 보상까지 지급하는 기능을 탑재한 설정 페이지를 만들면 이러한 업무를 간단히 처리할 수 있다. 여기서 PM이 하게 되는 역할은, 어드민을 개발하는 데에 들어가는 리소스와, 현재 운영에 소요되는 리소스를 비교했을 때 어떤 것이 더 소모적인가를 판단하게 된다. 만일 어드민을 만드는 것이 운영에 대한 효율을 크게 높일 수 있다 판단하면 다시 위의 1번으로 돌아가 어드민 기능을 기획하고, 이에 대한 지표를 바탕으로 기능의 범위를 좁힌다.
PM이 되고 싶은 꿈나무들에게
실제로 회사와 조직마다 위의 세 가지중 'PM' 이 실제로 어떤 업무를 수행하게 되는지에 대한 차이가 있는 듯하다. 어떤 경우는 PM이 2번에 더 집중하고, 1번은 '프로덕트 디자이너' (혹은 UX 디자이너)가 더 많은 부분을 처리하는 경우도 있다고 들었다. 내가 첫 번째 경험한 회사에서는 3번의 경우 아예 운영팀 따로 있고, 운영상 필요한 부분의 개발 요청을 PM에게 전달했었다.
이직을 할 때 이런 질문을 받았었다: '본인의 정체성은 어떤 부분에 있어서 강점을 가지는 PM이라고 생각하나요? / 기획 구축 업무도 실제로 진행을 했었나요?' 이 질문을 받고 실제로 현직에서도 PM의 역할과 업무 범위가 굉장히 다양하다는 점을 느꼈다. 그렇기 때문에, 관심 있는 많은 기업들의 PM채용공고와 Job Description을 유심히 살펴보기를 권장한다. Job Description 에는 상세하게 해당 조직의 PM 이 실무에서 수행하는 업무 범위를 정의해놓기 마련이니까. 그리고, 나는 어떤 부분에 강점을 가질 수 있을지 한 번씩 고민해본다면 실제 PM이 되어 실무를 하며 도움이 될 듯싶다. 실제로 함께 일해본 많은 분들도 촘촘하고 디테일하게 기획을 잘하시는 분들이 있는가 하면, 데이터와 지표 분석에 더 큰 강점을 보이시는 분들도 계셨다.
