PM 역할

PM(Product Manager, 프로덕트 매니저)의 역할은 무엇일까?

제로베이스 PM 스쿨

IT 유망 직무로 떠오른 PM(Product Manager, 프로덕트 매니저).
PM의 역할은 무엇이고, 도대체 무슨 일을 하는 사람일까요?

구글에 검색해봐도 이해하기 어려운 PM의 역할을 쉽게 설명한,
전 피엑스디 UX 컨설턴트 박재현 모니카님의 글을 소개합니다.

내가 PM하기 전에 알았으면 좋았을 것들

디자인 컨설팅 회사에서 PM 직무의 역할

Written by. 박재현 모니카 (전 피엑스디 UX 컨설턴트)

들어가면서

최근 프로젝트에서 처음으로 PM 직무를 맡아 4명의 팀원과 함께 2달간 프로젝트를 진행했습니다. 하면서 고민했던 것이나, 새로 배운 점을 공유하려 합니다. 저처럼 디자인 컨설팅 회사에서 처음 PM을 하시는 분들이나, 앞으로 PM하실 분들에게 도움이 되면 좋겠습니다.

저희 회사 같은 디자인 에이전시에서는 리딩하는 역할을 대기업에서보다 빨리 경험하게 됩니다. 인력이 빠르게 교체되고 비교적 소수 인원으로 돌아가기 때문입니다. 어차피 어디에 있든 나 혼자 할 수 있는 일은 그렇게 크지 않습니다. 나 혼자 생각하고 손을 열심히 놀려서 만드는 결과물은 여러 사람의 능력을 종합해서 만드는 결과물에 비하면 한계가 있지요.

시점이 언제가 되었든 어떤 회사에 있든, 우리는 점차 큰 그림을 보고, 종합하고, 분배하는 역할로 옮겨갈 것입니다. 회사가 성장하고 팀이 커지면서 내 역할이 바뀔 수도 있고요. 그런 역할을 경험할 수 있으면 추후에도 도움이 되고, 내가 팀원일 때도 일을 분배하는 입장을 이해할 수 있기 때문에 팀워크가 더 수월해 집니다.

관리라는 역할

제가 인상깊게 들었던 팟캐스트에서 Julio Zhuo가 이런 말을 했습니다.

이걸 듣고 외부에서 주어지는 역할로서의 '관리', 개인의 자질로서 '리더십'을 구분해 생각해 봤습니다. 리더십은 연차나 맡은 역할에 상관없이 발휘할 수 있는 개인의 자질입니다. 신입이라고 해도 주변 사람들에게 영감을 주고, 동기를 부여하고, 비전이 있다면 리더십이라는 특질을 가진 것입니다. 리더십에 대한 고민은 어떤 연차든 충분히 가치있고 좋은 매니저가 되기 위해서도 당연히 길러야 할 자질입니다.

(주관적인) PM 역할

우선 제가 경험하면서 느꼈던, 팀원에서 PM이 되었을 때 가장 크게 달라지는 역할은 다음과 같았습니다.

1. 논의를 시작하기(Open discussion)

'논의'라는 건 다양한 스펙트럼이 있겠죠. 어떤 일을 해야할 것인가, 이 업무의 목적은 무엇인가, 어떻게 수행할 것인가 등등. 가벼운 이야깃거리도 있지요. 회의 분위기가 어땠다거나, 점심은 언제 먹을까라던가. 물론 누구나 필요한 시점에 논의를 자유롭게 시작하는 것이 베스트이겠지만 때때로 논의가 시작되지 않을 때가 있습니다.

