마에스트로와 잡부 사이 어디, PM
Product Manager의 본질에 대한 단상
PM이라는 요상한 직업
처음 IT 업계에 발을 담근 10년 전에만 하더라도 쉽게 볼 수 없는 직업(또는 직군)이었다. 프로젝트를 매니징하는 것과는 다른가? 걔들도 Project Manager라고 해서 PM이라고 했던 것 같은데. 제품 관리자라는 것이 어떤 의미이지? 어떤 것을 준비해야 PM이 될 수 있는가? 서비스 기획자와 어떤 차이가 있는 거지?
PM에 대해서 찾아보면 슈퍼맨이다.
그래서 때로는 자조적인 말로 잡부라는 말도 쓰고, PM은 "필요(P)하면 뭐(M)든 다"한다고 한다. 때로는 하찮아 보이지만, 또 어딘가를 보면 마에스트로가 따로 없다. 소위 말하는 빅테크(혹은 대기업)의 네임드 PM을 보면, 세상에 이런 능력자들이 없다. 모든 것을 진두지휘하는 마에스트로가 따로 없다. 뭔가 멋있게 데이터도 다루고, 기획서도 휙휙 쓰고, 가끔 프로그래머처럼 코딩도 한다. 게다가 UIUX도 마스터한 것처럼 보인다. 그러면서 엄청난 조정자의 면모도 보인다. 하지만 그들이 처음부터 그랬을 리 없다. 아마 처음은 다들 자조적인 의미로 얘기하는 잡부처럼 커왔지 않았을까...
그럼에도 그 잡부는 꽤 멋있게 성장했다.
많은 사람들이 PM에 대해 고민하고 제품을 만들어 가면서 그 역할에 의미를 부여하기 시작했다. 나 역시 그 과정에서 PM에 대한 나만의 정의를 최근에야 명확하게 정리를 했다. 아마 100명이면 100명의 PM들이 하는 일이 모두 다를 것이지만, 하나만의 공통점은 있다. 만약 이것이 없다면 그 PM은 그 역할을 잘못 수행하고 있거나, 어쩌다 보니 PM으로 명명된 어느 사람일 것이다.
그래서 PM이 뭔데?
PM은 고객의 문제를
고객의 언어로
끊임없이 정의하는 직군.
아... 이 얼마나 무책임하고 두루뭉술한 얘기인가?라고 물으면 사실 그렇다고 얘기할 것이다. 그럼에도 불구하고 PM이라면 이것이 알파이자 오메가이고, AtoZ임을 의심하지 않는다. 왜 이렇게 PM을 정의하는지 하나씩 곱씹어 보아야 할 것 같다. 거창한 말을 꺼냈으니...
문제를 해결한다는 것?
사실 대부분의 채용 공고에서 강조하는 PM의 주요 역량은 문제 해결이다. 뭔가 PM에 대한 대단한 정의 같은데, 왜 그런 대단함을 축소시켜서 문제를 정의하는 사람으로 만들었는가? 나는 문제 해결이 PM이 가지는 역량으로 정의하는 것은 조금은 건방진 정의라고 생각한다. 인간의 모든 노동은 문제 해결이다. 인간이 가진 모든 직업이 사실 문제를 해결하는 것이다. 다시 문제라는 것을 찾아보자.
A problem is a difficulty which may be resolved by problem solving
문제 해결(probem solving)이 눈에 띈다.
Problem solving is the process of achieving a goal by overcoming obstacles, a frequent part of most activities. Problems in need of solutions range from simple personal tasks (e.g. how to turn on an appliance) to complex issues in business and technical fields.
영어로 쓰면 거창하게 보이지만, 실상 본질은 인간의 겪는 불편함이 문제이고, 문제 해결은 불편함을 해소하는 것이다. 다시 내가 앞서한 말을 다시 반복하자면, 인간이 가진 모든 직업이 문제를 해결하는 것이다.
동네 편의점 알바도
청과물 가게 사장님도
동사무소의 공무원도,
리그오브레전드의 대상혁님도
빅테크의 PM도
빅테크의 개발자와 디자이너 모두...
다들 문제를 해결하는 사람들이다. 어떤 사장님은 동네에 청과물 유통이 시원 찮아 불편해하는 사람이 있다고 생각하기에 청과물 가게를 열어 문제를 해결한다. 공무원들은 냅두면 불편한 게 뻔한데 돈이 되지 않을 것 같으니 나라에서 문제 해결하라고 뽑은 사람들이다. 대상혁님은...? 고전파 시절에는 자기가 재밌게 놀지 못해 불편한 것을 해결하다가, 이제는 수많은 팬들의 행복을 베풀어주는 신의 재림이자 문제 해결사이다. 회사이든 자영업이든 세상의 모든 노동은 문제를 해결하는 것이 직업으로 되었다.
회사로 좁히자면 결국 문제를 해결하는 것을 업으로 하는 사람들이 모여 있는 곳이 회사이자 조직이고, 거기서 각자의 기술들을 바탕으로 문제를 해결하는데 기여를 하고 있는 것이다. 개발자는 개발을 하면서, 디자이너는 디자인을 하면서... 그러면 PM은 무엇을 하면서...?
문제를 정의하는 것
PM은 그렇다면 무엇으로 문제를 해결하는 것인지 조금 의심스럽다. 내가 생각하는 정답은 문제를 끊임없이 정의하는 능력으로 문제 해결에 기여를 한다이다. 조금은 추상적이고, 대체 그것이 무엇이냐고 할 수 있겠지만, 곰곰이 생각해 보면 문제를 정의하는 것 자체가 생각보다 까다로운 것임을 깨달을 수 있다. 그리고 문제를 정의하는 것부터 모든 것이 시작되는데, 이를 제대로 정의하지 못하는 것은... 답이 없는 상황을 마주하게 된다. 현상과 문제의 구분부터 해서, 고객이 문제라 생각지도 않는 것을 문제라고 하기까지.. 문제가 제대로 없는데 좋은 답이 있기는 쉽지 않다. 언제까지나 우연히 전자레인지가 답으로 뿅 하고 나오길 기대할 수는 없지 않은가? 보통 회사가 문제를 제대로 정의하지 못하면 망한다. (경험담)
끊임없이 정의하는 것
문제를 달랑 하나만 정의하면 되는 것인가? 문제라는 것은 대단한 하나의 무엇인가로 수렴되는 것처럼 보일 수 있지만, 보통은 매우 여러 단계로 쪼개어지게 된다. 그리고 PM은 그 문제를 작게 작게 쪼개어서 해결 가능한 단위로 정의해야 하는 상황에 마주하게 된다. 청과물 가게 사장님을 예로 들어보자.
1. 동네에 청과물 유통이 불편하다.
2. 청과물 중에서도 제철 과일은 너무 비싸게 판매된다.
3. 제철 과일이 신선한 상태로 오지도 않는 것 같다.
4. 옆 과일 가게는 너무 대로변에 있어서, 매연을 뒤집어쓸 것 같다.
사실 청과물 유통이라는 문제에서 시작했지만, 쪼개고 쪼개면 매우 다양한 작은 문제들로 나눌 수 있음을 알게 된다. 모든 문제라는 것이 보통 그렇다. 이러한 문제의 구조를 잘 정의한 것이 PM이라면 반드시 마주하게 될 에픽(Epic), 유저스토리(User Story) 같은 것이라 본다. https://www.atlassian.com/ko/agile/project-management/epics-stories-themes
구조적인 측면에서만 간단히 요약하면 큰 문제를 작은 문제로 나누어서 관리하는 계층이다. 다만 꼭 PM만이 문제 해결을 위해 이렇게 쪼개는 것이 아니다. 개발자들 역시 문제를 쪼개고 쪼개면서 정의를 한다. (https://www.youtube.com/watch?v=3VG2OgkRJK0&t=21s&ab_channel=%EC%88%98%EB%8A%A55%EA%B5%90%EC%8B%9C%EC%BD%94%EB%94%A9%EC%98%81%EC%97%AD )
결국 핵심은 고객의 언어로 정의를 하는 것
모두 문제를 해결하고, 문제를 쪼개기도 한다면, PM은 무엇으로 이들과 차별화해야 하는 것인가? 이 질문에 대한 정답이 고객의 언어로 문제를 정의를 해야 한다는 것이다. 그리고 이러한 부분이 PM에 계속해서 고객 고객 소리를 지르는 이유이다. (고객 중심적 사고를 적지 않는 PM 공고는 본 적이 없다.) 상대적으로 하드스킬이 부족한 직군인 것을 모두 알지만, 그럼에도 불구하고 PM에게 기대를 거는 것은 고객과 가장 가까운 곳에서 그들의 목소리를 문제로 전달해 줄 수 있고, 주어야만 하는 직군이라 생각하기 때문이다. (비교 우위라는 측면에서 볼 때, 개발은 개발을 디자이너는 디자이너에 집중을 하면, PM은 고객에 집중을 하는 것이 효율적이다. 비교 우위는 경제학의 데이비드 리카도를 검색해 보면 된다.)
고객의 언어로 문제를 정의하는 것은 고객의 입장이 되어서 문제를 고찰하는 것이다. 그리고 누군가는 반드시 고객의 입장에서 문제를 명확하게 정의할 수 있어야 한다. 그리고 유저스토리(user story)라는 문제를 고객의 언어로 정의하는 꽤 멋진 프레임워크도 있다. 고객의 언어로 고객의 문제를 정의하지 못하면, 아무 고객도 쓰지 않는 매우 멋진 쓰레기를 만들게 된다. 고객이 불편해하는 문제를 캐치하지 못하면서 열정을 쏟게 되면 아름다운 자기만 만족하는 제품이 나오게 된다. (많은 IT회사에서 볼 수 있는데, 뭔가 엄청난 기능 위주로 뭔가를 만들겠다고 할 때, 자주 보는 장면이다. 엄청난 개발력이 들어간 MAU 5명의 서비스) 그리고 이걸 수행한다면, 건방지게 IT 회사만 PM, PM하는 것이 아니라, 모든 직업에서 PM이라고 해도 된다고 생각한다.
그래서 PM은...?
PM의 모습은 매우 다양하지만, 위에서 얘기한 저 범주의 일을 가장 많이 하게 되고, 잘해야 좋은 PM으로 인정받을 가능성이 높아진다. 그리고 PM의 산출물 중 핵심이라고 할 수 있는 PRD(제품 요구사항 명세서 : Product Requirements Document)도 이러한 PM의 역할을 자연스럽게 풀어내는 것에 지나지 않는다. 고객의 문제를 정의하기 위해서 데이터도 보고, 고객의 문제를 정의하기 위해서 인터뷰도 하고, 고객의 작은 문제를 풀었다면 그다음 문제를 또 정의해서 풀면서 큰 문제를 해결하는 일의 반복... 이 과정에서 같은 조직 내에서 문제를 해결하는 다른 직군들과 협업하면서 문제를 해결(Problem Solving)을 하는 것이다. 협업하는 과정에서 보통 PM이 조정자 역할을 많이 하게 되는데, 이는 고객과 가장 가깝기 때문이라고 생각한다. (그렇지 않은 이유라면 PM이 굳이 의사결정을 주도하거나 할 필요가 전혀 없다.) 고객의 문제를 해결하는 조직에서 고객의 입장을 대변하는 직군인데, 누가 토를 달 것이냐! (물론 현실에서 조정자라는 것이 꽤나 까다롭기에 PM이 아닌 다른 경력 있는 직군에서 맡기도 한다.)
그래서 PM은 중요하다... 때로는 모호하지만 반드시 필요하고, 누군가는 해야 한다. 그리고 문제를 해결하려는 조직의 성공에 핵심적인 역할을 한다.
앞으로 Product Manager에 대한 저의 생각들을 조금씩 정리해서 써보려 합니다. 자주자주 글을 쓰지는 못하겠지만, 평소의 생각들을 양질의 콘텐츠로 정리하고 싶습니다. 아마 다음은 PM은 문제를 어떻게 정의하는 지에 대해서 이어 가보려 합니다.
