본문 바로가기

우피클

PM이 뭐 하는 사람이야?

우피클은 무려 1주차 오리엔테이션부터 과제가 있었다. 

1. 프로젝트 매니저가 한다고 생각한 일.

2. 롤모델로 삼고 싶은 여성 업계 현직자 소개.

 

솔직히 내가 가진 PM에 대한 인상은 Project Manager, Product Manager, Product Owner 친구, 서비스 기획자… 이런 직업들이 아닐까 하는 두루뭉실한 생각이 있었다. 그래서 해당 채용공고를 찾아서 직무를 정리해봤다. 내가 생각을 정리하는 것도 좋지만 구직 시장에서 어떻게 이 직종을 정의하고 사람들을 뽑는지 그들의 언어를 알고 싶었기 때문이다. 같은 일이어도 아 다르고 어 다르다고, 어떻게 표현하는 지 살펴볼 수 있었다.

 

예전부터 트위터에서 팔로잉해서 보고 있던 두 분

 

롤모델로 삼고 싶은 현직자 분은 두 분을 소개했다. 모두 트위터에서 오랜기간 동안 팔로잉하며 보고 계신 분들로 꾸준히 SNS에서 해당 업계 소식을 말해주시는 분들이다. 개복치지망생 (@sheispuzzled) 님은 오늘부터 프로덕트 매니저 라는 전자책의 저자시다. 이 책으로 프로덕트 매니저란걸 처음 알았었고, 이론편과 실전편으로 나눠진 내용이 정말 알차다. minieetea  (@minieetea) 님은 배민의 서비스 기획자로 일하고 계신 분이다. 블로그에 종종 쓰시는 글을 읽었는데 회사 내의 서비스의 속사정도 자세히 써주셔서 어떻게 돌아가는지 파악할 수 있다. 

다른 피클분들이 소개해준 현직자 분들 중에는 처음 알게된 사람들이 많았다. 그 분들의 위치와 역할들을 보면서 더 넓은 시야를 가져야 겠다고 생각했다.


 

프로덕트 매니저는 4WH (Who, What, When, Why, How)를 하는 사람이다. 4WH는 다음과 같다.

[왜] 우리는 이 일을 하는가? - 비전

우리는 [무슨 일]을 할 것인가? - 전략

우리는 [누굴 위해] 이 일을 하는가 - 타겟

우리는 [언제] 배포할 것인가 - 로드맵

우리는 이 일을 [어떻게] 할 것인가 - 기능명세

 

회사마다 사정이 다르기 때문에 처음부터 이 다섯개를 잡고 갈 수는 없다고 한다. 주로 얘기하는 것은 [타겟]과 [기능명세]이다.

 

스프린트는 애자일에서 쓰는 방법으로 하나의 호흡이며 배포가 하나의 분기점이라 할 수 있다.

무엇을 만들까? - 어떻게 만들까? 만들자! - 잘 만들었나

이 단계가 스프린트이며 이를 계속 반복하는 것이 PM의 업무다. (끊임 없는 스프린트의 굴레…)

 

무엇을 만들까? 단계에서는

사용자의 문제와 제품에 대한 내외부 이해관계자의 요구사항을 먼저 파악해야 한다. 파악하는 범위는 사용자에게 나가는 서비스 뿐만 아니라 어드민과 툴까지 제품으로 묶어서 생각해야 하고 백로그(=backlog, 일의 창고) 형태로 관리 한다. 그리고 해결 방법과 요구사항의 우선순위를 정해야 한다. 마지막으로 가장 중요한 것은 [정확하게 뭘 하고 싶은지] 기획서의 *사용자의 언어*로 정리하는 것이다. 하고 싶은 게 정확한지 뭔지 말해야 하고, 커뮤니케이션을 못 하면 배포도 못 한다. 그래서 PM의 기본 소양 중에서 커뮤니케이션 스킬이 있나보다.

 

어떻게 만들까? 단계에서는

사용자가 어떤 형태로 이 기능을 만날지 결정해서 디자인을 해야하고, 전달하고자 하는 가치와 형태를 효과적으로 구현하는 것을 목적으로 개발을 해야한다. 그리고 PM은 계속 이슈사항들을 서비스 유관부서와 검토해야 하는데 때로는 법률과 관련한 이슈도 체크해야 한다.

 

만들자! 단계에서는

기능 명세에 대해 서로 다르게 이해할 수 있으니 하나로 맞춰야하고, 그 후에는 진짜 의도한 대로 만들었는지 기능 명세를 충족했는지 출시 이전에 QA를 진행한다. 이 때 QA 전담 부서가 없는 조직은 PM이 직접 진행한다…출시(=배포) 시에는 앱스토어에 업데이트 일지를 PM이 작성하는 경우도 있다. 

 

