brunch

You can make anything
by writing

C.S.Lewis

by 스나 Sep 17. 2023

PM, 뭐하는지는 알겠는데 어떻게 해야 잘하는 걸까?

[일하는 책읽기] 프로덕트 매니지먼트 - 김영욱

퍼포먼스 마케터에서 PM 업무를 잠시 경험하면서 막막함을 느낀 이유는 PM으로서 어떻게 일해야 하는가? 에 대한 멘탈모델이 없어서였다. 처음에 주어진 일은 개발자가 먼저 요구한 화면 기획사항을 구현하는 일이었다. 화면 안에서 버튼이 어디에 있어야 좋고, 어떤 문구를 써야 유저가 헷갈리지 않을지를 고민하는 것부터 어려운데, 다음 스프린트에서 어떤걸 우선순위로 개발해야할지를 어디서부터 어떻게 논의해야하지? 

대충 뭘 해야 하는지는 알겠는데, 쌩신입이 아닌 이상 경력직 직무전환자로서 더 나은 결과물을 내려면 어떻게 해야하는지 막막함을 느꼈다. 


PM의 업무도 커머스의 MD나 마케터처럼, 그 경계와 범위가 칼로 무자르듯 나뉘지는 않는 것 같다. 이번에 읽은 <프로덕트 매니지먼트> 책에서도 PM 역할의 범위를 한정하지 않고, '프로덕트 성공에 대한 모든 책임을 지는 역할' 로 정의한다. 뭐가 이리 모호해? 라는 느낌이 들지만, PM 은 실제로 기업 비전과 일치하는 팀의 목표를 달성하기 위한 모든 일을 관리해야한다. 


이렇듯 모호하고 방대한 PM의 일이지만, <프로덕트 매니지먼트> 에서는 이를 크게 3가지로 나눈다. 


1. 커뮤니케이션 허브 역할 

- PM으로 일하는 친한 친구에게 PM으로서 가장 많이 하는 일이 뭐냐? 라고 물으니 "부서간 커뮤니케이션으로 조율하기" 라고 말했다. 어떤 날은 하루종일 개발팀과 업무 요청사항 전달, 고객사의 회의, 고객사에서 전달받은 업무를 팀원들과 공유하기 등 정보전달자의 역할을 하기도 한다고. 


2. 우선순위 조정 역할

- 메이커 조직 내에서 화면과 기능을 구현하는 직무의 담당자들은 모두 각자의 전문성이 있기 때문에, PM은 프로덕트가 일정에 뒤쳐지지 않게, 올바른 방향으로 구현되게 하기 위해 우선순위를 조정해야한다. 개발자는 도전정신을 불러일으키는 개발을 하고 싶고, 디자이너는 사용자뿐만 아니라 자신도 만족하는 디자인을 만들고 싶은 것이 당연하다. 하지만 우리의 리소스는 늘 부족하고, 이번에 어디까지 해야하는지? 를 모두가 합의한채로 그 안에서 각자의 속도로 달려나가야 한다.

우선순위를 정하는 MoSCow 방법론
RICE score 방법론. 다양한 방법론이 있지만 우리에게 맞는 방법론을 찾아나가는 과정이 필요하다.

3. 프로덕트 대표이자 치어리더 역할 

- PO로 일하시는 분과 커피챗을 한 적이 있는데, PO에게는 프로덕트 팀을 운영하는 매니징 능력 또한 중요하다고 한다. 회고를 하며 프로젝트 팀원들의 업무성과에 대해 평가하기도 하고, 리소스 과부화가 될 때에는 팀원들의 사기를 끌어올리기 위해 노력하기도 한다고. 보통은 팀장이 해야할 일이지만, 크로스펑셔널 팀으로 일하는 조직에서는 PM/PO의 리더십과 매니징 능력이 프로젝트의 성패를 가를 수 도 있을거란 생각이 들었다.


프로덕트 매니지먼트 그룹은
필요없는 것 (시간, 리소스, 비용) 을 줄이는데 집중한다.



디자인 씽킹, 린 스타트업, 애자일을 통합하는 복합 다이어그램.

스크럼, 칸반, 애자일, 린스타트업, 디자인씽킹.. 프로덕트 조직이 일하는 방식에 쓰이는 방법론들은 많지만, 일잘러 PM이 되려면 어떤식으로 이 방법론들을 활용해야 좋을까? 에 대한 자신만의 답을 찾아야 한다고 생각했다. SAP의 프로덕트 매니저로 일하는 저자는 자신의 경험을 바탕으로 아홉가지 팁을 공유한다. 


1. 짧고 빠른 주기로 시행차공를 경험하자. 시행착오가 큰 위험이 없으려면 작은 단위로 나누자. 조금씩 늘려가면서 최대한 자주 행하고, 반드시 회고미팅을 하며 프로세스를 발전시켜야 한다. 

2. 팀 업무 진행상호아의 정기적인 리뷰를 하자. 발견된 개선요청사항은 공유해야한다. 

3. 각 그룹의 책임 매니저는 각 프로세스의 진행상황을 충실히 파악하고, 중요미팅에 반드시 참석한다.

4. 애자일, 린스타트업, 디자인 씽킹 등 방법론의 원론에 너무 매달리지 마라. 

5. 팀이 테스트와 실험, Best Practice 를 통해 자율적으로 업무 결정을 할 수 있는 권한을 부여한다. 

6. 커뮤니케이션은 지극히 투명하게 하자. 

7. 회고 결과를 긍정적인 피드백으로 공유하고, 경쟁적인 요소로 사용되지 않도록 주의하자. 

8. 팀원 모두가 동의하 수 있는 투명한 진행 지표를 정하자. 

9. 위 여덟가지보다 더 중요한 팁은 고객을 항상 업무 프로세스와 프로덕트 중심에 두자.


그리고 마지막에 적힌 문단이 와닿았다. '고객은 제품과 서비스를 만드는데 지금 애자일을 사용하는지, 린스타트업을 얼마나 잘 활용하는지, 디자인 씽킹 전문가인지 하나도 관심없다. 궁금해하지도 않는다. 팀이 고객에 집중하기 위해 서로간 경험을 공유하고 협업한다면 좋은 방법론을 가진 것이다.'


책에서는 고객개발/프로덕트 개발을 하기위해 사용자 스토리 작성, 고객 설문조사, 순 고객추천지수 조사, 유저에게 직접적인 피드백을 구할 수 있는 20달러 스타벅스 테스트부터 시장규모추산, 경쟁자 평가방법과 같이 프로덕트를 더 거시적인 차원에서 판단할 수 있는 방법론을 제시한다. 좋은 PM 이 되기 위해서는 이러한 방법론을 알아두고, 적재적소에 써먹는 것이 중요하다 방법론을 이미 알고 있으면, 어떻게 하지? 라는 고민시간을 줄여 지름길로 갈 수 있다고 생각한다. 


하지만, 더 중요한건 우리 조직의 비전에 맞는, 조직이 합의하는 방법론을 취사선택하고, 모든 프로세스를 회고하며 합을 맞추는 과정을 의식적으로 실현하는 것이라고 생각한다. 아직 좋은 PM이 되어본 적은 없다고 생각하지만, 이 모든 고민의 과정이 조금은 더 나은 방향으로 일을 이끌어가리라 생각한다. 

작가의 이전글 개발자와 협업 잘하는 법? 개발자를 이해하는 것 부터!

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari