PM이 갖춰야할 지식, 공부 기록1
프로덕트 매니저로 성장하기 위한 공부를 기록 합니다.
<오늘의 참고 도서>
프로덕트 : 유저를 사로잡는 서비스 기획의 모든 것 _ 홍석희
인스파이어드 감동을 전하는 IT 제품은 어떻게 만들어지는가? _ 마티 케이건
1. 프로덕트 매니저가 머야?
요즘 주변에서 프로덕트 매니저 / 프로덕트 오너 (PM/PO) 라는 말은 많이 들어 볼 수 있습니다. 물론 프로덕트 매니저라는 직무가 생소한 사람들도 많을 것이다!
그 이유는 최근 IT 분야의 수요가 급증하면서 PM / PO 역할이 중요해지고 있기 때문입니다.
조금 지루할 수 있지만
역사적으로 프로덕트 매니저의 탄생 배경을 짧게 살펴보면
왜 오늘날 PM이라는 직군이 꼭 필요해졌는지 알 수 있습니다.
(참고로 각 년도별 등장하는 단어나 사건에 대해 상세히 설명을 하고 있지 않습니다. PM의 등장에 대해 설명하기 위한 내용임으로 흐름만 이해하면 좋을 것 같습니다 :D)
과거 1930년대, 닐 맥엘로이(P&G의 전 사장)의 메모에서 "Brand Man"이 등장했습니다.
브랜드 맨은 "왜 제품이 안 팔렸는지 분석하기 문제를 개선하는 사람"을 말합니다.
즉, 브랜드와 고객 사이의 사이를 좁힐 수 있는 존재입니다.
브랜드 맨의 단어를 시작으로 제품의 문제를 해결하는 전문가가 등장하였습니다.
1940년대, HP에서 "cross-functional team"이 등장했습니다.
이로써, 하나의 브랜드 아래 역할이 다른 팀원들로 (엔지니어, 디자이너, 기획자) 구성된
최초의 제품 전담팀이 등장했습니다.
1950년대, 도요타에서 "just in time system" , 도요타 생산 시스템이 등장했습니다.
이는 제품 생산에 혁신을 발생 시켰습니다.
참고로 JIT는 낭비요소가 최소화된 효율적인 생산의 운영 및 통제 시스템을 말합니다. 철저한 현장주의에 의해 만들어졌다는 점에서 기본적인 사고 방식은 "개선과 답은 현장에 있다"에서 출발합니다.
1960년대, 시대가 변화하며 상품의 공급과 수요가 늘어남에 따라 "4P" 마케팅 믹스가 사용되기 시작하였습니다.
우리가 잘 알고 있는 product, place, promotion, price 의 첫 등장입니다.
1970년대, 컴퓨터 산업이 등장하며 개발 관리의 필요성이 대두되기 시작합니다.
1980년대, '고객 중심사고' 제품 전문가가 등장하였습니다.
1990년대, 최초의 퍼스널 컴퓨터가 등장하고 소프트웨어 개발자라는 직군이 생겨났습니다.
이때 고객과 프로그래머의 중간 다리 역할을 하는 프로그램 매니저가 등장했습니다.
프로그램 매니저는 마케팅 팀과 개발팀의 연결고리가 되어주는 사람이었습니다.
2000년대, 소프트웨어의 크기가 커졌다. 기존의 무겁고 규범적인 방법론에서 탈피하여 근본적인 문제를 해결하기 위한 'Agile 선언'이 발표되었습니다.
이 때, 현대적인 PM역할이 자리잡게 되었습니다.
즉, 우리가 알고 있는 프로덕트 매니저는
역사적, 시대 사회적 흐름 속에서 보았을 때 산업이 발달되고 사회가 고도화 되면서
효과적인 제품관리를 위해서 등장하게 되었습니다.
제품과 관련된 모든 분야를 관리하는 전문가의 역할이 분명해지고 필요해졌기 때문이다.
1-1. 프로덕트 매니저(PM)은 사업가치와 고객가치라는 결과를 창출하는 사람이다.
프로덕트 매니저는 사용자의 니즈를 꾸준히 파악하면서 기업의 비즈니스 가치도 높이는 방향으로 제품과 서비스를 개선합니다.
즉, 사용자의 문제와 니즈를 이해하고 다음에 구축하려는 것이 사용자에게 적합한지 확인한 후 다양한 이해관계자를 적절히 활용해 실제로 구축될 수 있도록 도움을 줍니다.
프로덕트 매니저란?
- 함께 만들어야 할 것을 기획함으로써 사업가치와 고객가치라는 결과를 창출하는 책임을 가진 사람
- 초기 아이디어 단계부터 제품 출시를 총괄하는 담당자
(출처 : codestates)
- 사용자와 비즈니스가 가진 문제를 파악하고 가설을 세워 해결하는 역할
(출처 : 프로덕트 : 유저를 사로잡는 서비스 기획의 모든 것_홍석희 )
1-2.프로덕트 매니저는 팀과 함께 무엇을 어떻게 만들지 고민합니다.
프로덕트 매니저는 팀과 함께 무엇을 어떻게 만들지 항상 고민해야 합니다.
어떤 제품을 만들 것인가?
어떻게 만들 것인가?
위의 질문에 대한 답변을 찾아가기 위해서는 2가지를 고려 해야합니다.
첫번째, 사용자와 시장에 대한 고민입니다.
우리가 만들고자 하는 프로덕트는 사용자와 시장에서 시작됩니다.
프로덕트 매니저는 사용자의 문제를 발견하고 해결해주기 위한 무언가를 만드는 사람입니다.
중요한 건,
사용자의 문제를 표면으로만 바라보는 것이 아닙니다. 사용자의 문제의 내면을 더 깊숙이 알아낼 수 있도록 노력하고, 해결책을 실제 프로덕트로 만들어 개발 해야합니다.
이 때 발견한 문제와 해결방법은 처음엔 가설의 상태이기 때문에 다양한 방법을 통해 여러번의 검증을 받는 과정이 필요합니다.
(이 때, 가설을 검증하기 위해선 정성 데이터와 정량 데이터 2가지를 이용하게 되며, 이 데이터를 잘 활용하기 위해 데이터 수집 및 분석 방법에 대한 이해도가 필요합니다. 이는 추후의 포스팅에서 이야기 해보겠습니다!)
또한 프로덕트 매니저는 사용자 뿐만 아니라,
시장도 항상 고려해야합니다.
완전히 새로운 프로덕트를 만들거나 프로덕트의 일부를 개선하는 상황 모두 개개인의 행동과 그 개인이 모인 집단인 시장을 고려해야합니다.
초기에는 "이 프로덕트를 사용하는 사람이 있을까" 라는 생각을 점점 개선해 나가게 되며, 이러한 반복을 통해 프로덕트를 개선해나아가다 보면 많은 사용자들을 불러들이는 시점을 찾게 됩니다.
우리는 이 시점을 PMF(Product-Market Fit / 제품시장적합성)라고 말합니다.
프로덕트 매니저는 프로덕트가 시장의 요구와 기대에 부응할 수 있도록 만들 수 있어야 합니다.
두번째, 동료와 팀에 대한 고민입니다.
사용자의 문제를 효과적을 해결해줄 수 있는 프로덕트를 실제로 사용자에게 전달하기 위해서는
팀과 동료들이 있어야 합니다.
프로덕트 매니저는 팀을 이뤄 프로덕트를 만듭니다.
다양한 직군의 팀원들과 한 팀을 이뤄 같이 일하는 경우가 대다수 입니다. 이를 "프로덕트 팀"이라 부릅니다.
(프로덕트 팀이란? 한가지 상품이나 카테고리를 맡아 PO/PM 중심으로 개발자와 디자이너로 이루어져 있는 팀을 말합니다.) 즉, 사용자가 원하는 프로덕트를 만들기 위해서는 하나의 팀 안에서 다양한 직군의 팀원들과 협업을 해야합니다.
일반적으로 프로덕트 매니저는 크게 엔지니어와 디자이너 팀원들과 협업을 하게 됩니다.
이때 프로덕트 매니저는 팀원들과 원활한 커뮤니케이션을 위해 IT 지식, 트렌드, 도메인 지식, 기술스택을 습득해야합니다. 그래야만 팀원들과 함께 빠르고 정확하게 원하는 제품을 만들어낼 수 있습니다.
더 나아가 PM은 사용자가 감동하는 제품을 만들기 위해선 좋은 프로덕트 팀에 대해 고민해보아야 한다고 생각합니다.
스스로가 좋은 프로덕트 팀이 무엇인가, 좋다는 기준은 무엇인가 그렇다면 나쁜 프로덕트 팀은 무엇이지? 등 프로덕트 팀에 대한 고민과 생각을 할 때 도움이 되었던 책인 '인스파이어드' 의 일부 내용을 공유해봅니다.
(참고로, 해당 책은 좋은 프로덕트 팀이 무엇인지, 또 나는 어떤 PM이 되어야할 지.. 저의 다양한 물음에 좋은 가이드가 되어 주었습니다.)
- 좋은 팀은 강렬한 제품 비전이 있고, 그들은 마치 선교사와 같은 열정을 추구한다.
- 좋은 팀은 그들의 비전과 목표, 고객 불편의 관찰, 제품을 사용하면서 고객들이 만들어 낸 분석 데이터, 문제를 해결하기 위해 새로운 기술을 끊임없이 탐색하는 과정을 통해 영감과 제품 아이디어를 얻는다.
- 좋은 팀은 그들의 핵심 이해 관계자들을 이해하고 있으며, 그들이 겪고 있는 제약사항을 잘 알고 있다. 이를 통해 사용자와 고객에게만 효과적인 솔루션이 아닌 비즈니스 제약 조건속에서도 유효한 솔루션을 찾아내는데 최선을 다한다.
- 좋은 팀은 어떤 아이디어가 진정으로 만들 만한 가피가 있는지를 결정하기 위해 빠르게 제품 아이디어들을 시도해 볼 수 있는 만흔 기법에 능숙하다.
- 좋은 팀은 제품 관리자, 제품 디자이너, 엔지니어가 함께 모여 앉아서 기능성/사용자 경험/가용 기술에 대해 서로 주고받으며 포용한다.
.
.
.
(일부 생략)
오늘은 간단히 PM가 어떤 일을 하고, 어떤 고민을 하는지에 대해 짧게 적어보았습니다.
물론 너무 간결하게 민망하기도 하지만 오랜만에 글을 써보니 예전에 부트캠프 생각도 나고... ㅎㅎ 즐거운 시간이었습니다.
앞으로는 실무적인 이야기와 이론적인 이야기를 함께 혼합하여 기록을 남겨보겠습니다.