마지막으로 잘 만들었나? 단계에서는

출시된 제품의 반응을 살피고 데이터를 분석하며 회고를 진행하기도 한다. 이 때, 사용자들의 마음을 가장 잘 알 수 있는 방법 중 하나가 데이터 분석이다.

 

사실 서비스 기획자, 프로덕트 매니저, 프로덕트 오너 같은 호명은 중요하지 않다. PM은 도메인 지식에 특화된 사람이라고 보면 되고, PO는 전달 받아서 제품을 만드는 사람이라고 보면 된다. 서비스 기획자는 제품의 ‘완성’을 위해 일하며 프로덕트 매니저는 제품의 ‘성공’을 위해 일한다. 제품의 완성은 디테일을 중시하고 의도한 대로 가는지 QA도 열심히하고 통계지표도 보는 것이라면 제품의 성공은 완성은 누군가가 할 테니 우리가 관리하는 지표에 따라 의사결정은 이렇게 할거고, 투자는 이렇게 할 것이다 라고 보면 된다. 하지만 둘 다 위계는 중요하지 않다. 그리고 주니어 입장에서는 성공 보다는 완성이 중요하다. 왜냐하면 완성을 해봐야 성공으로 갈 수 있기 때문이다.

 

PM이 할 일은 많지만 나는 능히 할 수 있다!

나는 어떤 PM이 되어야 할까?

 

출처 : https://www.ravi-mehta.com/product-manager-roles/

 

이 그래프는 PM이 갖춰야 하는 기본 스킬들을 나타냈다. 시계 방향에서부터 고객인사이트(데이터 활용, 사용자 피드백 수렴, 사용자 경험 설계), 제품 전략(비즈니스 오너십, 제품 비전과 로드맵, 전략적 임팩트), 사람 영향력(이해관계자 관리, 팀 리더십, 상향관리), 제품구현(기능명세, 과제실행, 품질향상)이다.

 

여기서 상향관리는 나의 위에 있는 의사결정권자에게 챌린지를 계속 거는 것이라고 설명해주셨는데… 아직 그런 일을 해본적 그런지 잘 모르겠다. 어떤 챌린지를 거는 걸까.

 

 

주니어 PM의 역할이 APM이라고 보면 된다. APM이 가져야할 스킬은 완성도, 정확한 스펙, 오너십을 가지는 것이 중요하다. 그리고 PM은 더 많은 스킬들이 요구되는데 그 중에서 ‘제때’ 할 수 있는지가 중요하다. 일정 관리는 내가 가장 어려워 하는 일이기도 하다.

 

PM의 커리어를 시작하고 싶은 사람들은 당작 이직을 시도하는 것보다 현재 하는 업무중에서 PM이 하는 일을 찾아보는 것이 좋다. 그리고 스스로 원페이저를 만들어서 업무를 해야 한다. 원페이저는 뭔지 몰라서 찾아보니 프로젝트의 방향성과 목적을 판에 정리한 기획안이라고 한다.

 

PM의 문제를 해결하기 위해 한 문장으로 문제를 정의할 수 있어야 한다. 지금 중요한 게 뭔지, 지금의 문제를 고를 줄 알아야 한다. 사수를 만난다고 해서 문제를 해결하는 방안이 나오는 건 아니고 ‘어떻게’를 알려주지도 않는다. 내가 직접 해야한다. 그리고 그것들을 얼마나 효과적으로 문서로 표현하는지도 중요하다.

 


첫 강의였는데 내용이 정말 많고 도움이 되는 내용이 많았다. 특히 PM으로 커리어를 시작하는 사람들은 현재 위치에서 PM이 하는 일을 도맡아서 하라는 말이 현재 나의 상황과 비슷해서 와닿았다. 이번 강의를 통해 지금 디자이너로 일하지만 기획도 하고 개발자랑 소통도 하는 내가 PM의 일을 이미 하고 있다는 생각이 들었다. 그리고 나는 내가하는 기획에서 뭘 해야하는지 제대로 커뮤니케이션을 못 할 때가 있는데 앞으로 하고 싶은 일을 제대로 정리해서 말해야 겠다고 다짐했다. 특히 문서로 제대로 정리해서. 내가 잘 안되는 부분이 문서로 정리하는 일이기 때문이다. 주니어 PM에게 완성이 중요한 만큼 현재 진행하고 있는 프로젝트를 제대로 완성하고 제품의 성공을 위해서 노력해야 겠다.

 

'우피클' 카테고리의 다른 글

데이터 분석도 PM이 하는 일이다.  (0) 2022.03.26
우피클(Woopickle) 2기에 선정되었다.  (0) 2022.03.14