나는 어떤 프로덕트 매니저 유형일까?
프로덕트 매니저 유형에 대한 테스트 해보기!
서비스기획자에서 프로덕트 매니저로 직무이동을 하면서 매일매일이 같은 것 찾기와 다른 것 찾기다.
지난 4개월의 시간동안 이 차이를 명확하게 구분하고 또 다양한 매체의 공부를 통해서
더 좋은 프로덕트 매니저가 되기 위해서는 어떤 것이 필요한지, 그리고 또 서비스기획자로서 일하면서 가졌던 장점을 무엇인지, 그리고 무엇을 바꿔야 하는가에 대해서 많은 고민을 하면서 지냈다.
스타트업이라는 환경에서 갖춰져야 할 점들도 찾기 위해 노력했다.
그래서 내 결론은 이렇다.
Product Manager에도 유형이 있다!
감사하게도 사내에 다양한 배경의 사람들이 있어서 내가 공부한 부분에 대해서 상의해볼 수 있었다. 스타트업 출신들부터 쿠팡, 네이버, 카카오, 이베이, 11번가 등등 다양한 배경의 PM들이 섞여 있었고 각자의 장단점과 담당하는 프로덕트가 굉장히 달랐기 때문에 내가 생각하는 유형에 대해서도 각자의 위치와 목표를 생각해볼 수 있었다. 그리고 이런 고민을 바탕으로 자신의 유형을 고민해볼 수 있는 테스트 질문 리스트를 뽑아볼 수 있었다.
1. Product Manger 유형 파악을 위한 사전 자료 조사
가장 먼저 PM에게도 유형이 있다고 생각하게 됐던 이유는. 백엔드 프로덕트를 하는 PM들에게는 UX도 중요하지만 '개발 가능여부'를 파악하기 위해서 개발 설계를 잘 하는 것이 굉장히 중요하다는 생각이 들었기 때문이었다. 비즈니스 방향성만 이야기하고 실제 구현 방법에 대해서 고민하지 않고 개발에 넘기게 되면 일정관리부터 시작해서 제대로된 목표 달성을 하는 것에 어려움이 있는 부분들도 있다고 생각했다. 특히나 내가 백엔드 프로덕트를 주로 담당하기 때문에 이러한 생각이 강력하게 들었고, 혹시나 이게 Product Manager들의 표준적인 생각이 아닌가에 대해서 고민했다. Medium의 글들을 탐독하면서 다행스럽게도 해외에서도 이러한 생각을 가진 사람들을 PM들을 어렵지 않게 찾을 수 있었다.
특히 아래의 글을 읽으면서, 개별의 유형화를 해봐도 좋겠다는 생각이 들기 시작했다.
https://theproductdesignblog.com/what-kind-of-product-manager-are-you-2e88eceda9f5
이 글에 나오는 유형을 보면, 나는 당장의 Growth나 디자인 보다는 진짜 사업 구조적으로 앞으로 해나갈 수 있는 사업들이 가능한 백엔드 구조를 만들어 낸다는 점에서 Backend Experienced PM에 가깝다는 생각이 들었다. 그런데 이 표로만은 만족하지 못했던 것은 이 표의 가장 큰 구분이 연차(또는 숙련도)인데 이 부분은 현재 일하는 사람들을 구분하기가 쉽지 않아 보였다. 그래서 새로운 유형화를 위해서 자료를 찾기 시작했다.
그리고 결국 좋은 기준이 되는 글을 하나 찾았는데 바로 이 글이다!! 맥킨지에서 2017년에 실리콘밸리의 Product Manager들의 유형과 역량을 조사한 글인데, 지금 읽어봐도 고개가 끄덕여 지는 부분이 있다.
https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/product-managers-for-the-digital-world
이 글의 내용에서 유형에 대한 부분만 발췌해서 요약해보려고 한다. 원문 번역이 아니라 내 이해를 바탕으로 쓴 것이므로, 더 자세히 궁금하다면 원문을 읽어보길 추천한다.
1) Product Manager의 역할
개발, 디자인, 고객 만족, 세일, 마케팅, 운영, 재정, 법, 등등의 프로덕트의 기능들의 전문가들이다. 무엇을 하겠다고 의사결정을 할 뿐만 아니라 무엇을 어떻게 만들고 런칭할 지 영향을 줄 수 있다.
매일 또는 주별로 기능 릴리즈를 계획하면서 동시에 6-24개월의 로드맵도 계획한다. 단, 길게 요구사항을 먼저 쓰기 보다는 대신에 다양한 기능의 팀들과 밀접하게 일하면서 피드백을 받는 것을 자주 한다.
Software-as-a-service 서비스가 많아지고, MSA 형태의 모듈러된 기능, dev-ops 를 기반으로 한 크로스펑셔널한 조직이 많아지면서 PM의 업무가 급격하게 복잡해졌다. → 상품 생명주기가 놀랍도록 복잡해지며 번들, 계단식 번들가격, 다이나믹 프라이싱, 업셀링, 가격 전략, 구매 후 업그레이드, 동시에 플랫폼 형태의 에코시스템의 발전은 비즈니스까지 고려하게 됨. 기술적으로 API도 프로덕트의 일환으로 보게 됐다. 또한 여전히 고객 중심적인 사용메트릭과 사용자 공감 능력에 집중하여 product를 설계해야한다.
2) Product Manager의 종류
단, 데일리로 개발자의 실행을 챙기는 역할은 엔지니어링 매니저, 프로그램 매니저, 스크럼 매니저가 대행한다. 이렇기 때문에 PM은 12명 이상의 개발자와 한번에 일할 수 있다.
technologist, Generalist, Business-Oriented 3가지 종류의 PM이 나타나면서 기존의 Project Manager 들은 사라져 가는 추세. (Project Manager 는 요청을 받아서 프로젝트만 리드하는 업무)
A. technologist
- 매우 시스템과 기술적인 부분에 중심적
- 기술적인 해결책을 중요시함
- 백엔드 플랫폼 또는 굉장히 복잡한 B2B 프로덕트를 운영한다. 가끔 목표 메트릭에 연결되지 않은 "쿨한 아이디어"에 대한 기술적 리스크를 감수하기도 한다.
B. Generalist
- 기술적 깊이와 더불어서 비즈니스에 대한 실전적 지식 중심
- 사용자 만족이 제일 중요
- 최종 엔드유저에 대한 메트릭을 성장시킬 수 있는 가능성을 측정하여 실행한다.
- B2C 서비스 또는 B2B의 프론트엔드 서비스
C. Business- Oriented
- 비즈니스 배경 지식 중심
- 특정한 비즈니스 메트릭을 극대화 시키는 것에 집중
- B2C 서비스가 가진 자산을 이용해서 창의적인 새로운 비즈니스를 생각해낼 수 있는 프로덕트에 필요
⇒ 아마존과 알파벳(google), 페이스북 등 유명 회사들은 테크놀로지스트와 제네럴리스트 쪽에 포진되어 있음. 이 중에서 AWS나 VMware처럼 프로덕트가 좀 더 기술적이고 어드민처럼 생기거나 API 중심적인 것은 테크놀로지스 유형의 PM이 적합. 페이스북과 링크드인처럼 B2C 서비스는 제네럴리스트 중심이 적합.
3) Product Manager의 유형별 고객에 대한 접근 방식
- 고객중심의 사고 방식은 모든 유형에 공통적이다.
ㄱ. 아마존의 6페이지 메모에서는 기능에 대한 고객들의 생각과 추후 반응에 대해서 먼저 작성하도록 함
ㄴ. technologist 유형인데도 비즈니스적으로 중요한 업무를 할 수도 있다.
(다만, Business-Oriented 유형의 PM이 feasibility를 중요시하는 프로덕트를 맡지 않을 뿐)
- 유형별로 고객에 접근하는 방식에는 차이가 있는 것으로 보인다.
ㄱ. technologist : 다른 개발자들과 업계 컨퍼런스에서 대화를 하면서 시간을 나누거나 매체를 통해서 인식을 선호
ㄴ. Generalist : 고객들을 직접 인터뷰하거나, 영업팀과 대화를 해보고, 유저사용에 대한 메트릭을 리뷰하면서 판단하는 것을 선호.
ㄷ. Business-Oriented : (원문에는 기술되어 있지 않으나, 타겟 시장크기를 더 중요시 할 것으로 보인다)
4) Product Manager로서 유형의 의미
- PM에게 중요한 3가지 면인 비즈니스(이익창출), 기술(feasibility), UX(고객분석,경험관리)은 각 유형에게 더 중요한 부분이 있는 것으로 보인다.
- 이러한 부분은 어떤 프로덕트 또는 어떤 회사에서 일하고 있느냐에 따라서 적합한 유형이 있을 수 있다.
-> 즉, 로테이션을 통해서 3가지 부분을 모두 균등하게 탐구할 수 있도록 하는 것이 중요하다.
2. Product Manger 유형 파악을 위한 질문지
이 글을 읽고, 개별적으로 3가지 유형중 어느쪽에 가장 가까운지 스스로 간단히 파악해볼 수 있는 문장들을 만들고 점수화 할 수 있도록 했다.
1) PM 유형 테스트 : 각 유형의 특징 대한 설명을 읽고 1-9 점 중 가장 가까운 곳에 체크해주세요.
각자 자신의 위치와 지향점에 대해서 생각해보자 : 이를 통해서 추구하는 프로덕트의 방향성을 가늠할 수 있다.A. 테크놀로지스트 특징
나는 새로운 프로젝트를 시작할 때 기술 구현 가능 여부부터 생각한다.
나는 UI 설계 보다 백엔드 프로세스에 대한 정책 설계가 더 재미있다.
성과를 정확하게 측정할 수 없어도 구현할 수 있으면 만들어 보는 것도 나쁘지 않다고 생각한다.
고객의 행동에 대해서 추정할 때, 시간이 없으면 업계의 상식적인 방향으로 추정할 때가 더 많다.
나는 시스템 개발 구조에 대해서 잘 알고, 개발자와 자연스럽게 구조에 대해 논의할 수 있다.
B. 제너럴리스트 특징
고객에게 불편하다면 반드시 해결해야한다고 생각한다.
나는 고객이 직접 다루는 프론트엔드 화면 UI를 기획하는 것이 더 재미있다.
개발 편의와 안정성을 위해서 고객이 불편해지는 정책을 진행할 수는 없다.
고객에 대해서 분석하려면 반드시 행동 지표를 봐야한다고 생각한다.
C. 비즈니스 오리엔티드 특징
경쟁우위 전략이나 SWOT 분석, 매출 목표 등의 경영분석에 관련된 내용이 편안하다.
지금 담당하는 서비스의 매트릭을 높이기 위해서 낸 아이디어의 구현에 대한 부분은 개발자의 몫이라고 생각한다.
기존의 사업을 지속 발전시키고 운영하는 것보다는 새로운 사업범위를 확장하는 것에 관심이 많다.
서비스를 판단하기 위해서 가장 중요한 지표는 매출과 M/S 등의 지표다.
마이크로한 UI 나 시스템 프로세스 보다는 해야하는 최종적인 목표를 더 잘 정리한다.
당신은 어떤 유형의 Product Manager 인가요?
이 테스트를 팀내의 다양한 PM들과 진행하면서, 각자 원하는 지향점과 현재의 역량이 다른다는 것을 많이 느낄 수 있었다. 예상한대로 고객 사이드의 프론트엔드를 다루는 입장일수록 Generalist에 가까웠고, 백엔드를 많이 다루고 있을 수록 Technologist에 가까웠으며, 비즈니스 방향성에 초점을 맞추는 PO의 역할을 하고 있는 경우 Business-Oriented 유형에 가까웠다. 그리고 각자 원하는 비전에 따라서 지향점도 굉장히 달랐다는 점이다.
물론 이 평가표에는 한계가 있다. 왜냐하면 한 사람이 항상 하나의 유형으로 일하는 것은 아니기 때문이다. 담당하는 Product의 성향과 형태에 따라서 완벽하게 다른 유형으로 변신해야할 수도 있다.
그럼에도 이러한 자신의 Product Manager 유형 체크가 의미하는 것은, 본인이 하고 있는 product와 자신의 역량이 일치하는지에 대해서 체크해보고 또 그 방향으로 제대로 가고 있는지도 확인해보는 좋은 기회가 되기 때문이다. 특히 나처럼 서비스기획자에서 Product Manager로 전향한 경우, 업무의 스킬과 업력에서 차이는 많이 느끼지 않으나 업무적 방향성을 직접 설정해야 한다는 차이를 느끼고는 하는데 이 부분에서 자신이 가지고 있는 역량을 잘 파악할 수 있는 기회가 되기도 했다.
이 글을 보는 분들도, 한번 이 테스트를 곰곰히 살펴보면서 자신의 PM 유형을 파악해보고 현재와 지향점을 짚어봤으면 좋겠다.
댓글로 자신의 PM유형을 남겨주세요:)
