요즘의 많은 소프트웨어/서비스기업에서는 ‘프로덕트 매니저/ 프로그램 매니저’ 의 역할에 대해서 더 깊은 인식을 하고 그 역할을 부여하고 진행을 하고 있습니다. 지난번에 간단하게 다룬 < PM-프로덕트 매니저, 프로그램 매니저, 프로젝트 매니저들이 어떻게 다른지 > 에 설명을 해 보았지만, 실제적으로 프로덕트매니지먼트가 무엇을 하는지에 대한 설명은 매우 많이 모자란다고 생각합니다. 기회가 되는대로 제품의 오너십을 가진 프로덕트매니저나 프로그램 매니저의 역할과 업무 프로세스에 대해서 아는 한도에서 열심히 제 경험을 나누어 볼까 하는데, 그것을 제대로 알려면 먼저 일반적으로 말하는 소프트웨어 서비스 기업의 프로덕트 그룹이 어떻게 이루어 있는지 제품/서비스를 구성하는 상위 체계는 어떻게 이루어져 있으며 어떻게 상호 유기적으로 업무를 수행하는지를 이해하는 것이 필요합니다. 그 이후에 프로덕트매니저/프로그램 매니저의 필요 기술이나 역할, 실제 업무 수행 방법에 대해서 설명하는 것이 더욱 쉽게 이해가 되리라 생각합니다. 몇번의 연재 과정이 필요하리라 생각하고 먼저 첫 시작을 해 봅니다.
일반적인 소프트웨어/서비스 기업의 제품이나 서비스를 실제 개발하고 출시는 그 그룹의 엔지니어링 그룹이 담당을 하고 회사에 따라 그 그룹을 R&D, 개발부서, 혹은 프로덕트 그룹이라고 합니다. 그리고 그 그룹에는 <프로덕트 리더십>이라는 그룹이 존재를 합니다. 어떤 형태의 이름으로 존재하던, 그 <프로덕트 리더십> 팀은 실제 제품의 상세 기능을 설계, 기획하고 개발하는 프로덕트 매니지먼트와 개발팀의 상위에 존재를 합니다. 그 ‘프로덕트 리더십’의 구성인원은 회사에 따라, 그 크기, 회사 문화, 회사 프로세스에 따라서 다르고 그 책임의 한계도 다를 수 있습니다.
스타트업의 경우라면 CEO가 프로덕트 리더의 역할을 하고 있을 수 있습니다. 조금 큰 기업이라면 프로덕트와 디자인 담당 그룹의 VP나 Director들이 담당하고 있거나, 아니면 엔지니어링 매니저, 프로덕트 마케팅 매니저들이 담당할 수도 있습니다. 여기서 중요한 점은 누가 그 ‘프로덕트 리더십’을 구성하고 있는지가 아니라, 그 그룹이 어떤 역할을 담당하고 어떤 결과물을 산출하냐에 있다는 것입니다. 이 부분은 상대적으로 매우 명확한 편입니다.
명확하다는 면은 프로덕트 리더십과 프로덕트 매니지먼트의 경계를 확실히 하는 데서 시작을 합니다. 프로덕트 리더십의 구성원들이 모두 회사 인사 라인의 상위에 있을 필요는 없습니다. 그러나 분명 제품의 사이클을 결정하는데 상위에 있어야 함은 분명합니다. (일반적으로는 VP, CPO- Chief Product Owner, GPM- Group Product Mananger, CPA-Chief Product Architect 라는 업무 타이틀을 가진 구성원들입니다 ) 이 말을 다시 풀어서 해 보면, 각 제품/서비스의 기능을 정의하고, 구현 방법을 지휘하는 각 프로덕트매니저의 역할과는 다른 상위의 역할을 담당해야 하는 그룹입니다.
그 프로덕트 리더십 그룹의 책임 역할은 다음의 3가지로 정리할 수 있습니다.
I. 프로덕트 제품/서비스의 방향을 결정합니다.
II. 프로덕트 팀을 구성하고 조직합니다.
III. 제품/서비스를 출하하기 위한 프로세스를 만듭니다.
1. 제품/서비스의 방향을 결정한다.
시장이나 고객의 니즈를 충족시키면서(meet customer needs), 경쟁 제품과 확실한 차별화를 하고(differentiate), 회사 사업을 지속 가능하게(enable a viable business) 성공적인 제품을 만들기 위한 매일매일의 고민은 기업 전체의 제품/서비스의 방향과 일치해야 합니다. <프로덕트 리더십>팀의 첫 번째 역할이 바로 이런 제품/서비스의 방향을 올바르고 투명하게 그래서 모든 그룹원들의 이해도가 동등할 수 있도록 결정하는 일입니다.
아마도 백 마디의 말보다 아래의 그림 한 장의 설명이 훨씬 이해가 쉽지 않을까 생각합니다.
처음에 이 다이어그램을 생각할 때는 위에서 아래로 내려오는 수직적인 흐름을 생각해 보기도 했으나 그것보다는 수평적인 흐름이 더욱 맞을 것 같다는 생각을 하였습니다. 이 방향 역시, 흐름이고 프로세스이기에 바통을 주고 받는 프로세스로 인식하는 게 더욱 맞을 것 같습니다.
1) 비전, Product Vision
제품/서비스의 방향성의 시작은 제품의 ‘비전’을 만드는 일부터 시작을 합니다. 만약 기업이 스타트업이거나, 기업이 단일 제품/서비스만을 행하고 있다면 아마도 회사의 ‘비전’이나 ‘미션’과 동일할 수 있습니다. 제품/서비스가 여러 개 있는 기업인 경우라면 이 해당 제품/서비스를 통하여 ‘장기적이고 지속적으로 고객에서 어떤 가치를 제공할지’에 관해 기술을 하는 것이 ‘비전’이 됩니다. 여러 개의 제품/서비스를 가진 경우, 서로 간의 연관성의 상위 개념을 도출하여 기술할 수도 있습니다.
2) 전략, Product Strategy
‘비전’이 매우 추상적일 수 있다면, 이제는 조금 계획적이고 가장 중요한 단계입니다. 전략의 기본에는 ‘승리 win’일 수밖에 없고요. 그 승리의 개념에 맞게 winning plan을 짜는 과정입니다. 그 전략은 일반적으로 큰 변화가 없는 이상 제품/서비스가 출시되기까지는 변화가 없습니다. 그 내용에는 반드시 다음의 3가지 내용은 기술되어야 합니다.
- 제품/서비스의 가치가 고객에게 어떻게 전달될것인지
- 경쟁사의 제품과는 어떤 차별화를 가져갈 것인지
- 비즈니스 모델 ( 타겟 고객층은 누구이고, 시간이 지남에 따라서 어떻게 확장이 되는지)
3) 로드맵, Product Roadmap
전략이 나왔으니, 그것에 따라서 제품/서비스가 갖춰야 할 테마의 우선순위를 정하고, 그 테마의 출시 시기를 정해야 합니다. 여기에서 중요한 점은 ‘기능’이 아닌 ‘테마’라는 워딩에 주목해 주십시오.
이 글을 읽으신 분이 주신 피드백으로 ‘테마’에 대한 설명을 추가해 봅니다.
‘테마’에 생소하실 수 있으니 조금 부가 설명을 해 봅니다. ‘테마’라고 하는 것은 여러분이 고객에게 제공할 제품/서비스 내의 특정 ‘기능에 기반한 결과’를 약간은 추상적일 수 있으나 비전보다는 훨씬 더 구체적인 전략으로 표현한 것입니다. 설명을 위한 설명이 더 어렵게 느껴지실 테니, 예를 들어서 설명드리겠습니다.
<AWS integration> 테마의 예입니다.
“현재의 On-premise 방식의 제품을 클라우드 형태로 바꾸면서 AWS위에서 동작하도록 하자”라고 정했습니다.
<소셜미디어 acquisition>또한 테마의 예가 될 수 있습니다.
“이번 제품/서비스의 특정 기능에 소셜미디어와 연계하여 사용자를 증가시키자”라고 정할 수 있습니다.
<프로덕트 리더십>팀은 실제 제품/서비스 내의 특정 기능의 구현 원리는 잘 모르는게 당연하지만, 시장에서의 ‘winning game 플랜’에 대해서는 충분히 연구와 검토를 하였기에 이런 테마를 정하고 우선순위를 지정하게 됩니다. 그 후에는 위에서 언급을 했든, 실제 ‘기능/워크플로우’의 구현은 프로덕트 매니지먼트/엔지니어링/디자인 그룹이 구현계획을 내고 우선순위와 딜리버리 기간을 비교해 가면서 로드맵이 작성되게 됩니다.
제품의 기능을 정하고 그것에 따른 동작원리는 ‘프로덕트 매니저, 프로그램 매니저’들의 역할입니다. <프로덕트 리더십>은 다수의 프로덕트가 연결되어 있다면 (예를 들어 MS-Office나 기업 ERP의 경우) 다수의 프로덕트가 함께 추구해야 할 테마를 정하면 실제 각 제품의 PM들이 제품/서비스 안에서 그 테마를 구현하기 위해서 기능을 나누고 동작원리를 구현해 낼 것입니다. 또한 그 테마에 따라 출하 제공 시기를 이야기하는데, 그것은 제품/기업/고객 상황에 따라 모두 다르게 구성됩니다.
4) 목표치 설정, OKRs
요즘 세계적으로도 가장 인기있는 책 중에도 이 부분에 관한 것이 있습니다. 흔히 Goal Setting 혹은 OKRs – Objectives and Key Results 라고 이야기하고 목표치 설정이라고 해석을 하지만, 그보다는 많은 뜻을 내포하고 있습니다. 시장과 고객, 경쟁사를 분석하여 목표치를 설정하고, 그것에 해당하는 결과치를 어떤 가중치로 어떻게 해석할것인가를 함께 포함하고 있습니다. 일반적으로 3-6개월 마다 목표 조정회의 calibration meeting 통해서 목표치를 조정해 나갑니다. 이 OKRs 과정과 조정 미팅은 항상 서로간의 상황을 더욱 더 잘 파악하기 위한 리더십팀과 실제 개발및 디자인 PM그룹간의 협상프로세스 negotiation process이지 상위에서 하위로 통보나 전달과정이 아닙니다.
5) 커뮤니케이션, Communication and Feedback
이전의 프로세스를 마무리 짓는 단계입니다. 먼저 세운 비전, 전략, 로드맵, 목표치들을 프로덕트 매니지먼트, 개발, 디자인과 공통서비스 (shared services 혹은 cross-function 이라고 부릅니다)를 제공하는 팀들에게 일관적이고 투명하게, 충분히 반복해서 전달합니다. 이 커뮤니케이션의 모든 구성원이 같은 이해도를 갖도록 하는 것이 최고의 목표입니다. 그래야만 각 기능 그룹에서 만들어지는 작지만 중요한 결정들이 큰 목표치들과 차이가 없게 됩니다.
또한 중요한 점은 이 커뮤니케이션은 일방이 아닌 양방향 bi-directional 이어야 합니다. 프로덕트 리더십은 프로덕트의 배경context과 발전 방향 evolution 에 대해서 가장 통찰력이 있는 그룹이기에, ‘피드백과 안내 feedback and guidance’ 라는 리뷰 과정을 통하여, 각 제품의 품질과 기능을 책임지는 PM, 개발 매니저, 디자이너들과 꾸준히 프로덕트의 디렉션을 맞춰 나갑니다.
2. 팀을 구성하고 조직한다.
위에서 정리한 제품/서비스의 방향과 기준점, 측정 방법을 마치고 나선 실제 그에 따른 액션이 필요합니다. 가장 첫 번째 해야 할 액션은 그 정리한 방향을 실행에 옮겨 줄 구성원을 갖추는 일부터 시작합니다.
그럼 어떤 <프로덕트 리더십>은 어떤 구성원을 조직해야 위에 액션들을 실행할 수 있을까요? 그건 기업의 크기와 환경에 따라 모두 정답이 없이 다를 것입니다만, 일반적인 경우엔 다음과 같은 3가지 축이 필요합니다.
- 프로덕트/프로그램 매니지먼트
- 디자인 매니지먼트(UX, 리서치 포함)
- 엔지니어닝 매니지먼트
팀의 구성원을 선발하기 위해 <프로덕트 리더십>은 그 팀원이 갖추어야 할 소양과 경험을 오픈하고, 어떻게 팀을 구성하고 인터뷰 프로세스는 진행할 것인지, 어떤 문화로 일을 진행할 것인지를 커뮤니케이션합니다. 후보자들이 추려지고, 팀 리더들이 갖춰지면, <프로덕트 리더십>은 충분한 시간-일반적으로 3박 4일 정도의 오프사이트 미팅 등으로-동안 1번 ‘제품/서비스의 방향’에서 정의한 배경과, 방향, 측정방법등에 대해서 충분히 팀리더들에게 커뮤니케이션을 합니다. 이 시간의 메인 결과물은 <프로덕트 리더십>과 <팀 리더, 팀 멤버> 간의 프로젝트에 관한 생각의 차이가 없도록 하여, 팀 멤버 각자가 이번 제품/서비스 릴리즈에 어떤 책임을 갖고 있는지를 명확하게 알려주도록 하는 것이 목표입니다. 또한 단순한 책임 완수뿐만이 아닌, 이 기간 동안 기업의 목표를 따라 개인의 능력이 함께 성장하고 좋은 평가가 된다는 사실을 명확히 커뮤니케이션하는 것 또한 매우 중요합니다.
세 번째로 해야 할 일은 올바른 문화를 만드는 일입니다. 문화는 그다음에 “프로세스”로 나타나게 됩니다. 지금은 프로세스를 세팅하기 전에, 왜 그렇게 하는 것이 조금 더 효율적이고, 좋은 것인지를 알게 하는 우리만의 기업/제품/개발 문화를 만드는 것입니다. 예를 들어, 테스트 성공과 실패를 가르는 허용 기준을 정한다 든지, 피드백을 적극적으로 구하고, 문제점을 오픈하고 크로스팀으로 함께 해결하는 것에 우선순위에 둔다든지, 실제 고객 중심 프로세스와 데이터로 테스트해야 한다는 마인드라든지 등, 이런 문화를 만들고 구성원들로 부터 동의를 얻고 나면, 나중에 실제 개발/운영팀으로 부터 산출되는 “프로세스”는 매우 자연스럽게 적용되고 스스로 베스트 시나리오를 찾아가게 됩니다.
3. 제품/서비스 출하를 위한 팀간의 업무 프로세스 정의
<프로덕트 리더십>에서 말하는 프로세스는 실제 업무를 수행하는 데 필요한 operational excellence를 구축하기 위한 프로세스는 아닙니다. <프로덕트 리더십>이 세팅해야 하는 프로세스는 이 제품/서비스를 위해서 여러 팀이 함께 일할 때 어떤 구조를 가질 것인가에 관한 것입니다. 즉 가장 쉽게 이해되는 부분은 “보고라인 reporting lines” 일 겁니다. 이 리포팅 라인에는 상황에 따라서 기능적으로, 아니면 시간의 순서에 따라, 혹은 우선순위에 따라 모두 다를 수 있습니다. 매우 일반적인 보고라인은 개발자는 개발매니저에게, 디자이너는 디자이너 매니저에게, PM은 상위 PM에게 보고를 하지만, 제품/서비스를 만드는 프로젝트가 시작이 되면, 상호간에 업무내용/진행사항/결과들이 유기적으로 공유되고 보고되어야 합니다. 장교도 필요하고, 참모도 필요하죠. 그 전체 흐름을 정의하는 것이 <프로덕트 리더십>의 역할이고 책임입니다.
두 번째로 <프로덕트 리더십>이 정의해야 할 프로세스는 각각의 팀 (개발, 디자인, PM)의 범주를 넘어서는 것들입니다. 예를 들어 제품/서비스의 개발 라이프사이클입니다. 매우 정밀한 레벨까지는 필요하지 않지만, 제품/서비스의 출하시기와 그 단계 (예를 들어, 리서치-디스커버리-디자인-개발/테스팅-릴리즈매니지먼트)를 정의하고 각각의 게이트키퍼 gate keeper-어떤 툴을 기준으로 어떤 측정치로 통과여부를 결정하는지-의 기준을 마련해야 합니다.
세 번째는 기업 내의 다른 조직과의 연결성을 정의합니다. 프로덕트 마케팅과는 누가 어떤 관계성을 갖고, 고객지원팀, 세일즈 팀과는 누가 어떻게 소통을 할 것인지를 정의합니다. <제품그룹: 개발, 디자인, PM>은 정해진 시간에 정해진 기능을 갖는 제품/서비스을 릴리즈하는데 최대한 집중할 수 있도록 외부와의 연결성을 명확하게 정의합니다.
글의 처음에서 말씀드렸듯, 요즘의 많은 소프트웨어/서비스를 만드는 기업에서는 프로덕트 매니지먼트의 필요성과 중요도를 알아가는 상태이지만, 이 부분을 더욱더 명확히 알기 위해서는 그전에 <프로덕트 리더십>이란 상위그룹에서 어떤 과정을 고민하는지를 이해하는 것이 필요하다고 판단이 되어 작성해 본 글입니다. 이제는 프로덕트 매니지먼트가 어떤 일을 어떻게 하는지를 설명드려도 조금은 쉽게 전달되지 않을까 하는 느낌입니다. 다음 글부터는 프로덕트 매니지먼트에 대해서 기술해 보도록 하겠습니다.
읽어주셔서 감사드립니다.