그런 타이밍에 '이런 얘기를 하자', '이런 걸 같이 결정하자'라고 화두를 던져서 시작하는 것이 PM이 맡는 중요한 책임 중 하나입니다. 팀원일 때는 제가 얘기를 꺼내고 싶을 때 꺼내고, 조용히 있고 싶으면 가만히 있었습니다. 하지만 PM이 되었을 때는 이 시점에 이 이야기를 하지 않아서 일정이 지연되거나, 완료되어야 하는 산출물이 나오지 않으면 그건 제 책임이 됩니다. 따라서 적절한 시점에 논의를 효율적으로 시작하는 것이 중요합니다. 저는 이야기를 완료하고 의사결정하는 것보다 논의를 시작하는 게 중요한 역할이라고 생각합니다. 물론 의사결정도 PM의 역할이지만 그보다 팀원+이해관계자가 함께 잘 의사결정할 수 있는 판을 깔아주는 것/틀을 만드는 것이 더 중요하고 팀원, PM 역할이 달라지는 지점이라 생각하기 때문입니다.

논의를 잘 시작하기 위해서는 사전에 머릿속에 '어떤 이야기를' '무엇을 위해서(뭘 결정하기 위해서)' '누구랑' '언제' '얼마나 오래'할 것인지 대략적인 그림을 그려놓고 시작해야 합니다. 무턱대고 우리 얘기 시작해요 하고 얘기하다보면 딴 길로 새고 시간은 시간대로 흘러가는 경우도 있으니까요. 모든 사안에 대해서 그렇게 할 필요는 없지만, 저는 주로 아이폰이나 맥북 기본 메모장에 무엇에 관해서, 이런 이유로 얘기를 해야겠다 싶은 걸 간단하게 써놓고 이야기를 시작했습니다.

2. 클라이언트와 직접 소통하기

팀원일 때도 물론 클라이언트와 소통을 하긴 했지만, 제가 맡아서 해야 하는 부분은 아니었습니다. PM이 클라이언트와 소통을 원활하게 할 수 있도록 도와주는 문서를 만드는게 더 큰 역할이었지요. 통화, 보고문서 발표, 이메일 등 다양한 통로로 클라이언트와 소통을 하게 되는데요. 여기서 고민했던 것들은 다음과 같습니다.

어떤 주기로 얼마나 디테일하게 공유할것인가?
어떤 인간관계도 마찬가지겠지만 클라이언트 분 성향과 상황에 따라 달라질 것 같습니다. 저는 익숙하지 않았기 때문에 감이 잘 안오긴 했지만 그래도 초반에는 계획, 진행상황을 적극 공유하는게 공유하지 않다가 '짠!'하고 서로 놀라는 상황보다는 훨씬 안전하다는 생각이 들었습니다. 공유하고 피드백을 받으면서 앞으로 프로젝트에서 예상되는 리스크도 파악할 수 있구요. 매주 직접/원격으로 만나서 작업한 내용을 공유하는 시간을 가질 것인지도 초반에 정하면 좋습니다. 산출물 공유 포맷/방식도 초반에 얘기하면 좋습니다.

보고, 청중과 우선순위를 고려하기
보고 문서를 만들때 가장 고민되었던 포인트는 누굴 대상으로 하고 어떤 내용을 우선순위로 전달할 것인가 하는 것이었습니다. 실무자/경영진이 전부 참여하는 보고자리라면 입장 차이가 있을 수 있겠죠. 가능하면 보고에 어떤 분들이 오시는지, 누가 주요 의사결정권자인지 미리 파악하면 문서 만드는데 도움이 됩니다. 이때 도움이 되었던 것은 내부 팀원들과 함께 보고자리에 오시는 분들이 각자 어떤 궁금증/목표를 갖고 있을지를 포스트잇에 붙여보는 것이었습니다. 머릿속에 두루뭉술하게 생각하는 것과 그걸 끄집어내서 한번 정리하고 나니 보고 문서 흐름을 정하는 데에 크게 도움이 되었습니다.

오픈된 질문보다 선택지 + 장/단점을 주고 선택하실 수 있도록

