brunch

매거진 프로덕트 매니지먼트 101

라이킷 23 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 파이온티어 사나 Oct 17. 2023

PM 면접 전 꼭 알아야할 직무관련 오해 10가지

프로덕트 매니저로의 취업/이직러 외 신입/주니어에게도 유용합니다

프로덕트 매니저,

프로젝트 매니저,

프로덕트 오너…?

도대체 뭐가 다른거지?

12/27(수) "면접관이 알려주는 절대합격 PM/PO 면접공식" 세션 OPEN 자세히보기

다~ 비슷해보이고 똑같아보이는 명칭 때문에 한국에서는 프로덕트 매니저에 대한 잘못 알려진 사실들이 많다. 특히 프로덕트(Product) 매니저라는 명칭은 프로젝트(Project) 매니저와 동일하게 PM이라는 축약어로 불리기 때문에 두 직무가 동일하다고 인식되는 경우가 많고, 구인공고에서 프로덕트 오너(PO)와 같은 직무로 통칭되는 경우도 많다. 이에 지원자들이 프로덕트 매니저 직무에 대해 지원하기에 앞서서 무엇을 중점적으로 준비해야하는지 면접에서는 직무이해 관련 질문에 뭐라고 대답해야하는지 헷갈려하는 경우가 많다. 이 글에서는 프로덕트 매니저라는 직무가 정확히 어떤 역할을 하는 사람인지, 어떤 것을 중점적으로 여겨야 하는지 등을 알 수 있도록 프로덕트 매니저라는 직무에 대한 흔한 오해 10가지에 대해 알아보고 정확하게 직무에 대해 이해할 수 있도록 오해를 풀어보고자 한다.

1. 프로덕트 매니저는 프로젝트 매니저와 동일하다?

프로젝트 관리자는 말 그대로 ‘프로젝트’를 관리하는 사람이다. 이 말을 이해하려면 '프로젝트’가 정확히 뭘 의미하는건지 알아야 한다. 프로젝트라 함은 (1) 시작과 종료가 분명하고 (2) 명확한 산출물이 존재하며 (3) 유일무이 (4) 불확실성 (5) 점진적 구체화 의 특징을 가지는 활동이다. 따라서 프로덕트 매니징과 프로젝트 매니징은 다르다. 프로젝트 자체가 프로덕트의 라이프 사이클안에 속하기 때문이다. 프로덕트 라이프 사이클을 간략하게 설명하자면 (1)비즈니스 플랜 > (2) 제품개발 프로젝트 (시작-진행-종료) > (3) 운영(생산, 유통, 판매, 판촉, 서비스 등)을 반복하는 것이다. 이처럼 프로덕트 라이프 사이클에 프로젝트가 포함되어 있기 때문에 '프로젝트' 관리를 업무의 큰 부분으로 수행하고 있는 프로덕트 매니저도 있을 것이다. 그러나 이것이 프로덕트 매니저의 주요 역할은 아니다. 프로젝트의 일정과 리소스 조정 등이 주요 관심사인 직무는 프로덕트가 아니라 프로젝트 매니저이다. 또한 프로젝트 매니저는 요구사항을 수집하는 업무를 담당한다고 해도, 요구사항을 파악하고 무엇을 채택할지 ‘선택’하는 의사결정 자체에는 많은 권한이 없다. 반면에 프로덕트 매니저는 제품과 관련한 문제와 기회를 파악하고, 어떤 것을 추구해야하는지 '선택'한다. 그리고 해결책을 생각하거나 디자이너와 개발자와 협력해 팀이 훌륭한 해결책을 도출할 수 있도록 하는 책임을 가진다.

잠깐, 프로덕트 매니저 VS 프로덕트 오너

프로덕트 매니저는 제품의 비전과 전략을 세우고 이해관계자와 소통하는 것에 중점을 둡니다. 반면 프로덕트 오너는 구체적 요구사항을 백로그에 정의하고 스크럼 팀과 협업하여 제품을 구체적으로 구현하는 역할을 수행합니다.

그러나 이 직무개념은 실리콘벨리에서 넘어온 것으로, 한국에서는 사실상 거의 혼용하여 사용합니다. 특히 스타트업처럼 규모가 작은 조직에서는 한 명이 여러가지 업무를 맡기 때문에 더욱 혼용된 개념으로 사용한다는 점을 기억하세요!

1. 프로덕트 매니저 (Product Manager)

비전 및 전략 수립: 제품 비전과 전략수립, 시장조사, 경쟁사 분석으로 제품의 방향성 결정

이해관계자 관리: 다양한 이해관계자와의 소통, 사업적 요구사항 이해, 고객의 니즈 파악

