어쩌다 PM
디자이너 출신 PM의 우당탕탕 적응기
이번에도 원티드(Wanted)의 의뢰를 받아 디자이너에서 PM이 된 이야기를 작성했습니다. <어쩌다 커리어> 시리즈 중 1화이며, 원티드 홈페이지에서도 확인하실 수 있습니다.
현재 카카오뱅크 고객인증팀에서 기획자 겸 프로덕트 매니저(이하 PM)로 근무 중입니다. 각 서비스 별 사용자 레벨과 인증 정책을 결정하고, 편리한 인증 수단을 만들기 위해 고민하고 있죠. 은행업에서 고객과 인증을 다루는 일은 매우 논리적이고 이성적인 능력을 필요로 합니다.
그러나 아이러니하게도, 저는 정반대의 일을 하던 사람이었어요. 불과 얼마 전만 해도 감각을 중요시하는 그래픽 디자이너였죠. 대학 졸업 후 2년은 시각디자인의 정수(精髓)인 편집 디자이너로 일했고, 3년은 1인 디자인 스튜디오를 창업해 운영했습니다.
혼자 일한 3년은 커리어 전환에 매우 큰 디딤돌이 됐습니다. 그때의 저는 일종의 실험을 하고 있었는데 회사에 속하지 않고 홀로 서기 위해 고군분투했어요. 일반적으로 회사나 타 부서에서 처리해 주는 일들 -이를테면 계약이나 세무, 회계, 영업 등-을 전부 혼자 처리했죠. 그 과정에서 스스로와 일에 대한 깊은 성찰도 했어요. 나는 목표지향적인 사람이며, 주도적으로 일해야 하며, 홀로 잘 서려면 역설적이지만 다시 회사로 돌아가 함께 일하는 법을 배워야 한다는 걸 알아냈고요.
그때 핀테크사 뱅크샐러드에서 PM 자리를 권유했습니다. 저의 창업 이력을 보고 PM의 역량이 있음을 확신했다고 해요. 예상대로 저의 성향과 PM 일은 일맥상통했고, 갑작스럽지만 성공적인 PM 커리어를 밟을 수 있었습니다. 성공적으로 PM 커리어를 쌓을 수 있었던 방법, 과연 무엇이었을까요?
ⓒ 셔터스톡
디자이너 출신 PM이 모르는 3가지
01/ PM이 정확히 뭐하는 사람이지?
“소영 님은 뭐 하는 사람이에요?”
PM으로 첫 근무를 했을 당시 인턴 디자이너가 제게 물었습니다. 사회생활에서 이렇게 직설적인 질문을 받을 일은 드물지만, 내심 PM이 정확히 무슨 일을 하는지 모르는 사람이 많은 것 같아요. ‘기획은 기획자가 하고, 개발은 개발자가, 디자인은 디자이너가 하는데 PM은 무슨 일을 하지?’ 싶은 거죠. 더군다나 요즘은 UX(User eXperience)디자이너의 역할이 확대되면서 기획 직군과 교집합이 생기는 추세잖아요. 한때는 저도 솔직히 PM은 ‘폼 잡는 사람’이라고 생각했어요.
02/ 화면 밖 세상이 이렇게 넓었어?
PM의 역할을 한마디로 정의하면, 담당 프로덕트에 관련된 “모든 것”을 관리합니다. 디자이너일 땐, 화면 밖 세상이 이렇게 넓고 광활한 지 몰랐어요. 시각적으로 확인할 수 있는 화면은 빙산의 일각일 뿐이죠. 예를 들어볼게요. PM은 기술적으로 시스템 구조, 데이터 플로우 등을 고려합니다. 대체로 개발자들은 기존 시스템을 크게 바꾸는 것을 부담스러워하기 때문에 길고 복잡한 논의를 거칩니다. 서비스적으로 협업이 필요한 타 팀과도 의견 조율도 필요해요. 종종 수억 원의 리스크를 입을 수도 있는 어려운 의사결정을 내리기도 합니다. 심지어 PM은 프로덕트 이외의 영역까지도 관장해요. 프로덕트를 지배하는 법률 개정안 관련 정부 회의에 참여하거나 영업과 계약 체결을 진행시키기도 합니다.
03/ 논리적 생각 프로세스
PM은 한 번에 다양한 카테고리를 관리하기 때문에 체계가 중요합니다. 즉, 논리적인 생각 프로세스가 필요해요. PM의 머리 속은 트리(Tree)구조로 생겼습니다. 컴퓨터의 폴더를 생각하면 쉬워요. 누군가 프로덕트에 대한 이야기하면, 어떤 폴더에 넣어야 할지 생각합니다.
반면 디자인은 시각적인 창작 활동입니다. 그러므로 “이미지”적으로 생각하죠. 디자이너 시절, 프로덕트에 대한 설명을 들으면 어떻게 화면으로 구성할지를 생각했을 거예요. 정보량이 적을 땐 기억력에 의존할 수 있지만, 정보를 무분별하게 습득해 정보량이 많아졌을 땐 감당할 수가 없었어요. 점점 범벅이 되어 뭐가 뭔지 구분할 수 없었죠.
ⓒ 셔터스톡
디자이너 출신 PM이 아는 3가지
01/ 쉬운 전달력
모든 것엔 장∙단점이 공존하는 법이죠. 디자이너의 이미지적 생각 프로세스는 강점으로 발휘되기도 합니다. 이미지는 국가, 연령, 세대 등 모든 경계를 초월해 가장 이해하기 쉬운 언어입니다. 고로 PM이 이미지적인 생각을 할 수 있다는 것은 곧 프로덕트를 가장 이해하기 쉬운 형태로 번역할 수 있음을 의미합니다.
예를 들어, 다양한 관점이 존재하는 복잡한 프로덕트를 플로우 차트로 도식화할 수 있습니다. 의사결정이 필요한 순간엔 쟁점을 한눈에 비교할 수 있도록 도표를 만들겠죠. 프로덕트 요건을 설명할 땐 기획안을 장표로 구성할 것입니다. 화면 기획은 말할 것도 없고요. PM은 대부분의 시간을 무언가 설명하는 데 쓰는데, 이때 디자이너 출신만이 갖는 이미지 전달법은 서로의 시간을 혁신적으로 단축시킵니다.
02/ 하나를 보면 열을 안다
디자이너는 프로덕트의 가장 마지막을 담당합니다. 바로 프로덕트를 사용자에게 전달하는 “화면”이죠. 프로덕트는 결국 사용자의 선택을 받아야 하므로 디자인은 매우 중요한 작업 중 하나입니다. 디자이너 출신 PM은 프로덕트가 시작도 안 된 극 초반부터 완성본을 상상할 수 있습니다. 그들의 생각 프로세스는 기본적으로 이미지이기 때문입니다. 어렵고 복잡한 기술적, 법적 요건들을 들어도 필터를 거치면 완성까지 그려집니다.
03/ 사용성
프로덕트를 구성하는 세 가지의 요소가 있습니다. 비즈니스, 기술 그리고 사용성입니다. 비즈니스 입장에 선 PM은 현실적인 주장을 할 것입니다. 돈을 벌기 위한 서비스, 광고주 등의 이해관계자를 만족시키는 서비스를 주장하겠죠. 개발 입장에 선 PM은 보수적인 주장을 할 것입니다. 과거 레거시 코드를 크게 변경하지 않는 서비스, 일정 안에 개발 구현이 가능한 서비스를 주장합니다.
한편 디자이너는 100% 사용성의 입장에 선 사람들입니다. 사용자가 누구인지, 그들이 원하는 것과 불편해하는 것 그리고 필요한 것을 정확히 알고 있죠. 따라서 디자이너 출신 PM은 늘 사용자 입장에 서서 생각하고 의견을 개진합니다. 물론 어느 한 면이 정답이라고 할 순 없지만, 저는 감히 사용성을 최우선으로 두어야 한다고 생각합니다. 아무리 훌륭한 비즈니스 모델이나 고차원의 기술이라도 사용자에게 전달되지 않는다면 아무런 소용이 없기 때문입니다.
ⓒ 셔터스톡
PM이 되고 싶은 디자이너라면 미리 준비할 사항
01/ 논리적 사고
기획 단계에서는 상상도 하지 못할 만큼 방대한 정보를 접하게 됩니다. 이때 정보를 무분별하게 받아들인다면, 그 양이 많아졌을 땐 감당하지 못할 가능성이 큽니다. 따라서 정보를 트리 구조로 체계화해 이해하는 능력이 필요합니다. 먼저, 디자인의 최종 아웃풋이 구성된 과정을 체계적으로 정리해 보세요. 그리고 사용자 조사를 통해 얻은 인사이트(사용자의 연령, 성별, 국적, 행동 특성 등), 외부 상황(법적 요건, 시장 변화, 경쟁사 상황 등)등을 정리해 최종 아웃풋이 구성된 논리적인 까닭을 기록해 보세요.
02/ 문제 해결 능력
기획 초안이 작성되면 개발, 비즈니스, 디자인, 타 서비스 등 유관 부서와 리뷰 시간을 갖습니다. 이 과정에서 반드시 저마다의 입장 차이가 발생합니다. 아시다시피 사람마다 특성도, 표현 방식이나 화법도 전부 다르기 때문에 자칫하면 분쟁이 발생할 수 있어요. 프로덕트 진행은 늘 문제의 연속입니다. 이리 치이고, 저리 치여서 의견을 조율하거나 결정하거나 중에 하나죠.
문제 해결을 위해선 가장 첫 번째로 문제가 무엇인지 정확히 알아야 합니다.
그다음 해결안을 생각해, 가장 합리적인 안을 진행해야죠. 이때 의사소통 능력이 중요합니다. 디자이너는 디자인 쪽의 입장에 서서 강하게 주장할 수 있지만 PM은 어느 한 쪽에 설 수 없습니다. 당연한 이야기지만, 흥분하지 않고 이성적 태도로 임해야 합니다. 디자인 프로젝트 중 문제가 있었던 부분과 해결 방법을 짧게 정리해 보세요. 본인의 의견대로 문제가 해결됐다면 금상첨화입니다.
03/ 주도적 일 처리
PM과 디자이너의 가장 큰 차이점은 디자이너는 누군가로부터 업무를 지시받지만, PM은 누구에게도 지시받지 않는다는 점입니다. 상사의 지시나 컨펌 없이 주도적으로 일을 만들어 진행합니다. 반면 디자인은 정렬(Align)의 세계라, 서로 의논하고 컨펌하며 함께 일하는 문화죠. PM이 되기로 마음먹었다면 스스로 생각하고 결정 내리는 연습을 해보세요. 작은 프로젝트라도 먼저 발의해 진행한 경험이 있다면 가장 좋습니다.
