프로덕트 매니저의 가장 어려운 역할
<프로덕트 리더십>을 읽고 생각 정리하기
이 글은 지난 글에 이어 <프로덕트 리더십>의 2장 '프로덕트 리더십이 중요한 이유' 중에서 67쪽에 등장하는 딱 한 문장이 주는 영감을 글로 풀어냈습니다.
팀워크로 구현하는 절차와 과정의 산물
여러 가지 생각을 떠오르게 하는 문장입니다.
프로덕트 매니저의 가장 어려운 역할은 시간, 비용, 에너지를 소비할 대상을 결정하는 것이다.
첫 번째는 회사에서 차용하고 있는 ART입니다. 하지만, 방법론으로 쓰는 것은 아닙니다. 2014년에 학습한 내용을 개념적인 수준에서 재사용하는 것일 뿐입니다. 그저 이름만 빌려 쓴다고 할 수도 있습니다.
동료들과 공유하는 것은 이름일 뿐이고, SAFe의 내용은 암묵지로 제가 기억으로 보관할 뿐이니까요. 실제 구현은 매주 1회 회의와 일상의 대면/비대면 소통으로 만들어지고 있죠. 그래서, ART라고 칭하는 것이 지향하는 것에 이름을 붙여 보니 그럴싸하네요.
팀워크로 구현하는 절차와 과정의 산물
프로덕트 관리 VS 프로젝트 관리
두 번째로 프로젝트(Project) 관리와 프로덕트 관리의 중요한 차이를 보여주는 문구입니다. 아래 그림은 10여 년 전에 애자일한 프로젝트 진행의 필요성에 대해 대기업 경영진에게 설명할 때 인용한 그림입니다.
이 그림에 제가 담아둔 가치는 크게 두 가지입니다. 하나는 릴리즈를 통해 시장을 학습하는 일의 중요성입니다. <진화하는 혹은 오래 사는 시스템 만들기>에서 '일단 릴리즈를 해라'라는 내용으로 관련 내용을 자세히 쓴 바 있습니다. 과거의 지식으로 내부 구성원들이 아무리 좋은 아이디어를 내고 치밀하게 계획을 짠다고 해도 시장의 반응을 직접 겪는 일을 대체할 수 있을까요? 저는 절대로 불가능하다고 믿습니다.
알면서도 반복하는 차세대라는 함정
하지만, 전산실에서 출발한 IT 조직을 갖고 있거나 외주 개발에 의존하던 기업이 갖고 있던 두 가지 특징은 이른바 '폭포수 방식'을 강제합니다. 먼저 작게는 수 억에서 크게는 수천 억에 해당하는 거액으로 품의를 받는 보고 절차가 강력한 압박으로 작용합니다. 아무래도 거액의 비용 집행이다 보니 보고한 대로 결과가 나왔느냐 하는 논리를 무시할 수가 없습니다.
역동적인 시장 변화를 받아들여야 하지만, 결과적으로 마치 정치나 행정의 영역에서 절차적 당위성을 강조하는 일을 처리하듯이 프로젝트를 수행합니다. 안타까운 미스매치가 아닐 수 없습니다.
또 다른 요인은 IT를 비즈니스 기능부서로 보지 않아 생기는 문제라 할 수 있습니다. IT부서의 결과물은 비즈니스 성과가 아니라 기술적인 표현이나 비용에 대해서 초점을 맞춰 사실상의 성과 평가가 무의미해 진다는 점입니다. 그런 점에서 제품이란 뜻을 가진 '프로덕트'라는 표현 자체가 갖는 혁신성을 다시 한번 확인할 수 있습니다.
비전과 전략을 다루는 프로덕트 관리
관련 내용이 나온 김에 인터넷에서 흥미롭게 보았던 자료(출처 미상)를 다시 살펴보겠습니다. 위에서부터 두 개 항목 비교만 보아도 책에서 인용한 문장의 디테일을 부연하는 듯합니다.
프로덕트 매니저의 가장 어려운 역할은 시간, 비용, 에너지를 소비할 대상을 결정하는 것이다.
프로덕트는 '비전Vision'을 담아야 하고, 전략Strategy 수행의 결과이기 때문에 어렵습니다. 반면, 프로젝트는 실행에 초점이 맞춰지고 보고 진척 여부에 대한 상태 보고가 주를 이룹니다. 비전과 전략을 다루는 일과는 굉장한 차이가 있죠.
프로덕트는 내용을, 프로젝트는 계약 이행을 담는다
정의 업무에 있어서도 초점이 다릅니다. 프로덕트 매니저는 '제품의 기능' 정의가 중요한 반면에 PM(프로젝트 관리자)은 요구사항 정의가 중요하죠. 아마도 계약의 이행으로 역할이 제한되는 탓이겠죠. 그러니 프로덕트 매니저는 내용에 관심을 두지만, PM은 조정역할이 중요합니다. 또한, 기능에 있어서도 관점이 엄청나게 달라집니다. 프로덕트 매니저는 기능을 통합해야 하니 개념화(Conceptualization)가 중요하지만, PM은 납기가 중요합니다.
규모가 커지면 직무 관계와 이에 따른 조직도 매우 달라집니다. 프로덕트가 커지면 프로덕트 개선을 위한 프로젝트가 다수가 될 수 있고, 이를 전담하는 PM이 생겨나 협업할 수도 있겠죠. 반면에 PM은 다수의 프로덕트를 다루는 프로젝트를 수행할 수도 있습니다. 이론적으로는 그러한데, 실제 이런 상황을 어떻게 받아들여야 할지는 잘 모르겠습니다.
마지막 네 개 항목을 더 살펴보고 글을 마치도록 하겠습니다. 프로덕트 관리자가 최적화하려고 노력하는 대상은 프로덕트 자체 혹은 그 기능이라면 PM은 다릅니다. 그들은 비용, 속도, 품질 같은 변수를 다룹니다. 한편, 프로덕트 매니저는 '전략적 로드맵'을 따르는 반면 프로젝트는 보통 사전에 계획하고 보고한 일정을 따릅니다. 이에 따라 실적을 보는 기준도 다르죠. 프로덕트 매니저는 프로덕트가 시장에서 성공하느냐가 평가의 잣대이지만, PM은 계획을 잘 이행했는가로 평가받습니다.