로드맵 관리: 제품의 로드맵을 작성/관리하며, 제품의 중장기적 개발 방향 제시

팀 리더십: 개발자, 디자이너, 마케터 등 다양한 사람과 협업하여 제품의 성공 이끌기

2. 프로덕트 오너 (Product Owner)

구체적 요구사항 정의: 제품 개발에 필요한 요구사항을 정의하고, 우선순위에 따라 관리

스크럼 팀과 협업: 스크럼 팀과 작업하면서 제품 백로그를 관리하고, 스프린트를 계획

기능 우선순위 지정: 제품 백로그 기능별 우선순위를 정하고, 각 스프린트에서 개발할 기능을 결정

피드백 수용: 스크럼 팀과 이해관계자로부터 피드백을 받아 백로그 조정, 개발 방향 조율

2. 프로덕트 매니저는 마케팅에 관련된 직무이다?

때때로 마케팅 관련 직무중에서도 프로덕트 매니저라고 부르는 직무가 있어서 혼동이 야기되기도 한다. 그러나 보통의 스타트업이나 IT 업계에서는 프로덕트 매니저는 주로 마케팅이 아니라 개발조직에 속해있다.

마케팅 담당자들은 사용자들을 제품으로 ‘유입’시키는 데 집중하는 반면, 제품 관리자들은 사용자가 제품 ‘내부에 있다면’ 어떤 일이 일어나는지 정의한다. 예를 들어, 마케팅 담당자는 마케팅 메시지를 생각해 내고 SNS광고캠페인에 관여하지만, 프로덕트 매니저는 제품에 들어갈 새로운 ‘기능’을 생각해내고 그것을 런칭하기 위해 개발자들과 협력한다. 마케팅 담당자들은 브랜딩에 도움이 되는 기능에 대해 프로덕트 매니저들과 토의할 수는 있지만, 그들이 그 기능들의 세부사항을 직접 정의하지는 않는다. 또한 그 기능들 구현하기 위해 개발자들과 직접 협력하지도 않는다.

3. 대학 졸업 후 바로 프로덕트 매니저가 될 수는 없다?

‘매니저’라는 단어 자체가 사람들이 프로덕트 매니저가 되기 위해 많은 경험이 필요할 것이라고 생각하게 만든다. 또한 프로덕트 매니저는 제품이 나아갈 방향에 대해 직접적인 영향을 끼치는 결정들을 많이 내리는 사람이다보니, 이 일은 시니어가 해야하는 역할로 보이기도 한다. 하지만 구글, 마이크로소프트, 페이스북, 야후 등과 같은 유명한 IT 회사에서는 갓 대학에서 졸업한 사람들을 프로덕트 매니저로 고용하고 있다. 왜냐하면 이들의 열정, 고객에 대한 집중, 넘치는 에너지 등이 프로덕트 관리자로서 성공하기 위한 중요한 요건이 된다고 보기 때문이다. 따라서 이 글을 읽는 독자가 프로덕트 매니저가 되고 싶은데 그 전에 다른 일을 먼저 해야하나 고민하는 중이라면 그럴 필요가 없다고 말하고 싶다.

다음은 실제로 대학졸업자를 바로 매니저로 고용하는 외국 사례이다.

Google - “Associate Product Manager”

Uber - "Associate Product Manager”

Yelp - “Associate Product Manager”

LinkedIn - “Associate Product Manager”

Facebook - “Rotational Product Manager”

Workday - "Rotational Product Manager”

Dropbox - “Product Manager”

Yahoo! - “Associate Product Manager”

eBay - “Associate Product Manager”

4. 프로덕트 매니저는 제품명세(스펙)만 작성하면 된다?

프로덕트 매니저라는 직업은 개발자와 디자이너와는 아주 다르다. 개발자는 잘 작동하는 코드를 작성해야 하고, 디자이너는 와이어프레임과 목업을 디자인해야 한다. 그러나 프로덕트 매니저는 제품의 스펙만을 정의한다고 끝나는 일이 아니다. 프로덕트 매니저는 프로덕트의 개발을 시작하고 성공적으로 완료하기까지 전 과정을 책임진다. 제품의 명세서를 작성하는 일은 프로젝트를 진행시키고 의사소통하기 위한 하나의 기술일 뿐, 명세서를 작성하는 일 자체가 고유한 가치를 지니는게 아니다. 실제로 많은 프로덕트 매니저들이 명세서 없이도 대화만으로 전달하거나, 화이트보드 등에 아이디어를 그려가면서 팀원들과 의사소통한다. 만약 프로덕트 매니저가 명세서를 잘 작성했다 하더라도 다른 개발자와 디자이너가 그 명세서에 적힌 내용을 제대로 이해하고 구현하는지 명확하게 확인하면서 진행하지 않아서 실패하는 경우도 많다.

