오늘도 일이 많은 프로덕트 매니저에게
: 곧 10년차 서비스 기획자 + 프로덕트 매니저의 일기 같은 글
항상 명함에 '서비스 기획자' 또는 '프로덕트 매니저(PM)' 라는 직무가 있었다. 나는 이 직무가 제품을 만드는 과정에서 중요하다고 생각한다. 그리고 개인적으로는 서비스 기획자 보다는 프로덕트 매니저로 일하는 것을 선호한다. 담백하게 말하자면 이 일이 좋고 자부심이 있고 잘하고 싶다. 최근에 직무에 대한 이야기를 하다가 '이렇게까지 솔직하게 이야기 하실 줄은 몰랐어요' 라는 반응을 듣고 왠지 조금 더 이야기 해두고 싶어서 부리나케 달려왔다.
용어를 짚고 넘어가자. 나는 서비스 기획자와 프로덕트 매니저가 수행하는 역할은 기본적으로 같다고 생각한다. 다만 각 제품/조직마다 세부 항목이 달라지고 수행하는 역할 중 무엇을 가장 중요하게 볼 것인지에 따라 직무가 갈린다. 하지만 이는 이 직무를 수행하는 사람이 결정하는 것이 아니라 귀납적으로 조직에서 결정되게 된다. 조직의 요구에 따라 가변적인 직무라는 뜻이다. 조직에 따라 프로덕트 매니저가 수행하는 역할의 일부를 이미 수행하는 사람이 있을 수 있다. 때로는 누군가가 해야 하는데 여타의 사유로 하지 않는 역할도 서비스 기획자 또는 프로덕트 매니저가 해야 한다. 서비스 기획자 또는 프로덕트 매니저는 제품을 완성하고 성공 시켜야 하고 그 책임을 지기 때문이다. 그렇기 때문에 정확하게 하는 일이 뭐냐는 질문에 대해서 대답하기가 민망할 때도 있다. 많은 걸 하는데 다 말하기도 어색하고 그렇다고 난데 없이 비장하게 '제가 바로 이 제품을 책임지는 사람입니다'라고 할 일은 또 아니니까. 그렇지만 조금더 자세한 항목이 필요하다면 이 내용을 참고해도 좋을 듯하다.
프로덕트 매니저는
제품의 성공을 위해 일 하고
서비스 기획자는
제품의 완성을 위해 일 한다
서비스 기획자와 프로덕트 매니저 - 이 둘은 어떻게 다를까? 자신의 목표가 사업 지표와 연동 되어 있고 다양한 역할 - 사업 또는 서비스 전략 수립, 목표 설정, 기능 설계, 제휴/마케팅, 팀 매니징 - 을 한다면 프로덕트 매니저라고 생각한다. 서비스 기획자는 주어진 전략 방향성에 맞추어 제품 또는 기능이라는 언어로 그것을 풀어내고 사용성과 사업 목표를 모두 충족시킬 수 있는 제품을 만드는 과정에 집중한다.
서비스 기획자는 제품의 완성도를 높이는데 기여하기 때문에 스타트업에서는 따로 이 역할만을 수행하는 사람이 없거나 디자인/개발자가 이 역할을 일부 나누어 가지기도 한다. 프로덕트 매니저도 사정은 비슷하고 역할을 주로 나누어 가지는 사람이 대개 경영진이라는 점이 다르다.
두 직무는 제품에 기여하는 방식이 다르고 앞서 말한 듯이 프로덕트 매니저에 대해서 더 이야기하고 싶다. 프로덕트 매니저, 프로덕트 오너와 같은 직무가 유달리 최근에 더 많이 언급 되기도 하고 나의 커리어에서 중요한 고민은 그 역할에 물려있기 때문이다.
프로덕트 매니저의 역할과 책임감을 강조하기 위해서 '프로덕트 매니저는 제품의 CEO다' 라는 표현을 한다. 조금 낡은 표현이기도 하고 제품에 한해서는 제멋대로 할 수 있다는 해석은 오염된 해석이다. 나는 '제품 전반의 책임을 지는 사람'으로 이해한다. 여타의 직무와 같이 프로덕트 매니저도 실무적인 능력에 대한 조직에서의 요구를 받는다. 이를테면 데이터 기반의 의사결정을 위한 분석 능력, 기본적인 디지털 환경에 대한 개발 지식, 사용자 경험에 대한 이해, 마케팅 전반에 대한 이해, 원활한 커뮤니케이션 능력 등을 갖추어야 비로소 좋은 프로덕트 매니저 1단계를 마친 셈이 된다. 2단계부터는 시장 상황에 대한 인사이트, 서비스 도메인 지식, 팀 구성원에 대한 동기부여 및 관리 등이 있다.
무슨 말인지 몰라도 걱정마시라 하고 싶었던 말은 조직에서 매우 큰 기대를 받는다는 점이다. 말하자면 제품팀이라는 배의 선장과도 같다. 배를 잘못된 방향, 비유하자면 암초가 있는 방향으로 가자고 결정한다면 그 결과는 뻔하다. 그래서 제품팀의 선장인 프로덕트 매니저의 다양한 역할 중 으뜸은 '의사결정'이다. 무슨 기능을 언제 어떻게 만들어져야 하는지에 대해서 결정을 하는게 가장 중요한 역할이다. 소프트웨어를 근간으로 사업을 하고 있다면 이 것이 사업의 성패를 좌우한다고 해도 과언이 아니다. 경우에 따라 의사결정 권한을 위임 받지 못한 프로덕트 매니저도 있지만 나는 옳은 방향으로 가도록 경영진을 설득하는 것도 의사결정 역할에 해당한다고 생각한다.
프로덕트 매니저는 뭔가 엄청나게 정의한 듯한데 직접 해보니 실제로 그런 것 같다. 마티 케이건이 <인스파이어드>에서도 말하지만 성공하는 프로덕트 매니저는 대부분 남들 보다 일을 오래 하게 될 수 밖에 없다고 한다. 내가 말 그대로 '현타'가 온 것은 위와 같은 모든 스킬 셋을 갖춘 엄청난 프로덕트 매니저가 팀과 제 아무리 열심히 해도 반드시 성공하지는 않는다는 점이다.
제품을 성공 시키려면
그 확률을 높이려는 노력만큼
시도 횟수가 중요하다
내가 IT 업계에서 일하면서 배운 것 그리고 애자일에서 가장 와닿는 지점은 제품을 성공 시키려면 그 확률을 높이려는 노력만큼 시도 횟수가 중요하다는 점이다. 말했다시피 나는 이 직업이 좋고 잘하고 싶다. 꽤 많은 기능과 제품을 만들면서 나와 우리팀 담당하는 제품이 최고가 되지 못하는 이유를 나 스스로에게서 자주 찾았다. 대부분 어떤 능력의 결여에서 찾았다. 이를테면 뛰어난 팀원을 채용하는 과정에서 설득하지 못했다거나 시장성을 제대로 읽지 못해서 등과 같다. '나를 탓할 시간에 잠을 자고 컨디션 조절을 했으면 어땠을까?' 하는 생각이 든다.
성공하는 제품을 만드는 과정을 보면 '이것은 반드시 되는 아이템이니 진행한다'라는 경우는 없다. 여러 번 실패하고 그 과정에서 영점 조절을 계속하다가 어떤 포인트를 터치하는 순간 성공으로 이어진다. 아쉽게도 실제 실무에서는 수많은 검토를 거쳐 성공할 확률이 있는지 여러 단계의 보고를 거치고서야 실행할 수 있는 경우도 있다. 물론 단 번의 천재적인 혜안으로 제품을 성공시킬 수도 있지만 가능성이 매우 낮다는 점에서 리스크다. 물론 시도 횟수를 늘린다는 것이 매번 허투루 기회를 허비한다는 의미는 아니다. 매번 검증하고자 하는 가설이 있고 그 가설을 하나씩 만들어 보면서 또는 최소의 비용으로 테스트 하면서 성공에 가까워지도록 확률과 횟수를 함께 관리하는 것이다. 오히려 단번에 시도하던 것을 여러 번 한다고 보면 되겠다. 어떤 면에서는 더 빡세게 해야 한다는 것이다. 결국 이건 지난한 과정이고 오래 가야 하는 과정이다. 지치지 않고 포기하지 않으면서 가설을 예리하게 세워야 성공에 닿을 확률이 높아진다.
그래서 프로덕트 매니저는 오래 가야 한다고 생각한다. 오래 제품과 팀을 바라볼 수 있어야 확률과 시도 횟수를 조절할 수 있다. 매 번 마지막이길 바라는 마음으로 달리는 것이 아니라 매 번 조금더 다가간다는 마음으로 버텨야 한다. 이 지점에서 비극이 생기는데 또다시 마티 케이건을 불러 오자면 '남들 보다 일을 오래' 하지만 오래 가야 한다. 왜냐면 수행하는 역할이 많고 책임이 무거운데 성공은 단 번의 순간이 아니기 때문이다.
매 번이 마지막이길 바라는 마음으로 달리는 것이 아니라
매 번 조금더 다가간다는 마음으로 버텨야 한다
때문에 나는 프로덕트 매니저에 대한 동기부여가 중요하다고 생각한다. 제품/팀의 성공을 위해서 오랜 시간을 노력해야 하고 의사결정을 담당하기 때문에 어쩌면 우리가 해결하고자 하는 문제의 열쇠를 쥔 사람이다. '제품의 CEO'라는 프로덕트 매니저도, 어떻게 들릴지 모르겠지만, 직원이다. '당신은 마땅히 이래야 하는 직무니까 그래야 한다. 그렇지 않다면 우리는 함께 할 수 없다'라는 말은 맞는 부분도 있다. 하지만 제품을 만드는 과정에서 다양한 카테고리의 역할과 책임을 지는 사람을 오롯이 개인의 열정으로만 버티기를 기대하는 것은 조직 차원에서의 리스크라고 생각한다. 그 사람이 조직을 떠나게 된다면 그 자리와 역할을 어떻게 채울 수 있을까? 매번 이 제품/조직에 누군가가 우연으로 노력하고 헌신하길 기대할 수는 없는 일이다. 좋은 프로덕트 매니저를 채용하기 어렵다는 말은 이미 제품과 팀에 반한 사람을 찾고 있기 때문은 아닌가 하는 생각도 든다. 매번 같은 방식으로 동기부여를 할 수는 없지만 프로덕트 매니저의 기여를 이끌어 내려면 조직적인 차원에서도 관리가 되어야 한다.
덧붙여 말하면 나는 팀원은 팀이라는 제품을 사용하는 사용자라고 생각하고 그 때문에 팀 매니징도 프로덕트 매니저의 역할 중 하나라고 생각한다. 마찬가지로 프로덕트 매니저는 더 큰 조직의 구성원 중 일부이다. 이 조직의 사용자로 오래 남게 하려면, 위에서 짚은 대로 다시 말해 성공 확률과 시도를 계속 관리해 가려면, 동기 부여가 되어야 한다. 조직도 그 방식을 학습할 수 있어야 구성원의 이탈에 대한 대비도 된다. 사업을 한다는 건 기본적으로 리스크를 어떻게 관리하느냐도 있지 않은가?
마무리 같은 마무리를 하고 싶지만 할 말이 없으니 다짐을 남긴다. 어쩌면 내 욕심에 어울리는 최고의 제품을 만들지 못하고 이 직업을 그만두게 될지로 모른다. '어쩌면'이라는 말이 무색하게 그것이 대다수이고 보통이다. 보통의 프로덕트 매니저도 자신의 방식으로 계속 성공 확률과 시도 횟수를 관리하고 있다. 조금 더 우리의 과정에 집중할 필요가 있다. 결과가 항상 중요하고 결과로 말하는 사람이 최고라지만 그런 사람은 한 줌도 안 된다. 그 한 줌도 안되는 사례를 보고 자신을 소진하는 방식으로 일 하게 되면 되려 목표에서 더 멀어진다고 생각한다. 버티고 포기하지 않는다는 걸 무기와 방패 삼아 버텨야 소프트웨어 시장에서 살아 남는게 아닐까?
가끔은 나와 우리 팀이 해온 작업을 다시 들춰보고 놓친 배울 점이 없는지 찾아보자.
우리는 언제나 어떤 과정 중에 있다.
