“프로덕트 매니저는 어떤 일을 하나요?”라는 질문에, PM들이 종종 “일종의 잡부 역할이죠”라고 표현합니다. 개인적인 인식을 포함해서 기업의 PM 직무에 대한 정의, 그리고 PM 역할에 대한 여러 고정관념들이 '잡부'라는 표현을 만들어내는 것 같습니다.

당연한 이야기라 '재발견'이란 단어가 이상할 수 있지만 'PM 역할의 재발견'이란 주제로 이번에 포스팅을 해봤습니다.

즐거운 설 연휴 보내세요 :)

---

아래는 글의 일부인 프로덕트 매니저 직무에 대한 고정관념을 유형 정리입니다.

1. 프로덕트 오너(Product owner) 유형

(참고. 여기서 언급하는 프로덕트 오너는 토스나 쿠팡에서 언급하는 직무(job)와 다르다.) 

PM을 단순히 백로그 관리하는 역할로 보는 관점이다. 

프로덕트 오너(Product Owner)는 스크럼(Scrum)을 활용해 제품 개발을 진행하는 조직에서 주로 존재하는 역할이다. PO는 스크럼 팀을 지원하고 제품 배포 속도를 극대화하는데 초점을 맞춘다. 일반적으로 PO는 다른 사람이 작성한 로드맵을 기반으로 에픽(epic)이나 유저 스토리(user story) 형태로 백로그를 작성하는 일을 담당한다. 모든 회의에 참여해야 하지만, 사용자와 시장에 대한 깊은 이해를 높이는 활동은 수행하지 않는다. 결과적으로 PO는 성과(outcome) 보다 산출물(output)에만 집중하게 된다. 이는 많은 업무량에도 불구하고 결과물 중심의 업무가 사용자와의 연결감을 약화시키기 때문에(제품 오너십을 낮춰) 성취감이 떨어지는 이유로 작용한다.

2. 서비스 기획자 유형

PM을 화면과 기능을 기획하는 전문가로 한정하는 관점이다. 

2000년대부터 한국의 테크 기업(예: 네이버, 다음)에서는 서비스 기획자라는 직무가 존재해 왔다. 서비스 기획자는 역할 면에서 프로덕트 매니저(PM)와 유사하다. 고객의 니즈를 발굴하고 솔루션을 도출하며, 엔지니어와 디자이너와 협업하여 제품을 개발하는 등 다양한 업무를 담당한다. 또한 업무 범위는 제품 개발에만 국한되지 않고, 파트너십 관리나 제품 마케팅과 같은 폭넓은 역할로 확장되기도 한다.

하지만 서비스 기획자의 업무에는 조직 구조와 팀 간 상호작용(Team Topology)에서 오는 한계가 존재한다. 대부분의 경우, 서비스 기획자가 있는 조직은 기획팀, 개발팀, 디자인팀과 같은 기능 중심 조직으로 구성되어 있다. 이로 인해 현대적인 의미의 프로덕트 트리오(Product Trio) 개념이 부족하고, 서비스 기획팀이 화면 설계 및 기능 기획서를 작성하면, 디자인팀이 디자인 가이드를, 개발팀이 이를 기반으로 구현하는 형태로 업무가 진행된다.

이 구조에서 서비스 기획자의 핵심 역할은 제품 기능 개선을 위한 시나리오와 정책을 꼼꼼히 검토하고, 이를 기반으로 엔지니어와 디자이너를 ‘설득’하는 데 초점이 맞춰지게 된다. 그러나 유저 테스트 기반의 근거(evidence)가 부족한 경우, 기획서(소위 ‘스펙’)는 엔지니어와 디자이너 리뷰 과정에서 스펙 아웃(spec-out)되기 쉽다. 이는 조직 구조로 인한 자연스러운 결과이며, 서비스 기획자가 열심히 기획한 아이디어가 실제 제품에 반영되지 못하는 일이 자주 발생하는 원인 중 하나이다. 이로 인해 서비스 기획자는 좌절감(현타)을 느낄 수밖에 없습니다.

3. 조정자 유형

PM을 단순히 이해관계자와 엔지니어, 디자이너 사이의 의사소통을 중재하는 조정자로 보는 시각이다.

조정자 역할을 수행하는 PM은 사내 이해관계자, 임원, 그리고 팀 사이를 오가며 아이디어를 수집하고 타협점을 찾는 데 주력한다. 그러나 훌륭한 제품은 이해관계자의 합의만으로 만들어지지 않는다. 조정자 역할을 맡은 PM은 마치 식당에서 서빙하는 역할에 가까운 경우가 많다(가장 불행한 경우 중에 하나이다). 이를 서번트 리더십(servant leadership)이라고 긍정적으로 표현하기도 하지만, 실질적으로는 제품에 대한 의사결정 권한이 없는 상태에서 사용자, 시장, 제품, 비즈니스에 대한 깊은 이해가 있어도 큰 영향을 미치기 어렵다.

또한, 이러한 PM은 제품 출시 프로세스를 운영하는 역할까지 맡는 경우가 많다. 이로 인해 프로세스 관리 업무가 PM의 주된 일로 자리 잡으며(압도되며), 본래 PM 역할의 핵심이라고 할 수 있는 전략적 기여는 뒷전으로 밀려나게 된다.

4. 프로젝트 매니저 유형

PM을 일정 관리와 예산 조정에 초점을 맞춘 프로젝트 관리자로 오해하는 경우이다.

프로젝트 매니저(Project Manager)는 일반적으로 PMO(Project Management Office)와 같은 조직에 소속되어 중앙 통제식(command-and-control) 문화 속에서 업무를 수행합니다. 프로젝트 매니저에게 요구되는 주요 역할은 정해진 일정과 예산 내에서 로드맵에 정의된 기능을 구현하는 것이다. 

이러한 역할에서 프로젝트 매니저에게 가장 중요한 것은 정해진 일정에 맞춰 산출물(output)을 내는 것이다. 따라서 프로젝트 매니저의 일반적인 커뮤니케이션 방식은 다음과 같습니다. “언제까지 완료할 수 있나요?”, “누가 이 작업을 담당할 수 있나요?”, “어떻게 구현할 수 있을까요?” 

로드맵에 정의한 기대치(expectations)를 이해하고, 계획을 잘 수립하고, 필요한 리소스를 잘 협상하는 것이 업무에서 중요한 요소이다. 따라서 얼마나 조직 내에서 영향력을 미칠 수 있는지 여부가 프로젝트 매니저에게 중요한 역량이다.

프로젝트 매니저는 특정 프로젝트가 종료된 이후, 해당 프로젝트의 성과나 인사이트를 기반으로 개선 작업을 진행하기보다는 로드맵에 정의된 다음 기능 구현 작업으로 바로 전환하는 경우가 많다. 이로 인해 항상 고정된 협업 멤버가 존재하지 않으며, 프로덕트 팀의 공통된 지식과 인사이트를 축적하거나 팀의 속도(cadence)를 기반으로 일하는 것이 어렵다. 또한, 매번 다른 프로젝트에서 다른 동료와 목표, 그리고 컨텍스트를 마주하게 되는 상황에서 프로젝트 매니저는 제품에 대한 오너십을 가지기 어려우며, 관리자로서 단순히 업무를 처리하는 데 급급한 상태에 놓이기 쉽다.

https://brunch.co.kr/@yongjinjinipln/210