5. 프로덕트 매니저는 이해관계자들과 회의만 잡으면 된다?

몇몇 사람들은 프로덕트 매니저의 역할이 주요 이해관계자들을 한 회의실에 모아서 그들이 의사결정을 내리도록 만드는 것이라 생각하기도 한다. 하지만 좋은 프로덕트 매니저들은 단순히 다른 사람들의 의견을 수동적으로 받아들이고 전달하는 역할만 하지 않는다. 좋은 프로덕트 매니저라면 제품이 속한 분야에 대해 조사하고 좋은 의사결정을 위한 자신만의 관점과 틀을 생각해낸다.

물론 프로덕트 매니저가 주요 이해관계자들을 만나 그들의 의견을 이해하고 우선순위를 파악해야 하는것은 맞다. 그러나 그 이후에는 그런 관점들을 종합해 절충안을 제시하고 이해관계자들을 만족시킬만한 권고안을 제시할 수 있어야 한다. 또 어떤 회의나 대화에서든, PM은 회의에 참석하지 못한 모든 사람들의 이해관계를 대변할 필요가 있다.

또한 제품 관리자들은 오히려 동료들이 참석해야하는 회의의 수를 줄일 수도 있다. 왜냐하면 프로덕트 매니저가 팀을 대표해서 다른 팀과 회의할 수 있고 굳이 회의까지 하지 않아도 될 생산적인 의사소통 방법을 찾을 수도 있기 때문이다.

6. 프로덕트 매니저는 고객의 요구를 곧이곧대로만 구현하면 된다?

당연히 고객의 의견을 조사하고, 고객의 요구사항을 유심히 듣는 것은 아주 좋은 일이다. 그러나 그것만으로 충분하진 않다. 프로덕트 매니저는 고객이 말하는 것 이상의 숨겨진 요구를 파악할 수 있어야 한다.

외국의 한 사례로, Oxo라는 주방제품 회사가 있다. 이들은 고객에게 자신들이 팔고 있는 계량컵이 무슨 문제를 갖고 있는지 물어보았다. 고객들은 주로 컵이 떨어질 때 잘 깨진다던가, 손잡이가 미끄럽다고 이야기 했다. 그러나 Oxo는 고객들의 요구사항을 곧이곧대로 받아들이는것이 아니라 고객이 컵을 사용하는 모습을 직접 관찰하는 시간을 가졌다. 그들은 고객이 계량컵에 든 내용물을 붓고 나서 얼마나 부었는지 남은 치수를 읽으려고 몸을 구부린 뒤, 다시 일어나서 내용물을 붓고, 또 치수를 확인하기 위해 몸을 구부리는 것을 반복하는 걸 보았다. 고객이 스스로 '내용물을 부으면서도 동시에 치수를 확인할 수 있게 해달라'고 말하지 않았지만 Oxo는 관찰을 통해 고객의 숨겨진 니즈를 ‘발견’했다. 그래서 Oxo는 이제 내용물을 부으면서도 치수를 확인 할 수 있도록 치수 표시가 비스듬하게 되어있는 컵을 판매하고 있다.

Oxo 의 계량컵. 내용물을 부으면서 치수를 확인할 수 있다.

7. 프로덕트 매니저가 개발일정을 결정한다?

구글의 PM인 Nundu는 말했다.
“프로덕트 매니저는 날짜를 결정하지 않는다. 엔지니어들이 결정한다.”

프로덕트 매니저는 팀에게 무엇을 개발하길 원하는지 말할 수 있다. 하지만 그 후 그것을 실제로 개발하기 위해 얼마나 걸리는지 이야기하는건 '팀원들'이다. 만약 기간이 너무 길다고 해서 프로덕트 매니저가 더 빨리 코딩할 수 없냐고 물어볼 수도 없으며, 그렇게 되지도 않는다. 만약 꼭 맞춰야 하는 외부 마감일이 있다면 팀원들과 절충하고 협상해야 한다. 특정 기능을 생략하거나, 작업을 병렬화하는 방안을 찾거나, 혹은 도와줄 수 있는 더 많은 사람들을 찾아야 한다. 어쩌면 더 창의적으로 개발자들의 기존 업무 부담을 줄이는 방법을 찾을 수도 있다. 예를들어 개발자들이 기존에 하던 불필요한 회의에서 벗어나게 하는 방법 등이 그렇다.

참고로 개발자가 일정에 대해 낸 견적을 신뢰하지 않는 것, 개발자가 동의한 기간보다 빠르게 작업될거라고 다른 팀에게 약속하는 일만큼 팀내 관계를 망치는 빠른 방법은 없을 것이다.

