PM의 ‘진짜 성장’은 언제 올까?
성장하지 못하는 PM
② PM의 ‘진짜 성장’은 언제 올까?
이번 글에서는 PM이 성장하는 지점에 대해 정확하게 설명하기 위해 역설적으로 접근하려고 합니다. “우리가 어떤 상황에 놓여 있다면 성장 지점에 도달하지 못하는가, 왜 PM으로서 성장하지 못할 것이라고 생각하는가”에 대해 얘기해 보기로 합시다.
제품 개발 프로세스의 후반부: 제품의 산출, PM의 성장
이제 제품 개발 프로세스 후반부를 살펴봅시다. 후반부에서 벌어지는 일은 크게 보면 단순한, 스프린트의 반복이 대부분입니다. 스프린트를 설계하고, 데일리 스크럼을 하며, 스프린트를 진행합니다. 데모를 만들어 짧은 주기로 우리가 생산한 것들을 마주하고 또 다음 스프린트의 일감들을 설계해 나갑니다.
PM의 성장은 이렇게 전반부에 뿌려둔 씨앗으로 후반부에서 결실을 맺을 때, 그 수확과 함께 이루어집니다.
우리는 전반부에서 제품의 형상화를 문장으로 해냈습니다. 우리의 생각이 원형의 모습으로 상대방에게 전달되었다고 합시다. 이제 그 아이디어는 각각 다른 코덱(Codec)으로 풀이되는 것이 아닌 본모습 그대로 상대방의 전문성이라는 토양에 심어집니다. 그 원형이 씨앗일 수도 있고 묘목일 수도 있습니다. UX는 UX의 전문성으로, 개발은 개발의 전문성으로 물을 줄 테고 심어진 원형은 자라날 것입니다.
당연히 구성원의 전문성에 따라 그 모습은 제각각 다를 수도 있을 것입니다. 그래서 우리는 계속 스프린트와 데모를 운영함으로써, 그 원형이 어떻게 자라나고 있는지 확인하고 방향을 조금씩조금씩 맞춰나가게 됩니다.
마법이란 그것을 상상할 수 있어야 성립한다
생각해 보면 당연한 말입니다. 인간은 누구나 자신이 가지고 있는 도구, 자신이 가지고 있는 능력 안에서 상상할 수 있습니다. 제가 좋아하는, 엘프 마법사가 주인공인 애니메이션 ‘장송의 프리렌’ 세계관에는 “마법이란 그것을 상상할 수 있어야 성립한다”는 말이 있습니다.
하물며 마법도 그러한데, 기획자로서 가장 잘 다룰 수 있는 도구를 두고 피그마, 스케치 같은 도구를 사용한다면, 내가 상상하는 것을 제대로 표현해낼 수 있을까요? 표현하고 싶은 원형의 아이디어를 소프트웨어 다루는 미숙한 실력에 맞춰버리지는 않을까요? 더 나아가 내가 소프트웨어를 다룰 수 있는 만큼에서만 상상하고 마는 것은 아닐까요?
마치 웹툰이나 애니메이션으로 재미있게 보았던 원작을 실사 영화로 만들었을 때 실망하거나, 감동을 준 소설 원작을 드라마로 봤을 때 그만큼 감동이 느껴지지 않는 것도 비슷한 이치입니다. 실사화한 영화나 드라마는 최근 발전한 촬영 기법이나 장비, CG를 더해도 인간의 상상력을 모두 표현하기 모자랄 때가 있습니다. 인간의 상상력은 제약이 없는 데에 반해 현실에서는 제작비와 제작 기간이라던가, 기술의 부족이 있기도 합니다.
스타워즈 시리즈 3편 개봉 이후 조지 루카스 감독은 “내가 상상했던 세계를 스크린에 표현하기에는 현재의 기술력으로는 부족하다”며 그 후 16년을 기다렸고, 4번째인 ‘에피소드 Ⅰ’은 99년에야 개봉될 수 있었다. 그리고 2005년 스타워즈 시리즈의 마지막 편이 개봉됐고, 루카스 감독은 “더 이상 스타워즈 시리즈는 만들지 않겠다”고 선언했다.
- 마커스 헌, ‘조지 루카스의 시네마’, 비엘북스에서 발췌
저는 한때 다큐멘터리 제작을 배운 적이 있습니다. 영상을 찍기 위해 가장 먼저 배우는 것들 중 하나는 바로 편집입니다. 최근에는 영상 편집을 AI로 해주겠다는 스타트업들도 나오고 있습니다만, 편집은 소프트웨어를 이용하는 것에서부터 시작해 영상 제작에서 가장 전문적인 일들 중 하나로 꼽힙니다. 그만큼 어려운 일이지만 제작을 배우는 사람이라면 직접 잘 해내지 못하더라도 깊이 있게 배워 나가야 합니다. 편집에서 장면을 어떻게 잡아내고 처리할 수 있는지를 알고, 이를 위해 어떤 장비와 도구를 사용할 수 있는지 알아야, 비로소 그것들을 충분히 활용하는 방식으로 기획하고 촬영할 수 있기 때문입니다.
UX 디자인도 단순히 스케치나 피그마 같은 소프트웨어를 다루는 것을 훨씬 넘어서는 전문적인 일로 인정받고 있습니다. 개발 역시 단순히 코드를 써 내려간다는 차원을 넘어 여러 설계를 포함한 아주 전문적인 영역으로 인정받고 있습니다. 그들의 전문성에서는 PM이 몰라서 상상할 수 없는, 혹은 PM이 인지하지 못한 도구나 프레임워크로 훨씬 더 간명하고 효과적으로 구현할 수 있는 영역들이 존재할 것입니다. 그런데 왜 전문성이나 정보력은 가장 부족한 PM이, 그들의 영역에 해당하는 부분을 구체적으로(too concrete) 정의하며 결정해야 한다고 우리는 생각하게 된 것일까요?
실리콘밸리에는 기획자가 없다?
한때 이런 말이 유행한 적이 있습니다. 대략 2010년대 어디쯤으로 생각하는데, 그때는 제가 창업했던 회사가 ‘부도’나 강제로 회사가 접히던 시기였습니다. 저도 곧 어딘가 재취업을 해야 하는 인생의 가장 어려운 시점이었습니다. 마침 그때는 저 말이 유행하면서 저 같은 문과 출신들은 두드려볼 채용 공고도 잘 나오지 않는, 그야말로 문송한 시대였습니다.
당시에도 저는 그 말이 ‘틀렸다’라고 생각했습니다. 그러나 최근까지 비슷한 얘기가 들리기도 합니다. 아직도 ‘실리콘밸리에는 기획자가 없대’라던가, ‘기획자가 코딩을 할 줄 알아야 하는가’ 같은 논란이 여전히 존재하는 것 같습니다. “실리콘밸리에서는 디자이너가 오브젝트로 설계해 개발자가 코딩하면 제품이 바로 산출된다”라거나, “실리콘밸리의 PM이라면 간단한 코딩도 할 줄 알고, 개발 언어도 이해하며, 스케치에 다 직접 얹어내야 한다”고 슈퍼맨처럼 묘사하는 이야기들도 있습니다.
제가 아직 실리콘밸리에서 일해보지는 못해 그 말이 얼마나 참에 가까운지는 잘 모릅니다. 그래서 페이스북과 트위터에서 PM으로 일했고, 카오스 멍키(Chaos Monkey)라는 책을 쓴 안토니오 가르시아 마르티네즈(Antonio Garcia Martinez)의 얘기가 더욱 흥미롭습니다.
직함이야 어쨌건 간에, 대체 제품관리자란 무엇을 하는 존재일까?
MBA 풍으로 정의를 하자면 ‘제품의 CEO’라 할 수 있다. 많은 기업이 제품관리자를 그렇게 정의하며, 비록 실제 업무보다 더 거창해 보이긴 하지만 아예 틀린 말은 아니다.
하지만 보다 실질적인 정의는 ‘똥우산’에 가깝다.
성경에 등장하는 신이 내린 재앙처럼, 설사의 폭풍우가 몰아치는 모습을 상상해 보자. 스타트업에서 일하든 페이스북처럼 유명하고 복잡한 대기업에서 일하든 상황은 똑같다. 제품관리자는 똥의 폭풍 속에서 미친 듯이 키보드를 두들기고 있는 팀원들의 머리 위에 너무 커서 들기도 힘에 부치는 거대한 똥우산을 씌워주는, 엔지니어링팀의 머슴 같은 존재다.
정의에 따라, 제품관리자는 할 필요가 있는 모든 일을 한다. 직접 키보드로 코드를 타이핑하는 일만 제외된다.
사생활 보호 담당 법무팀과 무수한 미팅을 하고, 제품이 발휘할 수 있는 기능을 엄선하고 편집해서 보여주고, 케케묵은 법적 틀과는 어떻게 맞아떨어질지 설명해야 한다. 또한 웃고는 있지만 머리가 텅 빈 영업 직원들로 가득한 회의실에서 그들이 신제품을 사용할 고객을 유치할 수 있도록 제품에 대해 소개해야 한다. 또한 다른 제품관리자를 상대로 권모술수를 써서 그들이 개발 중인 제품을 변경하거나 엔지니어링에 배분된 자원을 조금 내주도록 구워삶아야 한다. 고위 경영진 등 고위급과의 미팅에 참석해서 제품을 홍보하고, 빠른 속도로 떨어지는 테트리스 조각을 맞추듯 제품을 홍보하고 제품을 그들 세상의 청사진에 끼워 넣어야 한다. 다른 제품관리자가 다가와 우리 팀원을 약탈해가려 들거나, 우리 제품 계획안에서 그들의 제품과 비교되는 몇몇 요소를 문제 삼고 우선순위에서 밀어내려 할 때는 목소리를 높여 팀을 방어해야 한다.
뛰어는 제품관리자는 내가 구성한 제품을 만들어내도록 엔지니어를 설득할 수 있어야 한다. 하지만 그렇게 하지 못한다면 자신의 군대에 대한 통제력을 잃어버린 독재자 꼴이 된다. UN이나 종교단체가 내 편을 드는가는 중요치 않다. 곧 미친 듯이 총을 쏴대는 사람들 앞에 서게 될 테니까. 페이스북 광고부에서 가장 애잔한 사람은 엔지니어의 신뢰를 잃은 제품관리자였다. 자신의 지위가 주는 허세를 누리며 이메일과 로드맵을 사방에 보내도, 아무런 결과물도 내지 못했던 것이다.
- 안토니오 가르시아 마르티네즈, 카오스 멍키, 비즈 페이퍼에서 발췌, 티스토리 참고
우리는 글로 개발하는 사람들
저는 PM은 글로 제품을 개발하는 사람이라고 정의합니다. 기획자*여도 마찬가지라고 생각합니다. 물론 어떤 PM은 슈퍼 코더일 수도 있고, 슈퍼 디자이너일 수도 있어, 꼭 글이 아니라 그들의 전문성으로 제품을 개발할 수 있을 것입니다. 그러나 일반론으로 말하자면 ‘글’로 개발하는 사람이라고 생각합니다.
*PM이 기획자인가에 대해서는 다른 글에서 다룬 적이 있습니다. 궁금한 분은 그 글을 참고해 보셔도 좋겠습니다.
PM은 어쨌건 대부분의 경우 UX디자이너보다 와이어프레임을 못 그립니다. 관련 소프트웨어를 사용하는 것도 훨씬 미숙합니다. PPT는 와이어프레임을 잘 그리기 위해 만들어진 도구가 아니기도 하고요. 무엇보다 와이어프레임이라는 한계 안에서 상상하고 무언가를 표현해 내는데 아주 취약한 사람들이기도 합니다.
동시에 대부분 개발자보다 소프트웨어 구조에 대한 전문성이 떨어집니다. 어떤 새로운 프레임워크가 있는지도 잘 모르고, 어떻게 데이터를 저장하는 게 효율적인지도 잘 모릅니다.
PM의 전문성은 그런 데에 있지 않습니다. 그들은 제품을 산출하는 데 필요로 하는 그 모든 것을 감당하는 잡부이기도 하고 머슴이기도 합니다. 무엇보다 제품개발팀의 구성원들 모두가 같은 방향과 목적으로 나아가게 하기 위한 일을 해야 합니다. 그래서 우리가 가진 전문성은 대략 고객 발견이나 고객 인터뷰, 고객이나 시장의 세그멘테이션과 형상화, 그리고 특히 고객과 시장의 필요를 충족시킬 수 있는 제품의 요구사항을 결정하는 것에 있습니다.
그것들을 형상화해 전달(Visualization Sync)할 때, 저는 ‘글’보다 더 강력하고 한계 없는 도구를 보지 못했습니다. 그래서 PM은 글, 문장, 문서처럼 우리에게 자유로운 도구를 이용해 제품을 개발하고 산출해야 합니다. 그렇게 생각의 원형을 정확하게 다른 제품개발팀 구성원들에게 전달하고, 그들과 함께 제품을 산출할 수 있어야 합니다.
(페이팔의 창업자, 피터 틸(Peter Thiel)이 세운 비밀스러운 방위 첩보 소프트웨어 기업 팰런티어에서는 PM을 ‘제품항해사’라 부른다고 합니다. 낭만적인 느낌을 담은, 꽤 적절한 이름 같습니다.)
스프린트와 데모: PM이 성장하는, 지금 이 순간
그렇게 PM이 전달한 생각의 원형은 PM뿐만 아니라 개발자와 디자이너 등의 전문성을 바탕으로 그 덩치를 키워나갈 것입니다. 저는 PM이 직접 그린 화면정의서 대신 생각의 원형을 전달하고, 디자이너가 그것에서부터 사용자 여정(User Journey)을 산출하고 그에 맞는 와이어프레임을 제작해야 한다고도 생각합니다. 그 와이어프레임은 PM보다 전문성이 있는 구성원의 산출물이기에, PM이 직접 그렸을 그것들보다 훨씬 좋은 결과물일 가능성이 높다고 생각합니다. 특히, 어떤 디테일이나 특정 유저 스테이지에서는 그럴 가능성이 훨씬 높을 것입니다.
그리고 그런 “더 좋은 결과물”을 우리는 스프린트의 중간, 데모를 함께 하면서 발견해 나갈 것입니다. 사실 전혀 생각하지 못했지만, 아주 멋진 해답이나 결과물을 마주했을 때, 우리 반응은 크게 두 가지 중 하나가 될 것입니다.
“내가 몰랐던 멋진 것을 발견했어!” 또는 “내가 생각한 바로 그거야!”라고요.
두 상황 모두 PM에게는 성장의 지점이겠지만, 두 번째 상황이 저는 더 극적으로 성장하는 지점이라고 생각합니다. 정말 잘 쓴 문서는 ‘잘 썼네’가 아니라 ‘내 말이 바로 그 말이야’로 귀결됩니다. 이처럼 정말 멋진 결과물은 스스로를 속여낼 만큼 자연스럽고, 그렇게 내게로 흡수되어 버립니다.
오해는 없었으면 합니다. 타인의 성과를 가로채라고 독려하는 것이 아닙니다. 사실 우리들 PM이 생각의 원형을 공유하긴 해도, 그것이 자라났을 모습은 상상 속에서만 존재합니다. 그 상상을 타인의 전문성으로 만나게 되었을 때, 마치 원래 내 것이었던 것처럼 스스로조차 속이며 착각하게 된다는 의미입니다.
그렇게 “멋진 것”을 내재화하고 흡수하는 그 순간이, 바로 PM이 성장하는 순간입니다. 그렇게 성장한 “PM-나”는 다음 스프린트, 다음 PRD, 다음 제품을 접할 때, 이번에 흡수한 그 수준을 바탕으로 또 다른 전문성의 결과를 만나러 갈 테니까요.
마치며: 숙련과 성장의 사이
다시 한번 언급하자면, 화면정의서를 작성하고 리뷰하는 것이 무의미하다는 이야기는 아닙니다. 그 일은 그 일대로 회사에 기여하는 바가 있고, 또 ‘나’는 그것을 점점 더 잘하는 숙련 노동자가 되어 갑니다. 때로는 회사의 기존 제품 문화가 그러하기 때문에 화면정의서가 없이는 아무것도 못 하는 상황에 마주할 수도 있습니다. 화면정의서를 작성하는 행위는 아무런 문제가 없다는 것을 다시 상기해 봅니다.
그저 어떠한 것에 숙련되어 가는 것과 성장하는 것이 다르다는 얘기를 하고자 합니다. 언제 어디서나 그렇겠지만, 개인도 숙련되는 것만으로는 만족할 수 없고 조직도 숙련되는 것만으로는 충분히 행복할 수 없습니다. 단순한 숙련과는 다른 차원에서 성장의 기회는 필수적이어야 합니다. 조직에는 개인의 성장이 옵션이나 선택 관광 같은 요소여서는 안 됩니다.
제가 제시하는 방법이 성장의 모든 것은 아니겠지만, PM인 우리가 성장의 지점을 만날 가능성을 높여줄 것이라고 기대합니다. ‘비효율의 숙달(또는 the Busy Trap, Stop to go faster 등)’이라는 제목을 가진 그림으로 이번 글을 마무리합니다.
제품 개발 과정(Agile Product Development Process, APDP)에 대해, 특히 PRD에 대해 궁금한 분들을 위해 커피챗 신청 창구를 만들었습니다. 링크를 참고해 주세요.
성장하지 못하는 PM
② PM의 ‘진짜 성장’은 언제 올까?
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