위는 좀 극단적인 사례이긴 하지만, '뭐 먹을래?'하고 열린 질문을 하기보다 '한식,중식,양식,일식 중에 뭐가 땡겨?'라고 한번 좁혀서 물어보거나, 괜찮은 식당 몇개+메뉴를 보여주면서 '이 중에 골라보자'하는게 더 부드러운 대화가 될 수 있었겠죠. 마찬가지로 사용자 조사 때 '누구를 보고 싶으세요?', '어떤 방식으로 볼까요?'라고 열린 질문을 하기보다는 가능한 옵션+비용+장점을 제시하고 이 중에서 선택하시거나 같이 논의하는 방식이 더 부드럽게 흘러갈 가능성이 있습니다.

반대하기보다 선택에 따른 리스크 설명하기
진행하다보면 팀원들 생각과 클라이언트 의견이 맞지 않는 때도 많은데요. 그럴 때는 의견에 반대를 하기보다는 그렇게 진행했을 때에 예상되는 리스크는 이런 것이 있다는 점을 인지하셨는지하고 한번 짚고 넘어가는게 좋습니다. 그럼에도 불구하고 그대로 진행하길 바라신다면 예상되는 리스크를 줄이기 위한 대비책 같은걸 같이 논의하는게 좋겠죠.

3. 업무 배분하기

일을 분배하는게 더 어렵다
신입일때 알았으면 좋았을 것에서 1번으로 '일을 시키는 것도 능력이다'를 꼽았습니다. 그 때 얘기한 것처럼 내가 하는 것보다 남에게 일을 배분하는게 훨씬 어렵습니다. 제가 하는 건 저 자신만 생각하면 되지만, 여러명에게 업무를 분배할 때는 각자 일하는 스타일, 업무 이해도, 사고 방식을 파악해야 합니다. 거기에 따라서 각자 어떤 업무를 누구와 하고, 어디까지 가이드를 세밀하게 제시할 것인지가 달라지기 때문입니다. 오랫동안 같이 일한 팀원이면 척하면 척이지만 디자인 컨설팅 회사에서는 계속 같은 팀원이랑 일하기보다 절반은 같이 일해본 사람, 절반은 새로운 사람이랑 일하는 경우가 많습니다.

내용 만들 때랑 역순으로 생각하기
일을 배분하던 과정을 생각해보면(저도 처음(?) 하는 것이라 잘한 건지는 모르겠지만) 제가 일을 받아서 하던 과정과 역순으로 생각했던 것 같습니다. 보통 'A라는 내용을 이때까지 만든다'라고 하면 내용 덩어리를 만들고, 다른 분들이 만든 내용과 합쳐서 하나로 이어지게 톤/순서를 다듬었습니다.

반대로 업무를 배분할 때는 클라이언트에게 전달해야할 산출물을 먼저 생각합니다. 언제까지 어떤 요구사항을 담아서 만들어야 하는지 생각하고, 산출물을 구성하는 작은 덩어리로 나눕니다. 각 덩어리 간에 선후/인과 관계가 있을수도 있고, 실제 산출물이 아니라 밑바탕이 되는 작업이 있을수 있습니다. 이렇게 '만들어야 할 덩어리'를 리스트업 해봅니다. 다음으로는 각 덩어리를 누구에게 분배하는게 적합할지 고민해서 누가 언제까지 덩어리를 완료할 것인지, 하나로 합쳐서 톤을 맞추는 작업 시간을 고려해서 배분합니다.

혼자서 결정할 필요는 없다
이걸 혼자서 다 결정하고 생각할 필요는 없고 최종 산출물, 언제까지 해야되는지부터 팀원들과 얘기하면서 정해나가면 됩니다. 특히 프로젝트 초반부일 때는 어떻게 흘러갈지 아무도 정확히 알수 없기 때문에 초반에 충분히 팀원들과 논의해서 해야할 업무 덩어리를 구체화해 나가는게 좋습니다.

관심사/스킬에 맞추어 업무 배분
하기 싫거나 관심없는걸 하고 싶어하는 사람은 없겠죠. 최대한 팀원의 관심사, 잘하는 것에 맞춰서 배분을 하면 더 효율이 납니다. 팀원의 관심사나 잘하는걸 파악하는 방법은 우선 프로스펙티브때 물어보는 방법이 있습니다. 이번 프로젝트에서 목표, 얻고 싶은것, 해보고 싶은 역할 등을 구글 시트에 같이 작성해서 얘기하고 프로젝트 중간에 들여다 보면서 팀원의 목표와 현재 업무가 잘 맞아 떨어지는지 생각해 보았습니다.

