PM은 어떤 일을 하는 사람이에요
안녕하세요 처음으로 브런치스토리에 글을 포스팅하네요. 원래는 다른 곳에서 지식을 정리하는 목적으로 글을 종종 쓰긴 했습니다. 이제는 지식을 정리하는 것뿐만 아니라 저만의 이야기를 담을 수 있는 글을 쓰려고 노력하겠습니다.
저는 원래 프론트엔드 개발자가 되기 위해 컴퓨터공학과, 부트캠프, 인턴을 거치면서 여러모로 준비를 많이 했습니다. 그 과정 속에서 팀원으로서 기획을 해보기도 하고, 팀장으로서 팀을 관리해보면서 프로덕트를 만드는 과정 속에서 개발이 아닌 또다른 재미를 느낀 부분이 많았어요. 기획 속에서는 내가 뭘 좋아하는지에 대해 탐구하기도 하고, 지금 우리가 살고 있는 곳에서 일어나는 문제를 알아보기도 하면서 어떠한 문제를 해결하면 좋을까라는 회의를 하면서 재밌다고 느꼈고 인문학적인 소양을 조금이나마 키우지 않았나 싶습니다. 그리고 팀을 관리하는 팀장으로는 사용자 경험뿐만 아니라 개발자 경험을 신경쓰기 위해 업무 자동화와 애자일한 프로세스를 도입하려고 했습니다. 운이 좋게 팀원들이 제가 정한 규칙에 맞게 잘 따라준 덕분에 팀이 좋은 방향으로 이끌어간다는 경험을 해서 성취감을 느꼈습니다.
개발이 아닌 부분에서 좋은 영향력을 끼칠 수 있는 직업을 알아보는 과정에서 PM (Product Manager)라는 직업에 대해 알게 되면서 PM과 관련된 포스트, 영상, 책을 접하면서 정리되지 않은 상태로 마구잡이로 머릿속에 넣는 시간을 가져보았습니다. 그래서 이제 머릿속에 넣어놨던 것들을 풀어헤치기 위해 포스트를 작성하게 되었습니다.
제가 생각하는 PM은 말이죠.
제가 수학교육을 전공을 하여서 무언가에 대한 정의를 딱 떨어지게 내리는 걸 좋아합니다. Product Manager에 있는 단어를 분리해서 살펴보겠습니다.
Product : 고객이 지닌 문제를 해결하는 제품이나 서비스
Manager : 어떠한 제품이나 서비스에 대한 개발, 운영, 개선 등 과정을 원활하게 도와주는 역할을 하는 직업
이를 종합해보면 Product Manager는 고객이 지닌 문제를 해결하는 제품이나 서비스를 개발, 운영, 개선 등의 과정을 원활하게 도와줄 수 있는 역할을 하는 직업이라고 정의를 내렸습니다.
PM으로 활동하신 분의 유튜브를 통해 정의를 보충해도 좋을 것 같습니다.
PM은 마치 영화 감독과 오케스트라 지휘자와 같이 각기 다른 역할을 가진 사람들을 한 가지 목표를 위해 이끄는 사람이라고 표현하기도 했습니다.
추가적으로 PM에 대해 알아보는 과정에서 읽어본 포스트 중에 PM과 혼동되는 직업들에 대한 내용이 있었는데 이를 비교해보도록 하겠습니다.
PM(Product Manager)
PO(Product Owner)
서비스 기획자
PM (Product Manager)는 제품의 전체 생애 주기를 관리하며, 시장 조사, 사용자 요구 분석, 제품 전략 수립 등을 담당합니다. PO (Product Owner)는 애자일 개발 환경에서 주로 활동하며, 제품 백로그를 관리하고, 개발 팀과의 소통을 통해 제품의 비전을 구체화합니다. 서비스 기획자는 서비스의 기획 및 설계, 사용자 경험(UX) 개선을 중심으로 활동하며, 특정 서비스의 방향성을 설정하고 운영 방안을 마련합니다.
세 가지 직무에서 비슷한 듯 아닌 듯해보이네요. 이걸 보면 아직 모르는 게 많나봅니다.
PM으로 업무 프로세스, 역량, 일과에 대해 알아보도록 하겠습니다. 우선 PM의 업무 프로세스에 대해 알아보면 생각보다 방대하다는 점에서 놀랍니다. 업무 프로세스는 크게 Pre-Production, Production, Released 단계로 구분지을 수 있습니다. Pre-Production 단계에서 제품이나 서비스를 개발하기 전을 의미하며, 문제를 정의하고 리서치를 통해 타당성, 사업성, 개발 실현가능성에 대한 검토를 합니다. 그 후에 제품 개발 단계로 넘어갈 수 있도록 스토리보드, 필요 스펙, 화면 설계에 관한 자료를 문서화하여야 합니다. Production 단계에서는 제품이나 서비스를 개발하는 단계에서 한정적인 리소스를 알맞게 할당하고 일정 조율을 합니다. 개발하는 과정 속에서 문제없이 진행되는지 체크하기 위해 데일리 스크럼을 사용하기도 합니다. 그리고 개발한 것이 원래 의도와 맞게 만들어지거나 사용될 수 있는지 품질 보증을 하는 QA 단계를 거쳐 안정성을 체크하는 것도 PM이 관여해야 하는 부분입니다. 마지막으로 Released 단계에서는 제품이나 서비스가 출시된 이후의 단계를 의미합니다. 여기서 마케팅과 운영 과정이 들어갑니다. 널리 알리고 현재 문제가 되고 있는 부분을 개선하기 위해 VoC, 인터뷰 등을 이용합니다.
이렇게 수많은 과정을 PM이 관여하는 게 상당히 난도가 높다고 생각했고, 한편으로 배울 점이 무수하게 많다는 것을 느꼈습니다. PM은 Specialist보다는 Generalist 이라는 표현에 공감하였습니다.
PM이 생각해야 할 업무 분야로 크게 사용자 경험, 기술, 사업 등을 고려하면 좋다고 했습니다.
PM이 갖춰야 하는 역량이 많지만, 그 중에서 중요한 것은 '문제 정의', '문제 해결', '커뮤니케이션'입니다.
문제를 정의하기 위해서 리서치, 타당성 검토, 사업성 검토 등을 통해 데이터를 수립합니다. 모아진 자료를 통해 어떠한 가설을 수립하게 되고 그 가설을 검증하기 위해 기획, 설계, 관리, 개선 등의 과정이 진행되고 데이터를 통해 가설을 증명할 수 있어야 합니다.
PM이 하는 업무를 자세하게 이미지와 링크에 있는 유튜브를 통해 살펴볼 수 있을 것 같습니다.
출처 [https://www.youtube.com/watch?v=1XlV1AJbXI8&t=616s]
- 개발자와 디자이너의 업무 방식을 존중하고 효율적으로 일할 수 있도록 돕는다.
- 개발자와 디자이너가 절차상 필요한 존재라고 치부하지 않고, 중요한 파트너로 대한다.
- 개발자와 디자이너가 제대로 일할 수 있도록 충분한 시간을 준다.
- 프로젝트 초반부터 개발자와 디자이너가 참여하도록 한다.
- 전문가에게 권한을 위임할 줄 안다.
- 흠잡을 데 없이 정리가 잘 되었고, 커뮤니케이션이 일관적이고 명확하다.
- 팀원의 의견을 경청하고, 다양한 의견을 취합하여 실행 방안으로 만들어 낼 수 있다.
- 오버커뮤니케이션이 언더커뮤니케이션보다 낫다.
- 팀이 지금 뭘 하고 있고, 다음에 뭘 해야 하는지 계속해서 명확하게 한다.
- 중요한 것에 집중할 줄 안다.
- 무자비할 정도로 불필요한 것을 걸러낸다.
- 업무 범위 조정과 실험을 통해서 리스크를 관리한다
- 사용자와 비즈니스 결과를 최우선으로 고려하여 일관적이고 투명한 결정을 내린다.
- 자신의 자존심이나 명성을 위한 결정이 아니라 소비자, 비즈니스, 팀을 위한 결정을 한다.
- 데이터에 기반한 결정을 내릴 줄 안다.
- 디자인 그리고 계랑/정성적 리서치 방법에 대해 깊이 이해한다.
- 제품에 대한 결정과 기술적인 결정을 구분해서 이해할 수 있다.
- 어떤 결정을 내릴 때 기술적으로 무엇을 의미하고 오래 걸릴지 이해하려고 노력한다.
- 데이터를 제대로 사용할 줄 알고, 데이터를 이해하는 사람과 협업할 수 있다.
- "왜" 이 일을 해야하는지 그 비전과 목표를 제대로 설명할 수 있다.
- 지속해서 사용자, 경쟁사, 시장 조사를 하고 이를 제품에 반영한다.
- 해결책보다는 문제가 무엇인지에 대해서 더 깊이 고민한다.
- 경영진에게서 오는 압박을 잘 수용하고 이를 해결하기 위해 어떤 업무를 해야하는지 알고있다.
- 제품을 더 좋게 만들기 위해서 회사 경영진에 이의를 제기할 수 있다.
- 회사 문제로 디자이너와 개발자가 힘들어하면 이를 해결하기 위해 노력한다.
- 피드백을 사적인 감정으로 받아들이지 않는다.
- 자기 아이디어와 사랑에 빠지지 않는다.
- 미팅에 빠지지 않는다. 팀원이 답변을 요구하면, 제때 답변을 가져온다.
출처 [https://www.youtube.com/watch?v=U3JhQlTFxWw&t=2s]