1.
PM으로 일하면서 “PM은 꼭 필요할까?”라는 생각을 해봤다. ‘개발자는 코드를 바탕으로 특정 기능이라는 결과물을 만들고, 디자이너는 디자인으로 결과물을 내고, 비즈니스 담당자들은 계약과 매출로 결과를 내는데, PM은 과연 무엇으로 결과를 내는 것이지’라는 생각에서 시작됐다. 제목에 던진 “PM은 꼭 필요할까?”라는 질문에 대한 답부터 우선 말하자면 부제목에 쓴 대로 답은 “YES and NO”다.
2.
“YES. PM은 필요하다.” 비즈니스 사이드, 유저 사이드, 디자인 사이드, 개발 사이드의 입장 및 현황을 바탕으로 현실적인 일정과 조건에 맞춰서 비즈니스를 위한 프로덕트를 릴리즈 할 수 있도록 조율하고 관리를 하는 역할이 필요하기 때문이다.
3.
“NO. PM은 필요 없다.” 위에 비즈니스 담당자, 개발자, 디자이너 등 각 직무 내에서 위에 말한 각 사이드의 입장을 바탕으로 조율 및 관리를 할 수 있는 사람이 있다면 PM은 필요 없다. 또한 각 직무 간에 서로의 입장 차이를 이해하고, 원활하게 협의가 되어서 비즈니스를 위한 프로덕트를 만들 수 있다면 PM은 필요 없다.
4.
결국 모든 이해관계와 정보를 종합해서 정리하고 조율할 수 있는 사람이 있는지 유무에 따라서 PM의 필요성은 달라진다. 그리고 꼭 이 역할을 하는 직군을 PM이라고 지칭할 필요도 없다. 그냥 개발자인데 위에 나열한 일을 할 수도 있는 것이고, 디자이너가 할 수도 있는 것이고, 비즈니스 담당자가 할 수도 있다.
5.
조직 규모나 조직 문화에 따라 다르겠지만, 많은 회사에서 서로 다른 직군들 스스로 입장 차이를 조율하기는 쉽지 않다. 각 직군마다의 이해관계와, 서로 간의 이해도, 추구하는 것들이 굉장히 다르기 때문이다. 그래서 거의 대부분의 회사에서 이 모든 것을 정리하고 조율하고 관리하는 직군을 두고 있고, 이를 PM이라고 부를 뿐이다.
6.
사실 PM이라는 직군은 굉장히 특수한 직군이다. 다른 직군과 달리 직군 자체에 ‘Manager’라는 단어가 붙는다. 여기서의 ‘Manager’는 직급에 따른 게 아니고, 직군 자체에 붙는 ‘Manager’다. 직군 자체에 ‘Manager’라는 단어가 붙는 직무는 흔하지 않다. 경영 지원 쪽에는 “Operation Manger”, “HR Manger” 등이 있긴 하지만.
7.
일반적으로 개발자를 ‘Developer’라고 부르지, ‘Development Manager’라고 부르지 않는다. 마찬가지로 디자이너도 ‘Designer’로 표현하지 ‘Design Manager’라고 하지 않는다. 비즈니스 쪽에서는 ‘Business Development Manager’, ‘Sales Manager’, ‘Account Manager’ 등 ‘Manage’라는 단어가 붙는다. 그런데 여기서의 ‘Manager’는 고객을 관리하는 것에 초점이 맞춰져 있지, 조직 내부의 이해관계를 관리하는 것에 초점이 맞춰져 있지는 않다.
8.
개발자, 디자이너, 마케터, 비즈니스 직군은 기본적으로 Maker의 성향과 특성을 가지고 있다. 비즈니스는 직군에 따라서 Maker와 Manger를 오가는 경우가 꽤 많은 것 같긴 하다. Maker는 큰 덩어리 시간을 사용해서 특정 결과물을 구현하는 특성을 갖고 있다. 개발자는 그 결과물이 코드이고, 디자이너는 디자인이고, 비즈니스는 사업 모델인 것이고. 그래서 Maker들은 각자가 생각하는 최선의 결과물을 내기 위해 노력한다. 개발자의 경우 클린하고 버그 없는 코드, 디자이너는 유려한 사용성과 심미성을 갖춘 디자인, 비즈니스는 지속적으로 매출을 만들어 내는 사업 모델.
9.
개발자, 디자이너, 비즈니스 직군 모두 Maker의 성향을 갖고, 자신들이 원하는 결과물을 내기 위해 노력하지만, 위에서 말한 것처럼 그들이 추구하는 결과물은 각자 다 다르다. 그래서 결과물을 내기까지 필요한 것이 다르다. 예를 들어 개발자나 디자이너는 자신들이 생각하는 더 좋은 결과물을 내기 위해 더 많은 시간이 필요할 것이고, 반대로 비즈니스는 매출을 위해 더 적은 시간과 더 많은 기능이 필요할 것이다. 그리고 이는 입장 차이로 이어지고, 심한 입장 차이는 갈등으로 이어진다.
10.
흔한 예시로, 비즈니스 입장에서는 개발과 디자인에 대해서 “아니 이런저런 기능 있으면 우리가 돈을 엄청 벌 수 있는데 왜 못한다고 하는 거지? 왜 시간이 이만큼이나 더 필요하다고 하지?” 이런 생각을 할 수 있고, 반대로 개발자나 디자이너 입장에서는 “아니 이거 만드는데 얼마나 시간이 필요하고 고려사항이 얼마나 많은지도 모르면서 무작정 만들어 달라고 하지?”라는 생각을 할 수 있다.
10.
아무리 잘 짜인 코드로 만든 기능을 갖추고 또 아무리 좋은 사용성과 심미성의 디자인을 가진 프로덕트라고 해도 매출과 이익을 내면 의미가 없다. 프로덕트라기보다는 예술 작품에 가깝다. 반대로 아무리 매출을 잘 내는 비즈니스 모델이라고 하더라도 프로덕트 없이는 매출을 낼 수가 없다. 그래서 서로가 서로의 이해관계를 이해할 수 있어야 한다.
11.
그래서 서로가 서로의 이해관계를 이해하고 제약이나 현황을 고려해서, 최선의 안을 도출하도록 관리하는 ‘Manager’가 필요하다. 그리고 이런 관리를 좀 더 전문적으로 하는 직군을 ‘Product Manager’라고 하는 것이고. 물론 위에서 말한 대로 ‘Maker’가 이런 ‘Manage’까지 할 수도 있다. 다만 Mange도 하면서 Make도 하는 게 쉽지 않아서, Manage만 전문적으로 하는 직군이 생긴 것이고.
12.
‘Manager’의 성향과 특성은 Maker와 좀 다르다. Manager들은 각 Maker들과 Manager, 고객 혹은 유저들의 다양한 이해관계를 조율하고 서로를 이해시킨다. 그리고 이를 바탕으로 일정에 맞춰서 프로덕트가 나오고 비즈니스를 전개할 수 있도록 하고, 그 과정에서 Maker들을 대변하기도 하고 Maker들이 목표와 목적에 맞춰서, 또 일정에 맞춰서 최선의 결과물을 구현할 수 있도록 한다.
13.
그래서 Product Manager에게 요구하는 지식이 많은 것이다. 각 Maker들을 이해하기 위해서는 각 Maker들의 분야를 어느 정도 알고 있어야 한다. 그래서 PM은 개발도 어느 정도 이해할 수 있어야 하고, 비즈니스도 알아야 하고, UX 지식도 있어야 하는 것이다. 물론 각 분야에 대한 전문 지식을 Maker만큼 갖기는 힘들다.
14.
Manager, 특히 Product Manager는 일본 시부야의 스크램블의 신호등과 같은 느낌이다. 사방에서 날아오는 각기 다른 요구사항과 이해관계 등을 정리하고, 일정에 맞춰서 일과 비즈니스가 전개되도록 하는 것이, 꼭 스크램블의 신호등이 교통을 정리하는 모습 같다고 할까.
15.
결국 각 Maker들의 이해관계와 입장 차이, 비즈니스 및 프로덕트의 현황, 유저 입장 등 모든 것을 조율하고 관리해서 프로덕트와 비즈니스를 전개하는 ‘Manager’는 필요하다. 다만 이 ‘Manager’가 꼭 ‘PM’이라는 타이틀을 달 필요는 없을 뿐이다.
16.
참고로 Maker와 Manager의 차이는 폴 그레이엄이 쓴 Maker’s Schedule, Manager’s Schedule이라는 글을 읽어보면 좀 더 잘 이해할 수 있다. 해당 글은 Maker와 Manager의 시간 사용법의 차이를 주로 말하는데, Maker와 Manager의 특성 차이를 이해하기에도 좋다.
ASH 님의 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
