특히 국내 업계에서 (특히 IT 분야) ‘PM’ 이라고 소개를 하면 상대방은 대부분 프로젝트 매니저 (Project Manager) 로만 이해하는 것이 현실입니다. 그러나 상황에 따라 ‘프로덕트 매니저 (Product Manager)’ 혹은 ‘프로그램 매니저 (Program Manager)’ 의 역할을 수행하는 사람들이 있습니다.

이 번 포스트 에서는 모두 비슷해 보이지만 분명히 각각 다른 일을 해야 하는 프로젝트 / 프로그램 / 프로덕트 매니저가 어떠한 역할들을 수행하는지, 서로의 관계는 어떻게 되는지, 그리고 각 역할들이 왜 중요한 것인지에 대해 이해해보도록 하겠습니다.


0. 들어가기전에

먼저 프로젝트 / 프로그램 / 프로덕트 매니저의 주 업무는 팀원 들을 관리해야 하는 People Manager 가 아닙니다. 아무래도 ‘매니저’ 라는 타이틀 때문에 많이들 오해하는 부분 중 하나라고 생각됩니다. (물론 조직이나 업무 특성상 People Manager 를 겸직할 수도 있습니다.)

또한 일반적인 프로젝트 / 프로그램 / 프로덕트 업무를 정의해 보면 다음과 같습니다.
– 프로젝트 (Project) : 단기간에 특정 제품/서비스를 만들거나 관련된 목표를 달성하기 위해 처리되어야 하는 한 가지 또는 관계된 여러 업무
– 프로그램 (Program) : 조직의 목표를 달성하기 위한 여러 프로젝트들의 묶음. 장기적인 목표를 수립하기도 함
– 프로덕트 (Product) : 제품 또는 서비스 그 자체. 따라서 프로덕트 관리는 시장의 요구에 대응하기 위해 (혹은 시장을 리딩할 수 있는) 모든 것들을 하는 것. 모든 프로덕트는 수명 주기 (Life-cycle) 가 있으며, 수명 주기에서는, 제품/서비스에 대한 최초 아이디어 수립 – 개발 – 마케팅 – 개선 – 단종/폐기 의 모든 것들을 포함. (프로덕트 에서는 수명 주기 내에 여러 프로젝트를 포함할 수도 있음)

위와 같은 각 업무에 대한 내용들을 바탕으로 각각의 매니저들이 어떠한 역할을 해야 하는지 알아보겠습니다.


1. 프로젝트 매니저 (Project Manager)

프로젝트 매니저는 프로젝트에 대한 전반적인 계획 수립을 하고, 업무를 할당 하며, 전체적인 진행 상황을 점검 합니다. 또한 진행 과정에서 장애물이나 도전 과제를 직면하게 된다면 프로젝트의 모든 이해관계자들과 소통하여 문제를 해결해나가는 역할을 합니다. 그러므로 프로젝트 매니저는 제 시간에 프로젝트가 완료될 수 있도록 상황에 맞게 예산과 일정을 조율하고 리소스 들을 효과적으로 배분하여 할당해야 합니다. (시간/예산과 결과물의 퀄리티는 항상 서로 비례하는 이율배반적인 관계에 있으니까요) 야구 경기를 예로 들면, 경기에서 이기기 위해 선수들을 현장에서 지휘하는 감독 정도가 되겠네요.

프로젝트 관리 (Project Management) 에서 포함되어야 하는 주요 업무 들은 다음과 같습니다.
– 리스크 관리 (Risk Management)
– 리소스 관리 (Resource Management)
– 프로젝트 범위 관리 (Scope Management)

리스크 관리에서는 예상되는 리스크 들을 파악하는 업무와 리스크 그 자체를 줄이는 업무도 포함될 수 있습니다 (예> 축구 감독의 선수들 부상을 방지를 위한 노력). 리소스 관리에서는 프로젝트에 필요로 하는 도구나 환경 등이 충분히 갖춰져 있는지를 확인 합니다. (예> 야구 감독은 선수들이 훈련이나 경기를 잘 소화하기 위해 적합한 운동 도구, 영양소 공급 등을 신경써야 할 것입니다.) 특히 프로젝트 관리에서 어려우면서도 중요한 부분 중 하나는 프로젝트의 범위를 정하는 것입니다. (예> 야구 감독은 본인 팀의 역량과 경쟁 팀의 역량을 고려하여 적합한 전략적인 승리 목표를 설정해야 합니다. 욕심이 과하면 모자람만 못할 수 도 있는 상황이 발생할 수도 있겠죠.)


2. 프로그램 매니저 (Program Manager)

