[Chapter 1. 커리어] 어떤 일을 하고, 어떻게 될 수 있나요?
PM을 하면서 가장 많이 느끼는 건, 이 직무의 장점과 단점이 사실 같은 지점에서 나온다는 거다. PM은 제품의 중심에 서서 모든 결정에 관여하고, 다양한 팀과 협업하며 실제 사용자 반응을 직접 확인할 수 있는 직무다. 성취감이 크지만, 동시에 책임도 무겁다. 결정한 기능이 실패하거나 일정이 어그러졌을 때 가장 먼저 원인을 설명해야 하는 사람도 PM이다.
PM의 가장 큰 장점은 내가 만든 기능이 실제로 사용자에게 어떤 영향을 주는지 바로 확인할 수 있다는 거다. 어느 음원 스트리밍 서비스에서 플레이리스트 추천 기능을 개선했을 때, 사용자들이 "이거 진짜 좋다"는 리뷰를 남기는 걸 보면서 느끼는 보람은 말로 설명하기 어렵다. 내가 고민하고 설계한 게 실제로 누군가의 경험을 개선했다는 걸 확인하는 순간이다.
또 다른 장점은 다양한 사람들과 협업하면서 시야가 넓어진다는 거다. 개발자와 이야기하면서 기술적 제약을 이해하게 되고, 디자이너와 협업하면서 사용자 경험의 중요성을 배우고, 마케터와 논의하면서 비즈니스 관점을 키운다. PM은 한 분야의 전문가가 아니라, 여러 분야를 이해하고 연결하는 사람이 되는 거다.
실제로 한 커머스 PM은 "처음엔 개발 용어도 몰랐는데, 2년 동안 일하면서 API가 뭔지, 데이터베이스 설계가 왜 중요한지, UI와 UX의 차이가 뭔지를 모두 배웠다"라고 했다. PM으로 일하면서 자연스럽게 T자형 인재가 되는 거다.
PM의 단점이라고 하기는 어렵지만, 굳이 고르자면 정답이 없는 상황에서 계속 결정을 내려야 한다는 것에서 오는 압박이 있다는 점이다. "A 기능과 B 기능 중 뭘 먼저 만들까?", "이 기능을 출시하는 게 맞나, 아니면 더 검증이 필요한가?" 같은 질문에는 명확한 정답이 없다. 데이터를 봐도, 사용자 의견을 들어도, 결국 최종 판단은 PM의 몫이다. 그리고 그 판단이 틀렸을 때 가장 먼저 책임을 져야 하는 사람도 PM이다.
실제로 한 배달 앱 PM은 "무료배달 혜택을 확대하면 단기적으로 주문이 늘어날 거라 판단했는데, 예상과 달리 효과가 미미했고, 마케팅 비용만 늘어났다"는 경험을 이야기했다. 그 결정을 내린 건 PM이었고, 왜 실패했는지, 다음엔 어떻게 할 건지를 경영진에게 설명해야 했다.
이런 부담을 감수할 수 있는 사람이라면 PM에 잘 맞는 거고, 이게 스트레스라면 PM이 힘들 수 있다. 명확한 가이드라인이 있고, 시킨 일을 잘 수행하는 게 더 편한 사람이라면 PM보다는 다른 직무가 더 맞을 수 있다.
PM의 장점과 단점은 결국 같은 지점에서 나온다. 제품의 중심에 있다는 건 모든 결정에 관여할 수 있다는 의미지만, 동시에 그 결정에 대한 책임도 진다는 뜻이다. 성공하면 팀 전체의 성과지만, 실패하면 PM의 판단 실수로 여겨지는 경우가 많다.
하지만 이런 부담을 감수하고도 PM을 하는 이유는, 내가 만든 제품이 실제로 사람들의 삶을 바꾸는 걸 볼 수 있기 때문이다. 어느 교육 플랫폼 PM은 "내가 만든 강의 추천 기능 덕분에 누군가가 새로운 걸 배우고, 그게 커리어 전환으로 이어졌다는 후기를 봤을 때, 이 일을 계속하고 싶다고 느꼈다"라고 했다.
PM은 제품의 중심에 서는 직무다. 그래서 성취감도 크고, 부담도 크다. 내가 만약 의사결정을 내리는 걸 좋아하고, 그 의사결정이 팀에 효율적인 판단을 가져오는 것에서 뿌듯함을 느낀다면 PM이 잘 맞는 직무다. 하지만 정답 없는 선택을 계속해야 하는 부담을 감수할 수 있는지, 실패했을 때 그 책임을 받아들일 수 있는지도 함께 고민해봐야 한다. 이 둘을 함께 받아들일 수 있다면 PM은 정말 보람 있는 일이 될 것 같다.
* 전체 내용을 정리한 전자책은 아래에서 확인할 수 있습니다.