프로젝트 vs 프로덕트 매니저 어떻게 다른가? 보충해설
제 브런치에서 지금까지 가장 많이 조회가 된 글은 <프로덕트, 프로그램, 프로젝트 매니저? 뭐가 다른가요?>로 약 3만 회에 가깝습니다. 보강된 내용으로 같은 주제를 책 <프로덕트 매니지먼트> 1장 4절에서도 다룹니다. 지금까지 프로덕트와 프로젝트 관리의 역할 두 가지가 거의 비슷한 일이라고 생각한 분들이, 책 내용을 통해 이제는 그 차이점이 무엇인지 알게 되었다는 리뷰나 서평을 가장 많이 받습니다. 저에게는 큰 보람이 되는 일입니다.
그림 1. 책 <프로덕트 매니지먼트> 1장 4절제가 책과 브런치 글에서 말씀드린 아래 표 1.과 같은 역할 정리는 구별하기 편하고 변함없이 유효하긴 하지만 한편 너무 간단하긴 합니다. 예를 들어 프로젝트매니저가 '언제'에만 관심이 있지는 않죠. 기간내 비용, 위험, 범위도 관리해야 하는 역할입니다.
표1. 세 가지 PM 역할 구분그래서 오늘은 프로젝트 매니지먼트와 프로덕트 매니지먼트에 대한 차이점을 더 이상 필요하지 않게 너무너무 쉽게 해설하려합니다. 여러분들은 오늘 이후로 더 이상 헷갈리거나 혼란스럽지 않을 겁니다.
명확한 차이점 4가지
1. 종료 상태값
최고로 중요한 차이점이면서 구별하기 매우 쉽습니다.
프로젝트 관리와 프로덕트 관리의 가장 큰 차이점은 바로 그 관리가 끝났을 때의 ‘상태값’입니다.
프로젝트 관리는 목표와 기간이 정해져 있기에 끝난 상태는 늘 ‘완료’라는 닫힌 상태 값을 가집니다. 그러나 프로덕트는 ‘출시, 출하, 론칭’이라는 상태값을 가짐으로써 그 후에 연속적인 과정이 진행 중이라는 열린 상태 값을 갖습니다. 그리고 그 '열린 상태'라는 것이 프로덕트 라이프 사이클(PLC: 책의 2장에서 설명합니다)이라는 이름으로 지속성과 반복성을 갖게 됩니다.
예를 들어 '로빈 훗'이라는 이름의 소프트웨어 프로덕트를 가정해 봅시다. 만약 로빈 훗을 프로덕트 관리가 아닌 프로젝트 관리 방식으로 접근한다고 하면,
1. 로빈 훗 출시와 동시에 프로젝트의 상태값이 ‘완료’가 되면서 종료가 됩니다.
2. 소프트웨어 특성상 제품과 서비스의 책임과 오너십이 있는 상태에서 유지 보수라는 프로세스가 존재해야 함에도 불구하고 프로젝트가 완료되어 닫혔기 때문에, 추후에 발생하는 모든 프로세스는 멈추고, 연속성을 갖지 못합니다.
3. 유지 보수하는 기간, 비용, 리소스등이 모두 계획이 안되어 있기에 새로운 프로젝트로 기획하고 준비되어 동작하는수 밖에 방법이 없습니다.
그런데 이는 여러 가지 의도치 않은 부작용을 만들 수 있습니다. 특히 로빈 훗 제품이 기업의 핵심 비즈니스와 관련이 있을 경우에는 사용자의 요구 변화에 맞춰 제품을 수정(fix)하거나 최신화(update)가 지속적으로 필요한데, 프로젝트 매니지먼트에서는 제품과 비즈니스의 연결고리를 '종료 값'과 함께 끊어버리게 됩니다. 결국 로빈 훗은 비즈니스 변화에 탄력적으로 반응하지 못하게 되고, 이는 곧 비즈니스의 악화로 이어질 수 있습니다.
사실 이런 경우는 많은 SI 프로젝트에서나 고객 프로젝트, 정부 프로젝트에서 아주 쉽게 발견할 수 있는 같은 형태입니다. 예산대로 비용과 시간과 스코프(범위)가 지켜지는지가 가장 중요한 우선순위를 갖고 있으며 애초부터 라이프 사이클이란 프로덕트 기본 성격은 갖고 있지 않습니다.
2. 성공 책임과 기준
여러분은 이제 프로덕트 매니저가 제품의 성공에 대한 책임이 있다는 것은 이미 알고 있습니다. 하지만 어떤 책임이 있고 프로덕트 매니저에게 성공이란 무엇을 의미할까요?
프로덕트 매니저에게 성공은 OKR/KPI 또는 미리 합의가 된 지표(책의 6.2장에서 자세히 설명합니다)로 정의됩니다. 프로덕트 매니저는 특정 지표에 도달하여 성공할 책임이 있습니다.
프로덕트 매니저는 성공을 의미하는 지표에 대한 목표를 가지고 있으며 그 목표에 도달해야 합니다. 그 목표를 달성하는 방법을 결정하는 것은 전적으로 프로덕트 매니저와 이해 관계자와의 합의에 달려 있습니다. 이 지표를 책임과 기준으로 삼는 이유는 '비즈니스의 가치 창출'이 프로덕트에서 가장 중요한 성공 지표이기 때문입니다. 사용자 고객에게 가치를 전달하지 못하는 프로덕트는 아무 의미가 없다는 뜻입니다.
예를 들어 넷플릭스에서 여러분을 프로덕트 매니저로 고용하고 이번 2023년 3분기에 기본 서비스에서 프리미엄 서비스로의 결제 전환율을 10% 높이고 싶다고 하면, 여러분은 디스커버리 과정으로 사용자 조사를 하고 모든 관련 데이터를 검토하여 문제를 해결하거나 목표를 달성하기 위해 어떻게 접근할지 결정할 수 있습니다. 예를 들어 사용자가 프리미엄 서비스 내용을 잘 이해하지 못했기 때문이라면, 도움말을 적절하게 추가하고 결제 프로세스를 더욱 심플하게 재설계할 수 있습니다. 또는 스트리밍 퍼포먼스를 높이기 위해 더 빠른 클라우드 서비스를 도입하기로 결정할 수도 있고, 카드 결제 파트너의 잦은 오류로 최종 결제 전에 이탈하는 고객이 많아 전환율이 목표치를 넘지 못한다는 사실을 알게 되면 프로덕트 매니저는 어떤 접근 방식이 다른 접근 방식보다 더 나은지를 엔지니어나 디자이너와 함께 조사와 연구, 회의를 거쳐 결정합니다.
그렇다면 프로젝트 매니저는 어떤 책임과 성공 기준을 어떨까요? 프로젝트 매니저는 프로젝트를 완수할 책임(즉 상태값을 '완료'로 종료할 책임)이 있기 때문에, 프로젝트에 할당된 타임라인과 예산이 가장 중요한 성공 조건이 됩니다. 프로젝트는 이미 시작되기 전에 예산과 타임라인이라는 최종 목표를 확정한 뒤, 그 범위 내에서 태스크가 할당된 프로젝트를 완료하는지가 최고의 성공 기준이기 때문입니다. 그러기에 목표 예산, 비용, 스코프를 초과하는 고객의 피드백 반영과 제품의 추가적인 개선은 즉각적으로 수용되기 어렵습니다. 라이프 사이클이 원래부터 준비되지 않았기 때문입니다.
3. 우선 순위
프로젝트 매니저에게는 프로젝트 계획 (비용, 타임라인, 스코프)이 절대적인 우선순위입니다. 사전에 철저하게 계획을 세우고 프로젝트를 진행하기 때문에, 계획의 변경은 프로젝트 관리 및 의사소통, 협업 측면에서 많은 비용 추가를 야기합니다. 그러하기에 계획의 변경을 가급적 지양하게 됩니다. 목표한 기한 내에 계획이 완수되는 것을 최우선으로 작업의 우선순위가 결정됩니다.
프로젝트 관리 방법은, 복잡성과 불확실성, 돌발성이 계속되는 환경에서도, 목표 계획의 정상적 완료에 우선순위가 있기에, 실제 고객의 비즈니스 가치는 최고의 우선순위는 아닙니다.
이에 반해 프로덕트 매니저는 프로덕트 로드맵과 지속적인 사용자 피드백, 가설 검증을 기반으로 우선순위를 변경하고 작고 빠른 릴리스 사이클을 가져갑니다. 실제로 고객에게 가치를 제공하는 지를 피드백받고, 이를 기반으로 학습하고 새로운 계획과 우선순위에 반영하는 것을 반복, 지속하며, 점진적으로 개선시켜 나갑니다. 즉, 프로덕트 매니저는 계획의 완수가 아닌 프로덕트의 가치 창출을 최우선으로 하여 작업의 우선순위를 설정하고 수정합니다. 바로 이 일에 따라 프로덕트가 성공할 수 있냐를 결정하게 되는 프로덕트 매니저의 가장 중요한 업무 중의 하나입니다.
4, 위험 관리
프로젝트 매니저는, 프로젝트를 진행하면서 발행할 수 있는 모든 리스크를 사전에 예상하고 이에 대한 철저한 플랜을 마련해야 합니다. 물론 위험을 사전에 예방하는 것은 좋은 의도이지만, 일어날 수 있는 모든 위험을 완벽하게 예상하고 대비하려는 접근은 크게 두 가지의 문제가 있습니다.
첫번째는 이를 위해 너무 많은 시간과 자원, 노력이 투여 된다는 점입니다. 거의 발생하지도 않을 리스크에 대한 대비까지 너무 철저하게 준비하기 위해 많은 비용을 소모하는 것은, 프로젝트의 효율성 추구에 모순되는 지점입니다.
둘째, 수많은 프로젝트를 경험한 베테랑 프로젝트 매니저라도 모든 위험을 완벽하게 예측하기는 불가능합니다. 아무리 철저하게 분석하고 준비한다고 한들, 복잡성과 불확실성, 변동성이 급변하는 미스테리 (참조: "좋은 PM은 '퍼즐'이 아닌 '미스터리'를 해결합니다.")를 해결해야 하는 오늘날의 비즈니스 환경에서는 불가능한 이야기입니다.
프로덕트 매니저는 ‘프로토타입(책 5장 1절)’이나 ‘MVP (책 5장 4절)’ 등을 활용하여 리스크를 확인하며 분산시켜 점진적으로 프로덕트의 가치를 키워나가는 방법으로 접근합니다. 이는 모든 위험을 사전에 철저하게 대비하는데 들이는 시간과 비용을 줄일 수 있음은 물론, 실패를 빠르고 작게 경험함으로써 실패에 대한 부담과 비용도 줄일 수 있습니다. 또한 이러한 접근은 비단 위험 대비 뿐만이 아니라, 기존에 파악하지 못했던 기회를 발견하는 데에도 큰 도움을 줍니다.
위의 네 가지 명확한 차이점에서 설명했듯이 프로덕트 매니저는 디스커버리 기간 동안 요구 사항과 아이디어를 수집하고 잠재적인 이니셔티브를 정의하고 비즈니스 가치에 따라 우선순위를 정해 딜리버리를 합니다. 그리고 성공 지표를 달성하기 위해 열린 상태의 프로덕트 라이프 사이클을 꾸준히 진행합니다.
프로젝트 매니저는 사전에 정의된 프로젝트 계획에 따라 완료를 목표로 예산(비용), 타임라인, 스코프를 관리합니다. 그리고 닫힌 상태값 '완료'가 최종 목표입니다.
다시 한번 강조해서 말씀드리고 싶은 것은 프로젝트 매니저와 프로덕트 매니저가 무엇이 좋고 나쁘고 우수하고 열등한지에 대한 답은 없을뿐더러 그런 비교는 적절치 않습니다. 모두 그 비즈니스상황에 따른 책임 완수에 필요한 역할일 뿐입니다. 스크럼 마스터와 같은 역할이 준비되지 않은 작은 규모의 기업이라면 프로덕트 매니저가 릴리스 일정에 맞추어 프로젝트 매니저의 역할을 할 수도 있습니다. 그러기에 서로 간의 업무 기술 역시 이해하고 존중할 필요가 있습니다. 여러분들의 땀과 노력을 진심으로 응원합니다.
