PM이 하는 일
IT 업계와 관련이 있으신 분들은 PM이라는 직무가 익숙하실텐데요! 다른 분야에 계신 분들께 PM이라고 소개하면 어떤 일을 하는지 잘 모르시는 분들을 많이 만날 수 있었어요!
그럴 때마다 PM이라는 직무를 어떻게 소개해야할까! 하는 고민이 있었는데요. 오늘은 PM이 어떤 일을 하는 사람인지 간단하게 소개해보려고 합니다!
PM이란
IT 업계의 PM은 프로덕트 매니저(Product Manager)의 준말로, 담당하는 서비스의 문제를 정의하고, 지속적으로 개선해나가는 직무입니다. 약간 프로덕트라는 아기👶를 키워나가는 역할인데요.
IT 업계에서 프로덕트(Product)라 함은 우리가 사용하는 웹/앱 서비스를 말해요! 우리가 흔히 사용하는 배달앱, 검색엔진, SNS, 커머스앱 등을 아울러 프로덕트라고 부릅니다. PM은 특정한 서비스, 프로덕트를 담당해서 더 좋은 서비스로 지속적으로 키워나가는 역할인거죠!
근데 그럼 그 앱들에 그렇게 많은 PM이 필요한가?라는 생각이 드실 수 있어요. 왜냐하면 우리는 보통 '토스', '쿠팡', '당근' 같은 앱 서비스 하나를 사용한다고 생각하기 때문인데요!
하지만 이렇게 서비스 특성에 따라서 구매자와 생산자를 양쪽으로 서비스를 해야한다거나, 기존에 있던 서비스 외에 다른 기능이 추가된다거나 하는 식으로 서비스의 규모가 커지게 되면 점차 각각의 도메인, 팀으로 프로덕트를 쪼개게 됩니다.
예를 들어, 당근의 경우 현재 열려있는 채용 공고를 보면 아래처럼 피드, 검색, 광고 등으로 세분화되어있는 걸 볼 수 있어요! 이렇게 하나의 큰 서비스를 각각 세부적인 프로덕트로 나누어서 각각의 프로덕트를 PM들이 키워가는 구조라고 생각하시면 됩니다!
함께 일하는 사람들
PM은 프로덕트를 키우는 엄마같은 역할이지만, 엄마와 가장 다른 점은 실제로는 직접 애를 키울 수가 없다는 거에요! (!?)
PM이 키우는 자식인 프로덕트는 결국은 코드로 짜여자고, 디자인 UI로서 고객을 만나는 서비스이기 때문인데요. 그렇기에 가장 긴밀하게 함께 일하는 직군으로는 개발자분들과 디자이너분들이 있어요! 아무리 좋은 기획도 실제로 구현되지 않으면 고객을 만날 수 없기 때문에 구현이 가능한지, 어떤 UX/UI로 고객분들께 전달되어야 할지를 함께 고민하게 됩니다.
그 외에도, 고객분들이 서비스를 알고 들어와서 사용할 수 있게끔 유입을 이끄는 마케터 분들, 서비스가 운영되면서 생기는 문제를 해결하는 CX팀, 지표를 함께 분석하는 데이터 분석가분들 등 다양한 직군과 함께 협업하게 돼요. 팀 구성은 회사마다 팀마다 굉장히 다릅니다.
서비스 기획자, PM, PO의 차이점
PM은 서비스 기획자, PO라는 직무로도 혼용되어 사용되고 있는데요. 역사적으로 보면 아래와 같은 과정을 거쳐왔어요. (출처 : 프로덕트 매니저는 무슨 일을 하고 있을까 - 개점휴업, 최민 (2023))
2013년 : 기획자 무용론. 당시 기획 업무는 현재의 제품 관점보다 훨씬 협소한 역할을 수행했음. 기존 사업 분야와 같이 IT업이라고 부르는 용역성 업무가 주를 이루었음.
2015년 : 서비스 기획자라는 표현을 쓰기 시작함. 생활 필수재로 IT 서비스가 정착하면서 사용자 경험에 대한 논의가 시작됐고 뛰어난 서비스 기획자라면 사용자 경험 설계에 있어서 전문성을 요구받음.
2018년 : 프로덕트 매니저라는 호칭 적극 사용. 데이터를 기반으로 사용자가 말하지 않는 요구사항을 파악하고 제품에 반영하는 등 제품 전반을 책임지는 역할로 PM 업무의 범주와 위상이 달라짐.
2020년 : 프로덕트 오너(Product Owner)라는 직무로 프로덕트 매니징이 진화하면서 제품뿐만 아니라 비즈니스 영역 전체를 총괄하고 성과를 내고 책임지는 역할도 생김.
현재 세 직무가 딱 떨어지게 구분되지는 않지만 일반적으로는 아래와 같이 업무의 차이가 있습니다.
서비스 기획자 : 디테일한 화면 설계, 스토리보드 작성 등의 구체적인 개선 작업을 주로 담당
PM : 1 to 10, 1 to 100, Product-Market Fit를 찾은 제품의 고도화를 위한 전략을 구상하고, 문제 정의 및 가설 수립을 통한 개선 실행
PO : 0 to 1, 제품의 Product-Market Fit을 찾고, 제품을 고도화하하는 역할
담당하는 프로덕트가 현재 어떤 성장 단계에 있느냐에 따라, 그리고 의사결정권한과 책임의 범위에 따라, 그때의 프로덕트에 필요한 직무가 달라진다고 볼 수 있을 것 같아요! 회사마다 다르게 정의하는 경우도 있기 때문에, 모두 같은 의미로 사용하고 있다고 보긴 어려워요.
PM이 하는 일
그럼 구체적으로 PM이 어떻게 프로덕트를 키워나가는지 한번 살펴볼게요! 기본적으로 다음의 네 단계를 반복해서 목표를 달성하고 문제를 해결하는 것이 PM의 업무 사이클이라고 보시면 됩니다!
1) 문제 정의
우리가 사용하는 서비스는 고정적이지 않고 계속해서 바뀌는데요. 사용자의 입장에서 업데이트가 된 걸 확인하신 경험이 있으실 거에요! 그럴 때마다 여러 개선이 일어나고 있다고 보시면 됩니다! (그리고 실제로는 그 뒤편에서 더 많은 개선을 하고 있을 거에요😆)
사실 사용하는 입장에서는 뭔가 서비스에 그렇게 문제가 있나? 혹은 그냥 이거 좀 불편한데 안고치나? 정도의 생각만 하고 사용하실텐데요! PM이 만나게 되는 건 엄청나게 많이 쌓여있는 백로그들과 수많은 CS 문의들, 대표님의 피드백 등이랍니다! 이렇게 쌓여있는 문제들 중에서 PM은 우리 서비스가 지금 집중해서 해결할 단 하나의 문제를 정의해야 해요.
이 문제를 정의하는 방법은 크게 두 가지가 있는데요. 첫 번째는 정량적인 지표를 통해 문제를 정의하는 것이에요. 팀이 정해진 기간 내에 달성해야할 목표가 있을텐데요! 그 문제를 달성하려면 어떤 걸 가장 먼저 해결해야 하는가라는 관점에서 문제를 정의하는 거죠.
예를 들어, MAU가 기존 트렌드 상으로 월 3%씩 성장하고 있는데, 목표 MAU를 달성하기 위해서는 남은 3개월간 월 성장률이 10%가 되어야 한다. 현재 MAU의 구성요소 중 M1 재방문자 그룹이 70%를 차지하고 있는데 그 리텐션 비율이 25%로 업계 평균 대비 절반 가량 낮으므로, M1 리텐션을 높여야 한다. 와 같은 방식으로 데이터를 기반으로 문제를 좁혀 들어가는 방식입니다.
두 번째는 고객의 목소리를 듣는 것인데요. 실제로 내가 유저들을 100명을 만나봤는데 그들 중 80명이 이 문제를 이야기했다와 같은 방식으로 고객 의견을 통해 개선점을 발견하는 방법입니다. 이때 중요한 건, 빈도수와 강도를 함께 고려하는 것이에요. CS 문의로 들어오는 문제들도 너무 많기 때문에, 해당 문제가 얼마나 자주 발생하고 얼마나 심각한 문제인지를 고려하는 거죠.
2) 솔루션 도출
앞에서 정의한 문제를 어떤 방법으로 해결할 것인가가 솔루션인데요. 각각의 솔루션은 하나의 가설이기 때문에 사실 솔루션이 맞아들어갈 가능성은 그렇게 높지 않습니다. 3할 타자에 비유하기도 하죠.
물론 기획을 하는 PM과 프로덕트팀의 입장에서는 각각의 솔루션이 잘 됐으면 하는 마음이 크고, 잘 될거라는 믿음을 가지고 실행하지만, 실제로는 각 솔루션이 진짜 문제를 해결하는 맞는 방법이었는지는 실제로 해보지 않고서는 알 수 없어요. 문제를 해결할 방법을 빨리 찾으려면, 가능성이 높은 가설을 테스트하는 것도 중요하지만 최대한 빨리 다양한 가설을 테스트해보는 게 중요한 이유에요.
또한 이때 중요한 건, 우리가 집중하는 문제를 해결하는 방법 중에 대중적으로 이미 있는 방법이 있는가를 고려해서 그 방법을 활용하는 것인데요! 생각보다 고객들이 우리가 의도한대로 제품을 사용하지 않는다는 걸 항상 생각해야 하기 때문이에요!
실제로 저도 QA를 위한 서비스를 만들 때, 실제 유저가 QA를 하는 흐름에 맞지 않는 기능으로 인해 사용자들이 이탈하는 모습을 유저 테스트에서 보고 반성했던 기억이 있답니다..🥲 저희 팀장님께서도 항상 고객들이 우리와 같이 생각하고 서비스를 쓸 거라고 기대하면 안된다라고 강조하셨었답니다.
그렇기 때문에 최대한 '이미 있는 방법'을 활용하는 것이 중요해요. 이미 있는 방법, 익숙한 방법을 활용할 때, 고객이 새로운 학습을 하지 않고서도 제품을 바로 이해하고 사용할 수 있고, 그렇게 됐을 때 저희가 의도한대로 사용하실 가능성이 높아지기 때문이죠.
3) 액션 및 검증
이렇게 만들어진 솔루션을 실제로 고객분들께 전달하고, 그 결과를 확인하게 되는데요. 여러 시행착오를 거치면서 돌아보니 잘 되는 기능과 안 되는 기능은 결국에는 고객에게 '가치'를 전달했는가로 귀결되더라구요. 어떤 문제를 해결하려고 하는가에 집중해서 그 문제가 해결되는지를 확인해야하는 거죠.
저의 예시로 보자면, 같은 버튼을 바꾸는 솔루션이라고 하더라도, 버튼의 모양만 바뀌었을 때는 고객이 새롭게 얻은 가치는 없기 때문에 문제가 해결되지 않았었지만 버튼의 의미를 명확하게 전달하고 해당 기능을 이해하고 사용할 수 있게 바꿨을 때는 고객이 기능의 가치를 이해하고 사용할 수 있게 됨으로써 문제가 해결되는 걸 확인할 수 있었어요.
결국은 우리가 검증하려고 하는 가설이 있을 때, 1) 문제가 해결되나? 2) 이게 가장 효율적인 방법인가?를 고려해야하는 거죠.
저는 아직도 기억에 남는 에피소드가, 대표님이 어떻게 하면 일을 덜할까를 고민하라고 하셨을 때였어요. 어떻게 하면 일을 가장 적게하고 문제를 해결할 수 있을까? 최대한 일을 덜하려면 어떻게 해야할까?를 고민하라고 하셨을 때 머리를 한 대 맞은 것 같았어요. 일에 몰입해서 달려가다보면 이것도 되어야할 것 같고, 이것도 필요할 것 같고 스펙이 커지기 일쑤인데, 잠시 멈춰서 일주일 걸릴 이 일을, 하루만에는 못하나? 하루만에 하려면 어떻게 해야하지?를 생각하는 것이 중요한 것 같아요.
4) 결과 해석
실제로 실행을 하고 나면, 결과가 나오게 되는데요. 보통은 A/B 테스트를 통해 기존안과 개선안의 성과를 비교하게 됩니다. 개선안이 이겼으면 하는 마음으로, 조마조마하게 결과를 30분, 1시간, 하루 종일 들여다보게 되죠. (가끔은 실눈 뜨고 슬쩍슬쩍 보기도 하고, 기도하면서 보기도 했습니다😂)
결과는 실패하거나, 성공하거나 둘 중 하나인데요. 여기서 중요한 건 실패했으면 왜 실패했고, 성공했으면 왜 성공했는지를 아는 거에요. 그래야 다음 액션이 달라질 수 있기 때문이죠!
실패한 이유를 알아야 다음에는 어떻게 다르게 할지를 알고 더 가능성이 높은 방향으로 시도할 수 있고, 성공한 이유를 알아야 같은 방법으로 계속해서 성공 복제를 할 수 있어요.
가끔은 데이터만 봤을 때는 정말 이유를 모르겠을 때가 생기기도 하는데요, 이럴 때는 유저 인터뷰, 유저 테스트 등의 정성적인 방법을 활용하거나, 아니면 아예 다시 테스트를 해보기도 해요.
개발자분들이 개발을 하시다보면 잘 안 돌아가면 '이게 왜 안되지?', 잘 돌아가면 '이게 왜 되지?'라는 말씀을 하시는 걸 보게 되는데요. PM도 같은 상황을 겪는다고 보시면 돼요. 잘 되면 '아니 왜 잘된거지?', 안 되면 '아니 이게 왜 안된거지?'하면서 그 이유를 집요하게 파게 됩니다😆
PM을 선택한 이유
그럼 이제 저의 개인적인 이야기로 돌아가서 제가 왜 PM을 선택했는지를 잠시 이야기해보려고 해요. 저는 다른 글에서 말씀드렸던 것처럼 드라마 조연출을 하다가 PM으로 직무를 바꾸게 됐는데요. 진짜 다시 시작한다고 생각하고 내가 어떤 일을 하는 게, 어디에 쓰이는 게 가장 좋을까를 생각해봤던 것 같아요.
여러 직군의 사람들과 협업하고, 하나의 일을 되게끔 이끌어가는 일을 하고 싶었어요. 제가 의사결정권한과 책임을 가지고 있을 때, 제 자신보다도 일에 푹 빠져서 몰입하는 게 너무 좋았던 것 같아요.
PM이라는 직무를 처음 접했을 때 사실 저는 PM이 조연출과 그렇게 다르지 않다는 생각이 들었어요. 수십명의 촬영팀과, 또 내부에서 만나는 수십명의 후반작업 팀들이 개발자와 디자이너, 마케터로 바뀌고, 콘텐츠에서 서비스로 만들어가는 결과물만 바뀐 느낌이었어요!
또 경영 / 프로그래밍 / 디자인의 합집합에 있는 PM이 다 저랑 나름의 공통점이 있다는 생각이 들었어요. 경영학과를 전공했고, 또 프로그래밍도 관심이 있어서 세 과목 정도 들은 적이 있었거든요. 또 방송국 활동을 하면서 디자인, 영상 편집을 했었기 때문에 이 셋이 합쳐지는 곳에 PM이라는 직무가 있는 것 같아서 '오 뭔가 나랑 잘 맞을 것 같은데?' 하는 생각이 들었답니다😆
그리고 무엇보다 사람들의 삶을 바꿀 수 있는 일이라는 점이 가장 컸어요. 사람들의 불편함, 문제를 해결하는데 기여할 수 있다면 일을 할 이유가 너무 충분하겠다는 생각에 PM을 선택했어요!
PM으로 이루고자 하는 목표
돌아보면 '왜 그렇게 열심히 하냐'라는 말을 많이 들었던 것 같아요. 근데 문제는 저도 '왜인지' 잘 모르겠다는 거였어요. 답하기 어려워서 그냥 일이 재밌고 좋으니까라고 했던 것 같은데, 생각해보니 저는 그런 이유는 아니라는 걸 깨달았어요.
일하면서 행복한 순간은 두 가지였는데요. 첫째는 팀원 분들과 함께 몰입해서 일할 때였어요. 대학생 때 방송제를 기획할 때도 방송제에 몇 명이 왔으면 좋겠다가 아니라 '국원들이 내가 주인이라고 느끼면서 재밌게 일할 수 있으면 좋겠다'가 제 목표였던 게 생각 나더라구요. PM으로 일하면서도 어떻게 하면 팀원 분들이 재밌게, 의미 있는 일을 하고 있다는 걸 알고서 몰입할 수 있는 환경을 만들 수 있을까 하는 생각이 컸던 것 같아요.
그리고 두 번째는 고객 분들이 서비스를 만족하면서 사용해주실 때였어요. 작은 한 마디일 수 있지만 '덕분에 잘 쓰고 있어요' '이런 점이 좋아요'라는 말을 듣는 것보다 행복할 때는 없는 것 같아요. 그리고 반대로 뭔가 불편함을 말씀하실 때나, 이런 문제가 있다를 말씀해주실 때는 아 진짜 너무 해결하고 싶다하는 의지가 활활 타올랐구요.
그렇게 회고해보니 저는 '다른 사람의 삶을 더 좋게 만드는 일'에 가치를 느낀다는 걸 알 수 있었습니다! 그 중에서도 저는 교육과 심리 상담, 건강 쪽에 계속해서 관심이 있어왔어서, 미래에는 더 많은 분들이 삶을 긍정하고 행복하게 살 수 있는 일을 돕는 서비스를 만들고 싶어요!
저의 개인적인 목표까지 곁들여서 PM에 대해 이야기해보았는데요! PM 직무에 대해 궁금증, 호기심, 관심이 있으셨던 분들께 도움이 되었으면 좋겠습니다!
Last updated