PM이 뭔데? 내가 되고 싶은 PM은?
지극히 개인적인 PM에 관한 이야기
PM이라는 단어를 내가 처음 접해본 지는 불과 반년이 채 되지 않았다.
처음엔 그냥 IT 업계에서 흔히 말하는 기획자, 개발자, 디자이너 중에서
기획자를 다르게 부르는 말인줄 알았다.
2학년을 마치고 군대에 들어간 뒤로부터 나에게는 어떠한 꿈이 생겼다.
그러나 그것은 내가 아는 단어들로는 설명할 수 없는, 누군가에게 말로 표현할 수 없는 꿈이었다.
그렇게 막연하게 창업과 개발, 인문학적 소양, 리더쉽과 같은 개념들 사이에서 표류하던 내 꿈의 정의에
한발짝 다가가게 해준 것이 바로 3학년 여름방학에 동아리에서 진행한 프로젝트였다.
지금 생각해보면 정말 아무것도 몰랐지만 PM이라는 직책을 처음 경험한 프로젝트에서
나는 PM이 필요한 역량이 무엇인지를 어렴풋이 가늠할 수 있었다.
왜냐하면 개발을 제외한 나머지 내가 해야하는 일들, 그러니까 내가 못하는 모든 일들이 모두
PM의 역량에 포함되는 일들이었으니까.
그렇게 프로젝트를 진행하면서 내 꿈의 정의가 좀 더 또렷해진 것을 알았다.
내가 하고 싶은 일, 내가 이루고 싶은 꿈이 정확히 뭔지는 아직 모르겠다.
그러나 확실한 건 PM이 되고자 노력하고 공부할 수록, 그 꿈에 가까워질 것이라는 생각이 든다.
그렇기에 나에게 PM은 내 꿈에 다가갈 수 있는 수단이다.
PM의 역사
PM은 직무가 아닌 역할이라는 이야기가 있다.
전쟁에 있어서도 PM처럼 물자, 전술 등을 계획하고 관리하는 역할이 있을 것이다.
따라서 PM의 역사는 유래가 깊다고 할 수 있다.
여기서는 현대적 의미의 PM의 역사에 대해서 알아보자
1930년대
닉 멕엘로이가 1931년에 남긴 메모에는 "Brand man"이라는 개념이 등장한다.
이 "Brand Man"을 현대적 의미의 PM의 시작이라고 보는 의견이 많은 듯 하다.
P&G의 회장, 국방부 장관, 스탠포드의 조언자로서 활약한 그가 "Brand man"에 대해
남긴 내용을 풀어쓰면,
- talk to customers and uncover their pain
- develop a product that solves the problem
- create a channel strategy and sales collateral to sell the product
- track the right metrics, iterate, and drive profitability
와 같다.
현대적 PM의 기원이라고 보는 이유를 알 것 같기도 하다.
1940, 50년대
휴렛과 패커드는 닉 멕엘로이를 멘토로 둔 기업가로서, 각자의 이름을 딴 HP를 설립했다.
그들은 "Brand Man"의 의미를 제품의 모든 측면에서 고객의 입장을 대변하는 사람으로 재해석했다.
토요타는 필요한 것을 필요한 때에 필요한 만큼 만든다는 JIT(Just In Time) 원칙을 제시했다.
'간판'이라는 뜻의 '칸반'시스템을 이용했다.
1960년대
이때부터의 제품은 IT 제품이 주류를 이루기 시작함.
그동안은 하드웨어 제품이었기 때문에 유지보수등의 개념이 희박했고, 프로덕트 자체보단
가격과 홍보전략에 집중하는 경향이 있었다.
그러나 개발 프로젝트의 빈도와 중요성이 커지고 규모가 커지면서 애자일 기법이 등장했다.
이때 현대적의미의 PM이 등장했다.
PM이란?
PM이란 기술에 대한 이해 뿐 아니라 사용자, 비즈니스에 대한 이해를 하고 있는 팀원이어야 한다.
특히 나의 경우 개발자로서 공부를 해왔고 IT Product에 대한 PM을 꿈꾸고 있기 때문에 특히나
사용자와 비즈니스에 대한 이해가 필요하다는 점이 와닿는다.
그래서 내가 생각하는 IT Product의 PM은
Application 뿐 아니라 Service를 생각하는 사람이다.
Service는 단순히 기능적인, 말하자면 기술과 개발적인 내용 뿐 아니라
사용자와 비즈니스까지 포괄한 단어라고 생각한다.
그렇기 때문에 PM은 단순히 Application의 레벨을 넘어서
Service의 수준에서 생각하고, 고민하고, 중개하는
사람이라고 생각한다.
내가 속한 PM의 유형
PM은 그 도메인마다, 개발 프로덕트마다 하는 일이 크게 유동적이기 때문에
모든 PM이 같다고 볼 수 없다.
그래서 필연적으로 PM의 유형이라는 것이 존재하게 되는데,
나는 어떤 현재 유형이고 어떤 유형이 되고 싶은지 알아보자.
PM의 가장 중요한 역량 12가지를 4가지 분야에 따라 표현한 그래프이다.
여기서 자신이 생각하는 자신의 수준을 표시하면 내가 어떤 유형의 PM인지 확인해볼 수 있다.
사실 나는 개발을 공부하던 사람이었고(빨강), 리더십은 아주 약간 있으며(파랑),
UX에 관심을 가진지 1년이 채 안됐고(노랑), 비즈니스는 거의 문외한이다(초록).
그래서 대충 그래프의 모양을 예상해볼 수 있었고, 그와 비슷하게 나온 것 같다.
(각 역량에 대한 설명을 원하면 https://www.ravi-mehta.com/product-manager-roles/에서
이메일을 제출해 자료를 받으면 된다.)
나는 결과적으로 Product Architect보단 Product Builder이고,
Product Leader보단 Product Manager라는 결과가 나왔다.
또한, PM의 가장 첫 레벨인 APM이 나왔다.
Product Architect VS Product Builder
Product Builders are who can make product.
Product Architects are who design well.
Team needs both Product Builder and Architect. In modern,
Product Architecture is better. If you are Product Architect,
just paring with Product Builder. If you are Product Builder,
not only paring with Architect but also self level-up with Architect competencies.
Product Leader VS Product Manager
PM evolves clockwise starting with Product Execution.
Product Managers build products.
Product Leaders build products, people, and companies.
Throughout evolving, in every stages,
PM must focus on Business Outcome Ownership.
APM
APM(Associate PM) - PM - Sr. PM(Senior PM) - GPM(Group PM)
- Director - Sr. Director(Senior Director) - VP(Vice President)
- CPO (Chief Product Officer) 중 가장 첫단계로,
다른 말로 주니어 PM이다.
말하자면 내 현재수준은, PM중에서도 아주 꼬맹이라는 뜻이다.
Technologist VS Generalist VS Business-Oriented
추가적으로 이와 같은 구분도 있다
나 같은 경우 현재 내 자신도 generalist이며, 내가 되고 싶은 유형도 generalist이다.
내가 되고 싶은 PM
다양한 자료들을 참고하기 전까지, 나는 PM이 모든 걸 잘해야한다고 믿었고
깊이가 있는 generalist라고 생각했다. 그래서 내가 되고 싶은 PM은 모든 방면에서 뛰어난,
그러니까 말하자면 unicorn과 같은 PM이 되고 싶다고 생각했다.
그러나 이는 현실적으로 정말 어렵기도 하고
팀이 모든 역량에서 뛰어난 둥근 모양이면서(round)
PM 자신은 하나가 특히 뛰어난 뾰족한 모양(spicky)인 회사일 수록 실적이 좋다는
내용을 접하고 나서는 생각이 조금 바뀌었다.
나는 모든 역량에서 최소한의 수준을 갖추고 개발/기술/Product에 일가견이 있는
T자형 역량을 가진 PM이 되고 싶다. 아마 나중이 되면 이 목표 또한 변하지 않을까 생각한다.
참고자료
'기타 > 서비스 기획' 카테고리의 다른 글
'스픽' 서비스 역기획해보기2 - 메인 기능 유저 플로우 개선 (2) | 2023.10.09 |
---|---|
'스픽' 서비스 역기획 해보기 0 - 서비스 구조/회사 목표 분석 (0) | 2023.10.09 |
'스픽' 서비스 역기획 해보기1 - 핵심문제/고객 정의하기 (0) | 2023.09.23 |
프로덕트 팀과 개발방법론 (0) | 2023.09.23 |