내부 회의를 하다보면 (누구나 자유롭게 자기생각을 말할수 있는 분위기라면) 각자 목소리를 높여 주장한다거나 자기 의견을 주로 펼치는 지점이 있습니다. 특히 평소에 조용하다가도 이 주제만 나오면 얘기를 많이 하는 사람이요. 시각적인 부분에 목소리를 내는 사람, 논리에 목소리를 내는 사람, 실현 가능성을 주로 이야기하는 사람 등 각자 달랐습니다. 그럼 저는 그 사람이 해당 주제에 관심이 있다고 판단했습니다. (^_^;; 아니었다면 죄송;)

이외에 논의를 하면서 결정하는 업무라면 어떤 사람들을 같이 붙여서 한 덩어리를 완성하도록 요청해야 할지 생각해봅니다. 아니면 전체 논의를 하고 각자 나눠가지면 되는 업무일수도 있고요. 혼자 하는게 더 효율적인 업무일지 판단해야 합니다.

4. 비용/리스크 관리하기

컨설팅 회사에서 비용은 실제 금전적으로 나가는 게 있고(외주, 사용자 사례비 등) 인력(기간, 인원수, 작업시간)도 있습니다. 팀원일때는 사용자 사례비 말고 비용에 대해서는 크게 신경쓰지 않았었습니다. PM이 되면 회사 수익성을 따져 비용을 생각하고 결정해야 합니다. 추가 비용이 들것 같다면 그룹장 님, 경영지원 팀과 논의가 필요합니다. 팀원이 업무를 하는 기간, 작업 시간, 투입하는 인원 수도 비용이 됩니다.

프로젝트를 하다가 클라이언트 사 내부 사정 때문에 일정이 뒤로 밀리거나, 내부 의사결정이 늦어지는 경우, 또는 보고 했을 때 추가 요청이 있어서, 내부에서 요구사항이 변경되어 추가 비용이 발생하는 경우 등의 리스크를 미리 생각해보는 것도 좋습니다. 여기서 제가 몰랐던 점은 영업 단계에서 정한 최종 산출물의 형태나 범위가 프로젝트를 진행하면서 조정될 수 있다는 점입니다. 그렇게 되면서 조금씩 일정, 투입인력, 필요한 외주업체 등 비용이 달라질 수 있습니다.

마치면서

각자에게 '프로젝트 관리'라는 말이 다르게 다가올테고, 본인 성향에 따라 조금씩 팀원에게 위임하는 범위도 다를 것입니다. 시작하기 전에 나에게 PM 역할이 무슨 의미인지 고민해보는 것도 도움이 될거 같습니다. 처음 PM을 해보는 제게 전부다 잘하려고 부담을 갖지 말고, 하나의 목표만 세워서 그거에 집중하라고 하셨습니다. 그때 재밌게 하기를 목표로 삼았고, 다른건 모르겠지만(?) 재미는 잘 달성했던거 같습니다. 저처럼 처음으로 새로운 역할을 맡게 되는 분들이라면 처음부터 잘하는 사람은 많지 않으니, 내가 이번 경험으로 얻고 싶은 하나만 한번 정해보는건 어떨까 싶습니다.

*본 내용은 작성자의 개인적인 의견이며, 회사의 공식적인 입장과 다를 수 있습니다.
*이 콘텐츠의 원문은 박재현 모니카님의 브런치입니다. 제로베이스 미디어에서 더욱 다양한 필진의 인사이트 콘텐츠를 만나보세요.
*해당 콘텐츠의 저작권은 원문 작성자에게 있으며, 무단 전재, 복사 및 배포 등을 금지합니다.

추천 컨텐츠