진정한 프로덕트 매니저란 이런 것이다.
ㅡ IDEO 비즈니스 디자이너가 말하는 PM이란 직업
매일 겸손함과 열린 귀, 그러면서도 사용자를 포함하여 내 주변 동료라는 스테이크홀더의 의견을 잘 조율하는 능력을 길러야함을 느낍니다.
프로덕트 매니저는 제품/서비스를 관리하는 것이 아닌, 해결해야하는 문제를 정의하고 관리하는 사람이란 의미이다. 프로덕트 매니저는 개발자도 아니요. 디자이너도 아니요. QA담당자도 아니요. 마케터도 아니요. 그렇다고 제품에 대한 아이디어만 쏟아내는 사람도 아니다. 또한 자기가 해당 서비스 관리의 '장'도 아니다. 그래서 다른 직군 담당자에게 일방적으로 명령만 하는 역할을 갖는 것으로 오해하면 안된다.
전 세계, 프로덕트 매니저를 지망하는 사람들이 늘어나고 있다고 생각하는 건 저뿐만이 아닐 것입니다. 저 자신이 프로덕트 매니저로 일하고 있기 때문에 그렇게 느끼는 걸지도 모르겠네요. 그렇다 할지라도, 최근엔 컨설턴트나 MBA후보, 엔지니어 등 누구나가 프로덕트 매니저를 지망하고 있단 느낌을 받습니다.
혹 이 일이 사실이며, 설령 정말로 '모두가' 프로덕트 매니저가 되길 원한다 하더라도 놀랍지는 않습니다. 확실하게도 기술을 깊이 연구하는 일이 아닌, 잘 활용하는 일에 가까우니까요. 프로덕트 매니저가 되기 위해 어떻게 데이터 모델을 만들지를 알고 있을 필욘 없고, 코딩을 해야할 필요도 없으며 웹사이트를 디자인해야 할 필요도 없습니다. 플러스가 되지만 필수는 아닙니다. 엔지니어와 디자이너가 되는 것과 달리 프로덕트 매니저라는 직종은, 어느 날 눈 떴더니 되어있을 수도 있습니다.
여기에 추가로 프로덕트 매니저 롤에 대해 적어보자면 어떤것이든 다 좋아 보입니다.
회사의 mini-CEO이다.
다른 멤버를 이끄는 역할이다.
업계에 능통하다.
오늘 그리고 미래의 프로덕트 겉모습과 속을 결정하는 역할이다.
급여가 높다.
당신이야말로 보스다.
이 리스트는 농담입니다. 프로덕트 매니저라는 직업은 종이 위에 다 적어내리기엔 모자를 정도의 놀라움으로 가득 차 있기 때문입니다. 당신이 아직 PM이 아니며 또한 지금까지 회사에서 PM과 깊이 있는 교제를 해오지 않으셨다면 프로덕트 매니지먼트의 실태는 당신이 상상하는 것과는 분명 다를 겁니다.
프로덕트 매니지먼트의 일
유저의 마음과 머리, 목소리가 되는 것
분야를 가로지르는 팀워크를 촉진시키는 일
프로덕트에 대한 트레이드오프를 실시하는 일
한정된 자원과 기한안에 최종 목표에 이르러야 하는 일
프로덕트 여정 속에서 일관하여 사람들을 이끌어 나가는 일
긍정적 그리고 실천적이어야 할 것
적은 정보를 갖고 어려운 판단을 내리는 일
프로덕트 매니지먼트가 아닌 일
더욱 중요한 '의견'인 것
단지 한 사람의 아이디어 제안자인 것
디자이너인 것
프로그래머인 것
QA를 관리하는 일
웹사이트를 최적화하는 일
마케팅에 부임하는 일
어떻게 나는 이것들을 아는가?
How I know
제가 프로덕트 매니저에 지원한 건 즉흥적이었습니다. 당시 저는 심리학 전공의 대학교 4학년 학생이었죠. 베이 에어리어(Bay Area)에 어떻게든 돌아가고 싶었고 하나 안타깝게도 넘치는 테크놀로지 업계에만 자리가 넘쳤습니다. 심리학이란 자신의 전공이 하찮아지지 않도록 필사적으로 직업을 찾았습니다.
저 자신도 놀라웠는데요, 기술적 또는 문화적으로도 훌륭한 Intuit란 기업 프로덕트 매니지먼트 어소시에이트에서 오퍼를 받았습니다. 스스로도 놀랐습니다. 프로덕트 매니저 일이 어떤 건지 몰랐었으니까요. '와우!' 채용 통보서를 반복해 읽으며 생각했습니다. "그 인터뷰에선 그저 나의 열정에 대해 말했을 뿐이었는데. 그걸로 충분했다니 믿을 수가 없는걸". 제 졸업 논문 테마는 심리언어학으로, 제가 알고 있는 한 이는 금융 소프트웨어와는 거리가 멀었습니다.
제가 처음 프로덕트 매니지먼트 역할을 담당한 건, QuickBooks였습니다. 일 년에 한 번 릴리즈 되는 베타 버전 관리를 담당하며, 그때의 모든 경험이 프로덕트 매니지먼트에 임하는 데 있어서의 놀라운 일들을 요약해주었습니다. 그 어떠한 일들도 저의 (입사 당시) 직무 개요에는 기제되지 않았었죠.
주로 4가지가 있습니다.
1. 당신은 프로덕트를 관리하는 것이 아니다. 해결할 과제를 관리한다.
QuickBooks를 담당하게 되었단 걸 알았을 때 토할 것 같았습니다. "응? QuickBooks라고?"라며 바보 취급했었죠. "우리 할아버지보다 나이가 많잖아!"(실제론 그렇지 않지만 매 초 새로운 프로덕트가 생기는 실리콘밸리에서 QuickBooks는 아버지 세대의 것처럼 느껴졌습니다.) "진정한" 프로덕트 매니저처럼 "창조"하는 일을 할 수 없음에 분했습니다. 어리고 섹시한 프로덕트를 담당하지 못했었던 거죠.
이 인식이 얼마나 잘못됐었지요.
고객이 한 명이라도 있는 프로덕트를 관리하게 된다면, 당신의 일은 완전히 기능을 갖춘 프로덕트를 웃도는 거대한 일임을 깨닫게 됩니다. 프로덕트가 해결하고자 하는 과제를 깊이 이해하는 일이야말로 프로덕트 매니저의 일이며, 이 일이 가능해지면 과제 하나하나의 세세한 뉘앙스를 해결하기 위해 일하게 됩니다.
언제나 기능 추가 요구사항들이 넘쳐 돌아오며, 엄청나게 많은 시간이 있더라도 그걸론 부족합니다. 버그는 산더미고 시간은 계속해서 흘러가죠. 해야 할 일은 끝나질 않습니다. 사용자가 이미 습관들인 성숙한 프로덕트일 경우, 또는 기업에 독자적인 프로세스가 설계돼있는 경우, 제약을 극복하기 위해 더욱 이노베이티브 해질 것이 요구됩니다.
프로덕트 매니저가 된다는 것은 당신 팀이 결정한 기한 내에 달성할 수 있는 일과 고객이 뭐가 무엇이든 간에 필요로 하는 것과의 사이를 타협하고 균형 잡아가는 일입니다.
2.프로덕트의 장점은 사용자의 인식이 결정한다.
베타 버전을 운영하며 매주 E메일로 테스터들이 테스트를 잘할 수 있도록 돕고 전화로도 이야기하고, 때로는 일주일에 하루를 통째로 기술적인 서포트를 실시했습니다. 처음엔 이렇게 된 것에 그저 실망할 뿐이었습니다. 왜 내가 트러블에 대해 답변해주고 있어야 하지? 프로덕트 매니저인데 말이야!라고 자문자답했었습니다.
그 뒤로도 고객과의 커뮤니케이션을 더하고 더해 그, 그녀들이 어떻게 프로덕트를 사용하는지를 관찰함으로써, 그녀들이 '제대로 못한다'라고 말할 경우 이는 그녀들이 기대하는 것처럼 되지 않는다는 의미임을 배웠습니다. 고객에 따른 인식이야말로 현실이며, 여기서 '당신이 하는 방식은 틀렸어요'라고 지적하는 것은 제 일이 아닙니다.
거꾸로 그녀들과 계속해서 커뮤니케이션을 주고받음으로써 제 자신이 틀렸음을 깨달았습니다. 저는 이 깨달음을 엔지니어나 디자이너에게 피드백하였고 어떻게 하면 프로덕트의 기능이 사용자에게 있어 쓸만한 것이 되는지에 대해 브레인스토밍 하였습니다.
마지막으로 몇 시간, 며칠에 걸쳐 프로덕트에 대해 고객과 이야기 나누는 일을 늘린 점이 프로덕트를 알리는 일이 되었습니다. 알려서 정말 좋았었네요. 프로덕트가 우선 존재해야지만 프로덕트를 맡길 수 있겠죠.
3. 프로덕트 매니저는 디자이너가 아니면서 엔지니어도 아니다.
Mac 앱 스토어에 등록할 때 프로모션 페이지를 같이 디자인해야 한다는 요청을 받았었습니다. 아직 게임에 익숙하지 않았던 탓에 전 이를 "문자 그대로" 받아들여 Photoshop 레이어와 컬러 팔레트를 스스로 건드렸습니다. 창조 프로세스에 동반하는 일들에 현기증을 느끼며 열심히 노력해 완성시킨 페이지를 매니저에게 보냈습니다.
그에게 내가 기대했던 칭찬과는 먼 거리의 답변이 돌아왔습니다.
"와우. 이거 우리 디자이너가 한 작업물이에요? 배색에 대해 그녀가 좀 다시 해줘야겠는데요?"
"디자이너? 뭐라고?" 무의식적으로 컴퓨터에 말을 걸었습니다.
이 한 가지 사건으로 깨달은 점. 이는 순조로운 대기업에서는 특히 프로덕트 매니저는 비주얼 디자인을 하지 않는다는 일입니다. 그녀는 코드를 적지도 않습니다. 당신의 디자이너야말로 디자인 전문가이며, 당신의 엔지니어야 말로 프로그래밍 전문가입니다. 그리고 프로덕트 매니저인 당신은 그 디자인과 기능이 눈 앞에 있는 특정 사용자의 니즈에 맞게 잘 되어있는지를 살펴보는 전문가겠죠.
4. 별이 되고자 하는 것이 아닌 우주를 관리하는 일이다.
프로덕트 매니저로써 QuickBooks 팀에 배속된 첫날, 매니저가 함께 사무실을 둘러보며 멤버들을 소개해주었습니다. 그것도 전원을 말이죠. 서포트, 마케팅, 엔지니어, 디자인, 재무. 압도되어버렸습니다. 그것보다 신경 쓰였던 건 시간 낭비라 생각됐던 점입니다. 그냥 다른 프로덕트 매니저만 소개해주면 되잖아, 하고 말이죠. '분명 나중에 소개해주겠지'하고 마음속으로 생각했습니다.
소개받은 많은 사람들에게 놀랐던 것 이상으로 저를 불안하게 만든 점은 매니저가 저를 소개했을 때입니다.
"QuickBooks를 론칭할 책임자입니다."라고 소개했으니까요. 아직 QuickBooks를 내 컴퓨터에 다운로드조차 안했는데 어떻게 프로덕트를 론칭한다는 건지 수수께끼였습니다.
그리고 수주가 지나 QuickBooks 릴리즈는 절대로 독단적인 작업이 아님을 깨달았습니다. 제 역할은 첫날 인사한 많은 그룹들 간의 적절한 브레인스토밍과 대화를 촉진함으로써 론칭을 위한 다양한 의사결정을 실행해나가는 일이었습니다. 이 일이 계기로 조금은 (어디까지나 조금) 안심도 되었니다. 회의실에서 항상 최적의 아이디어를 생각해낼 필요가 없으며 저는 최적의 안을 선택할 수 있게끔, 풍부한 아이디어를 만들어니기 위해 이 일들이 가능한 적절한 사람들을 모으는 일만을 철저히 했으면 되었으니까요.
3년 동안 아주 작은 규모의 스타트업에서 프로덕트 매니저로 일을 해오며 가장 처음 면접 때 전달한 열정, "다른 사람들을 깊이 이해하는 일, 사람의 생활 속에서 불편함을 없애는 일, 적는 일, 현장에 대해 아는 일, 데이터에서 패턴과 트렌드를 발견하는 일, 사람을 위해 디자인하는 일", 이것이야 말로 면접관이 찾고 있었던 것이라는 점을 깨달았습니다. 왜냐하면 이것들이야 말로 훌륭한 프로덕트 매니저에게 빼놓을 수 없는 요소니까요.
프로덕트 매니저로서 현재 진행형으로 떠안고 있는 염려와 불안감은 있습니다. 엔지니어와 이야기할 때 바보 같은 자신에게 질려버리거고, Web 사이트를 스스로 디자인하면 좋았을 텐데, 하고 바라고, 감독관인 내게 혐오감을 느끼며 Jira(*협업 툴) 다른 사람들에게 속기관 정도로밖엔 보이면 어쩌지하고 걱정합니다. 잘못해서 연구원의 발부리를 밟거나 그저 감사함은 받지 못하는 역할이 아닐지 자신에게 의문을 품습니다.. 그래도 결국 사용자가 웃으며 프로덕트를 사용하는 모습을 보고 있노라면 그러한 것들을 웃돌 가치가 충분히 있다고 생각됩니다.
프로덕트 매니저라는 일은 직함에 '매니저'라는 단어가 그저 따라붙는 것으로 끝이 아닙니다. 확실하게 의사결정을 해나가는 사람은 바로 당신입니다. 하나 동시에 모든 프로덕트의 흥망성쇠도 당신의 책임입니다. 사용자가 프로덕트를 이해하지 못하는 건 당신의 책임이며, 전략실 책임이 아닙니다. 사용자가 버튼을 찾지 못하는 건 당신 책임이지 디자인 책임도 아닙니다.
그리고 또한 타깃 유저가 당신 프로덕트를 쓸모없다 여기는 건 당신 책임이지 그 타깃 유저 책임이 아닙니다.
Ira와 Brandongador 협조에 감사드립니다.
(번역끝)