8. 프로덕트 매니저는 보스이다?

몇몇 사람들은 프로덕트 매니저의 역할이 팀의 보스가 되는 것이라고 말한다. 하지만 현실적으로 프로덕트 매니저는 팀에게 직접적으로 지시할 수 있는 권한이 없다. 팀원들에겐 PM의 말을 그대로 따를 의무가 없다. PM은 ‘권한’이 없이도 영향을 미칠 수 있어야 한다. 팀원들과 신뢰를 쌓고, 명확하게 의사소통하면서 데이터를 조사/수집하고, 팀을 이끄는 설득력을 갖춰야 한다. 팀원들은 PM이 자신들의 목표와 잘 부합하며 PM이 자신들이 가진 개별적 목표를 더 효과적으로 달성하는 데 도움을 줄거라 확신할 때 PM을 따르게 된다.

즉 프로덕트 매니저는 디자이너나 개발자에게 하나하나 마이크로매니징을 하면서 무엇을 해야하는지 알려줘서는 안된다. 제품의 디자인에 대한 권한은 디자니어가 부여받아야 하며, 기술적 구현에 대한 권한은 개발자가 부여받아야 한다. 디자이너와 개발자들이 결정하는 세부사항들이 프로덕트의 전체 방향과 일치하지 않는 경우 기꺼이 프로덕트 매니저로서 의견을 표현할 수 있어야 하지만, 하나하나 그들이 선택하는 사항들에 대한 결정을 통제하려 해서는 안된다.

9. 아이디어가 실행보다 더 중요하다?

갓 프로덕트 매니저가 된 주니어 PM들은 종종 아이디어를 내는 그 자체가 가장 중요한 일이라고 생각하는 경우가 많다. 실제로는 아이디어 그 자체보다 아이디어의 ‘실행’이 훨씬 중요하다. 많은 팀원들이 다양하고 훌륭한 의견들을 제시하지만 일반적으로 실무에서 진짜로 어려운 부분은 ‘세부사항’을 완성하는 것이다. 즉 프로덕트 매니저로서 헤야하는 중요한 일은 초기의 광범위한 아이디어를 구체적이고 실행가능한 단위로 쪼개는 일이다. 간과하기 쉬운 극단적인 예외 케이스를 고려할 수 있어야 하고, 아이디어를 현실로 만드는 데에 필요한 모든 작은 단계들을 설정할 수 있어야 한다. 이러한 절차를 수행하다보면 자주 귀찮은 작업을 해야할 때도 많다. 코드를 실행할 서버를 찾아내거나, 다른 팀이 프로덕트 매니저가 관여중인 작업에 더 높은 우선순위를 두도록 설득해야 하거나, 제품을 지속적으로 사용하고 문제점을 찾아 보완하는 작업 등이 있다.

10. “그건 제 일이 아닌데요”

개발자와 디자이너의 역할은 비교적 명확하게 정의되어 있다. 하지만 프로덕트 매니저의 역할은 매우 유동적이다. 만약 이 글을 읽는 독자가 프로덕트 매니저라면 당신의 업무는 다른 사람이 다루지 않는 거의 모든 업무라 할 수 있다. PM으로서 당신은 제품의 성공과 실패에 대한 책임을 지게 된다. 이 과정에서 필요한 어떤 일도 가치가 없는 일은 없다. 아무도 하기 싫어하는 일이 있다면 PM이 스스로 하더라도 그 작업을 완료해낼 방법을 찾아야 한다. 그 업무를 확실하게 마무리 하지 않고 그저 지나가게만 내버려 둔다면, 어떠한 누구라도 그 일을 스스로 맡아 처리되도록 보장해주지 않을 것이다.

결국, 프로덕트 매니저는 아이디어의 구현에서부터 성공적인 제품을 만들어내는 과정의 주도자로서, 누구보다도 열정적이고 책임감 있는 사람이어야 한다. 즉 프로덕트 매니저로서 지녀야 하는 핵심은 '책임지기'라 볼 수 있을 것이다. 프로덕트의 성공과 실패에 대한 책임을 질 때, 어떤 업무라도 가치있고 중요하다고 여기며 소홀히 대하지 않는 것이 중요하다.

이상으로 PM 직무에 대한 흔한 오해 10가지를 살펴보았다. 현재 프로덕트 매니저로 일하고 있는 사람이 실무에 적용하거나, 이 직무로의 전환을 희망하는 사람들이 직무이해도를 높여 면접에서 관련 질문이 나왔을 때 잘 대응할 수 있도록 도움이 되는 글이었으면 한다.