산업이나 조직에 따라 조금씩 다르지만 프로그램 매니저는 크게, (1) 여러 프로덕트에 공통으로 적용되는 일부 기능에 대한 전반적인 책임을 지는 테크니컬 프로그램/프로덕트 매니저 (Technical Program Manager / Technical Product Manager), 그리고 (2) 여러 프로젝트 들로 구성된 프로그램을 담당하여 전체적인 딜리버리에 대한 책임을 지는 딜리버리 매니저 (Delivery Manager) 역할을 하는 경우 로 나눌 수 있습니다.

예를 들어, 자동차를 출시하는 경우 아래와 같이 테크니컬 프로그램 매니저와 딜리버리 매니저의 역할을 설명할 수 있겠습니다.

위 그림에서는 각기 다른 자동차 모델 (예> 승용차, 트럭, 승합차 등) 의 출시를 위해 한 모델에 필요한 여러 기능/구성 들은 딜리버리 매니저가 책임을 지고, 각기 다른 자동차 모델에 공통적으로 들어가는 각각의 개별 기능/구성 (예> 핸들, 도장 등) 들은 각 테크니컬 프로그램 매니저가 책임을 지는 형태를 보여 줍니다.

종합하자면 프로덕트 전반에 영향을 미치는 프로그램 매니저는, 개별적으로 담당하는 파트 들이 조직에서 추진하는 다양한 진행 사항들과 맞물려 어떻게 비즈니스에 영향을 미치는지 잘 이해해야 하고 관련된 미래를 내다보는 통찰력이 필요합니다.


3. 프로덕트 매니저 (Product Manager)

프로덕트 매니저는 고객이 요구하는 것, 더 나아가 시대의 흐름을 읽거나 미래를 예측하여 앞으로 필요로 하는 것 또는 시장을 이끄는 제품이나 서비스를 만들기 위해 디자인에서 부터 개발과 생산 및 마케팅에 이르는 전체적인 과정, 즉 담당 프로덕트 의 수명 주기 (Life-Cycle) 전체 모두를 CEO 처럼 책임지는 역할을 한다고 볼 수 있습니다. 이를 달성하기 위하여 여러 다른 프로젝트나 프로그램들을 이끌 수 있는 전략적인 비즈니스 목표를 설정 하기도 합니다.

개인적으로는 애플을 이끈 스티브 잡스가 인류 역사상 손에 꼽히는 프로덕트 매니저 였다고 생각합니다. 제품과 서비스에 대한 기본 철학을 수립하는 것에서 부터 그것을 바탕으로 한 디자인, 운영체제, 비즈니스 플랫폼 등의 개발에 직접 깊이 관여 하였고 그 결과 전 세계가 사용하는 모바일 기반의 IT 플랫폼이 단 시간 내에 최소 한 세대 이상의 급격한 발전을 할 수 있었다고 생각합니다. (단순히 아이폰 이라는 기기를 넘어서서 모바일 운영체제/플랫폼을 기반으로 한 앱스토어와 같은 비즈니스 플랫폼을 이야기 하는 것입니다.)


위의 내용들을 바탕으로 각 역할 들을 한 눈에 볼 수 있도록 정리해 보면 다음과 같습니다.

– 부록. PM (프로덕트 매니저, 프로그램 매니저, 프로젝트 매니저) 는 왜 필요한가?

실제로 2001년도에 구글의 CEO 였던 래리 페이지는 프로젝트 매니저들을 모두 해고하려고 시도했던 적이 있었습니다. 기술자들이 기술자가 아닌 사람에게 통제를 받으면 생산성이 떨어지고, 프로젝트 매니저들이 그들의 역할을 잘 하지 못하고 있는 것 같다는 것이 그 이유 였습니다. (이 때, 모든 구성원들은 강하게 반발하였습니다. 그러나 결국 프로젝트 매니저들은 해고되는 대신 결국 다른 부서에서 근무하게 되었습니다.) 이 후 엔지니어들은 프로젝트 매니저 없이 엔지니어링 파트의 부사장 (Vice President) 에게 직접 보고 하게 되었습니다. 이 결과로, 어떤 엔지니어들은 중간 관리자 없이 잘 지내는 한편 어떤 엔지니어들은 필요한 리소스 들을 할당받지 못하거나 리소스가 중복되는 문제가 발생하기 시작했습니다. 또한 중간 매니저들로부터 경력에 대한 피드백을 받거나 관리를 받지 못하는 문제도 발생하게 되었습니다. 결국 구글은 다시 프로젝트 매니저들을 고용 해야만 했습니다.

한 편, 수 천명이 근무하는 공장에 프로덕트 매니저가 없다면, 그 비즈니스와 공장은 어떻게 될까요? 아마도 시장의 흐름을 읽고 전체적인 오케스트레이션을 하지 못하며 비즈니스 전체의 방향성을 잃어버릴 지도 모르고 결국 큰 배가 좌초될 수 있는 상황이 발생할 수 있겠죠?



#Steven