PM은 대체 회사에서 뭘 할까?
주니어 PM 성장기 #3
"아직 PM에 대해서 스스로도 정확하게 정의하지 못했습니다."
PM의 꿈을 가지고 면접을 볼 때, 마지막 한마디로 항상 했던 말이다.
치기 어린 신입의 마지막 한마디를 긍정적으로 보았던 면접관이 있었고, 그렇지 않았던 면접관이 있었다.
다행히 지금 다니는 회사에서는 긍정적으로 봐주었고, PM이 무엇인지 제대로 알려주겠다는 대답까지 해주었다.
우선, PM은 Product Manager의 줄임말이다.
내 명함에는 '프로덕트 매니저'라고 적혀 있으며, 회사에서는 PM님이라고 불리고 있다.
PM 자체가 우리나라 말이 아니다 보니 회사마다 다른 의미로 사용되는 경우가 매우 많다.
따라서, 나는 지금 내가 회사에 가면 하고 있는 일을 기준으로 PM의 역할을 정의 내려보고자 한다.
PM은 조직의 두뇌다.
나는 SaaS에서 PM 업무를 하고 있다.
SaaS (Software-as-a-Service) : 서비스로서의 소프트웨어, 클라우드 애플리케이션과 기본 IT 인프라 및 플랫폼을 사용자에게 제공하는 클라우드 컴퓨팅 형태
SaaS의 구성원은 크게 PM, 개발자, 디자이너로 나뉜다.
개발자와 디자이너는 직무 이름에서 직관적으로 알 수 있는 역할을 한다.
개발자 : 프론트앤드와 백앤드로 나뉘어 서비스를 개발
디자이너 : 서비스의 UX와 UI를 디자인
이들과 함께하는 PM은 한국말로 말하자면 기획자에 가장 가깝다.
하지만, 기획자에 가까운 것이지 기획자와 동일한 업무를 하지는 않는다.
기획은 PM 혼자서 하는 것이 아니라, 개발자 디자이너와 함께 해야 하는 것이기 때문이다.
실제로 우리 회사에서는 서비스 정책을 결정하는 회의에 디자이너와 개발자가 모두 참석한다.
예를 들어, 공유 드라이브 관련 정책을 세운다고 가정해보자.
공유 드라이브 정책을 PM이 단독으로 결정하고 통보한다면 많은 문제가 발생할 수밖에 없다.
가령 PM은 공유 드라이브 간 파일 이동을 자유롭게 풀어두기로 결정했는데, 개발자 입장에서 개발 리소스가 과도하게 소요될 수 있고, 디자이너 입장에서 UI를 고려했을 때 공간 활용성이 떨어질 수도 있기 때문이다.
따라서, 사소한 정책이라도 PM, 개발자, 그리고 디자이너 간의 협의가 있어야만 정책을 효율적이고 빠르게 결정할 수 있다.
물론, 정책의 기본적인 틀은 PM이 결정하는 것이 맞다.
그렇기 때문에 기획자와 가까운 업무를 진행한다고 말했던 것이다.
앞선 예시를 다시 살펴보자.
공유 드라이브 정책에서 '드라이브 간 자유로운 파일 이동'은 PM의 머리에서 나온다.
드라이브 간 자유로운 파일 이동은 유저에게 매력적으로 느껴질 수 있고, 유사 서비스 사이에서 경쟁력을 확보할 수 있을 것이다.
이런 생각을 가지고 PM은 개발자와 디자이너에게 회의를 요청한다.
회의의 목적은 아래와 같다.
'내가 다음과 같은 정책을 세우려고 하는데, 여러분들과 함께 정책을 폴리싱하고자 합니다.'
사실, 정책의 아이디어나 생각의 시초는 PM의 단순한 감이다.
(그래서, 일부 회사에서는 관련 서비스 시장 구조를 구체적으로 파악하고 있는 PM을 선호하는 것이다.)
하지만, PM의 감으로 시작한 아이디어를 그냥 그대로 회의에 들고 들어가는 것은 매우 위험하다.
개발자와 디자이너에게 '다른 서비스도 그렇게 하던데요? 우리도 하면 좋겠죠!'라고 말하면 당연히 안된다.
만약 PM의 생각이 위 단계에서 멈췄다면 개발자나 디자이너가 진행을 거부했을 때 할 말이 없다.
정책이 빨리 결정되어야 배포도 빠르게 될 텐데, PM 이외의 다른 구성원들이 거부한다면 진행은 매우 어려워진다. (연차가 높은 PM이라면 그대로 밀어붙일 수도 있겠지만 그건 큰 문제다...)
그렇다면, 개발자와 디자이너에게 설득력 있는 회의를 진행하고 효율적인 협업을 진행하기 위해서 PM은 무엇을 준비해야 할까?
과정으로만 생각해보면 PM이 준비해야 할 내용은 매우 간단하다.
아이디어 > 경쟁 서비스 파악 > WHY? > 효용 > 결론
우선, 앞서 말했던 것처럼 감으로 아이디어를 도출한다.
경험을 바탕으로 아이디어를 제시해도 좋고, 새로운 아이디어를 제시해도 좋다.
다음 단계는 경쟁 서비스를 파악해야 한다.
내가 생각한 아이디어와 관련해서 경쟁 서비스는 어떤 정책과 구조로 진행되고 있는지 파악한다.
이때, 파악하는 서비스는 경쟁 서비스에만 국한되지 않아도 괜찮다.
생각한 아이디어와 관련된 정책을 제공하는 서비스는 많이 파악하면 파악할수록 좋다.
(정기 구독 정책을 세울 때, 넷플릭스와 밀리의 서재처럼 기본 서비스에는 유사한 점이 없더라도 '정기 구독'을 진행한다는 점에서 동시에 파악하면 도움이 된다.)
경쟁 서비스까지 파악을 완료했다면, 그다음이 가장 중요한 WHY? 단계이다.
아마, 파악한 각각의 서비스마다 조금씩 차이가 존재할 텐데, 차이가 '왜' 존재하는지 이유를 분석해내야 한다.
여기서 얼마나 정확하고 예리하게 분석하는지에 따라 PM의 역량이 갈린다고 생각한다.
예를 들어, 넷플릭스는 정기 구독 이전에 30일 무료 체험을 제공하는데, 밀리의 서재는 무료 체험 기간을 7일과 30일로 나누어 유저에게 선택하도록 한다.
이렇게 차이가 나는 이유에 대해서 넷플릭스의 상황과 밀리의 서재의 상황을 면밀하게 조사해야 한다.
가설을 미리 세우고 조사해도 괜찮고, 그냥 전체적으로 조사해도 무방하다고 생각한다.
해당 조사를 통해 왜 서로 다른 정책을 펼쳤는지 논리적으로 분석해낸다.
WHY? 단계에서 논리적인 분석을 마쳤다면, 초기 아이디어를 우리 서비스에 어떻게 적용할 것인지 다시 한번 생각하고 어떤 효용을 가져올 것인지 예측해야 한다.
쉽게 말해서, 넷플릭스처럼 30일 무료 체험 서비스를 제공하는 것이 더 큰 효용을 가져올 것인지, 아니면 밀리의 서재처럼 유저에게 기간을 선택하도록 하는 것이 더 큰 효용을 가져올 것인지 예측하는 것이다.
이 과정에서 초기 아이디어의 구조가 일부 변경될 수 있다. (아마 50% 이상이 변경될 것이다.)
앞선 모든 단계를 거쳤다면, 결론을 내리고 개발자, 디자이너와 함께 회의를 진행하면 된다.
이 과정을 봤을 때, PM의 역할은 조금은 명확해진다.
PM은 조직의 두뇌 역할을 한다.
마치 팔을 움직이는 데 있어 그 목적에 대해 두뇌가 이미 생각하고 있었던 것과 같다.
능력 있는 PM이란 개발자와 디자이너가 '왜 이 정책을 세워야 하죠?'라고 묻는다면, 탄탄한 논리력으로 이미 생각해둔 내용으로 답할 수 있는 자다.
내가 다니는 회사에서 PM은 이런 역할을 하고 있기 때문에
나는 회사에서 대부분의 시간을 팔짱을 낀 채 모니터만 하염없이 보고 있거나, 노트에 난잡하게 뭔가를 쓰며 보낸다.
다시 말하지만, WHY? 단계는 PM에게 있어 가장 중요하다고 생각한다.
정책에 따라 다르겠지만, 경쟁 서비스가 왜 그 정책을 채택했는지 알아내는 것은 대체로 매우 어렵다.
해당 서비스의 방향성과 시장 점유율은 기본이고 CEO의 경영 이념까지 고려해야 하기 때문이다.
그렇기 때문에 PM은 끊임없이 생각에 잠겨있어야 한다.
'왜 이렇게 진행했지?', '왜 최근에 정책을 바꿨을까?' 등에 대해서 고민하고 적절한 이유를 찾기 위함이다.
내가 회사에서 키보드에 손을 올리고 뭔가를 쓰고 있다면, 긴 고민 끝에 결론을 내리고 개발자와 디자이너에게 전달하기 위해 위키를 정리하고 있는 중일 것이다.
사실, 아직 입사한 지 한 달이 채 되지 않았기 때문에 내가 내린 PM의 역할은 정확하지 않을 수 있다.
그럼에도 불구하고 이 글을 정리하는 이유는 나중에 내가 업무에 더 많이 적응한 뒤에 이 글을 다시 봤을 때, 얼마나 더 성장해 있는지 파악할 수 있는 마일스톤을 남기기 위함이다.
다음 글에서는 이 글에의 PM이 준비해야 할 단계를 실제로 진행했던 내용을 정리해보고자 한다.
