현재 <개발자>인데 "프로덕트매니저"가 되고 싶다구요?
먼저 개발자인 당신에 대해서 얼마나 잘 알고 계신가요?
지난 글 <프로덕트 매니저>의 '생각의 틀'과 '방법의 툴' 을 읽어 주신 많은 분들이 비슷한 종류의 질문을 많이 주셨습니다. 약간의 개인차가 있지만 그 질문들을 일반화하면 다음과 같습니다.
"지금 현재 개발자/프로젝트매니저/SI엔지니어 인데, '프로덕트매니저'라는 역할에 관심과 흥미가 생긴다. 그런데 어디서 어떻게 시작을 하면 좋을지 잘 모르겠다"
사실 현재 본인의 일을 바쁘게 해 나가면서, 다른 업무에 흥미와 관심을 두기가 쉽지 않은데, 무엇보다 그런 질문을 해 주신 분들의 열정에 박수를 보내 드리는것으로 글을 시작합니다.
질문하신 분 들중에는 개발자도 계시고, 프로젝트매니저도 계시고 또 다른 여러분야에 걸쳐 계시기에, 한번에 맞는 글을 쓰기 보다는 몇개로 나누어 각 부문에 계신분들과 함께 공감하고 이해되는 글을 써보려 합니다.
오늘은 그 첫번째로 현재 하고 있는 일이 소프트웨어/서비스 개발자 Developer, Architect, Software Engineer 이면서 '프로덕트 매니저'에 관심도 있고 업무 전환도 고려해 보고 계신 분들을 대상으로 어떤 부분의 준비와 검토가 필요한가에 대해서 이야기 해 볼까 합니다. 다음 글에서는 프로젝트매니지먼트를 행하고 계신 분들을 위한 글을 준비중입니다.
(지금부터 글에서의 PM은 '프로덕트 매니저'를 통칭하고자 합니다.)
0. 시작은 모두 별 차이없어요.
2019년 작년에 발표한 재미있는 조사결과가 있습니다. 현재 여러 글로벌 소프트웨어/서비스기업의 '프로덕트매니저' 들에게 PM일을 하기 전 업무는 무엇이었느냐는 질문에 아래와 같은 결과표가 나왔습니다.
프로덕트매니저 업무를 하기전에 했던 직무 도표에서 나타난 바와 같이 현업의 PM들이 업무 전환을 하기전에 했던 상위 3개의 직무는 '프로젝트매니저, 비즈니스 분석가, 개발자' 입니다. 비즈니스분석가를 비즈니스 도메인 업무를 알아야 하는 'SI 엔지니어'로 확대해석해 보면, 저에게 질문을 주신 분들의 현재업무와 동일 합니다. 즉 이 통계조사결과는 최소한 "여러분이 지금 하고 있는 일들은 모두 향후 잠재적인 프로덕트매니저로 업무전환을 할 수 있는 토양을 충분히 제공하고 있다" 라는 아주 긍정적인 면을 보여줍니다. 또한 PM이라는 직종이 대학을 졸업하고 바로 그 직종으로 입사를 하기 보다는 다른 역할을 하는 도중에 직무전환이 경우가 많구나 하는 부분도 어렵지 않게 알아채셨으리라 생각합니다. 또한 상위 3개의 직무가 차지하는 비율은 36 % 정도 일뿐입니다. 즉 그외에 수많은 백그라운드를 가진 분들이 현재의 PM으로 역할을 수행하신 사실에도 동기부여가 되기를 바랍니다.
위 도표를 포함한 전체 자료는 이곳에서 가져오세요. 매우 유익합니다!!
위의 도표의 상황을 저는 제 방식으로 이렇게 표현합니다. 저렇게 수많은 다른 백그라운드를 가진 분들이 현재 PM이라고 해도,
PM은 되고 싶고, 관심이 있다고 되는게 아니라 <프로덕트 매니지먼트팀>이 그 역할에 맞는다고 생각하는 사람을 PM으로 찾아 그 일을 맡기는것 입니다.
위에 문장의 제 표현에서 실망이나 좌절을 느끼라고 드리는 말씀은 절대로 아닙니다. 프로덕트 매니지먼트라는 일은 대학졸업 후나 입사초기에 PM교육을 통해서 배운 지식으로 실행되기 보단, 여러 각 분야 (개발, 디자인, 프로덕트마케팅, 고객지원, 혹은 과학이나 예술의 학문적 성과)에서 경험을 갖고 있는 전문도메인을 가진 사람들에 의해 더욱 잘 수행해 낼 수 있는 일이라, 그만큼 다양성과 전문성이 요구되는 일이라는것을 말하고 싶었을 뿐입니다.
물론 요즈음엔 PM에 대한 수요가 있다보니, 구글이나 페이스북에서 대학생이나 신입레벨을 위한 자체교육프로그램을 수행하기도 하고, 카네기멜론의 석사코스나 스탠포드의 특별과정으로 배울수 있는 기회가 있습니다. 구글이나 페이스북의 과정은 한국의 대학생들이나 입사예정자 분들도 관심을 많이 가지시고 도전했으면 합니다.
(제가 한국에서는 어떤 코스가 준비되어 있는지에 대한 조사는 하지 못했습니다.)
Google Associate Product Manager Program
Facebook Rotational Product Manager Program
지난 글에서, 저는 한 기업의 개발매니저일때 '사내 직무전환 internal transition/hiring' 을 통해 프로덕트/프로그램 매니저가 된 경우라고 말씀드렸습니다. 그런데, 저는 처음부터 무조건 PM이 되고싶다라는 생각을 가진 사람이 아니었기에 어떻게/왜 PM이 되었는가에 대해 명확한 설명을 드리는것이 쉽지 않습니다. 그만큼 애매모호한 면이 있기 때문입니다. 그래서 밑의 이야기로 답을 대신합니다.
제가 PM이 되고 나서 (물론 여러단계의 PM 인터뷰와 프레젠테이션을 거쳤습니다.) 그 당시 제 상사에게 왜 저보고 지원하라고 하였고, 선택했는지를 물어본 경험이 있습니다. 상사분의 대답은 "당신이 개발매니저때 보여준 여러가지 역량때문인데, 기능사양서를 쓰면서 시장과 고객의 스토리를 가져다쓰는것, 데이터에 기반하여 우선순위 결정프로세스를 보여준 점, 단독적 기능을 여러제품에 채택하도록 여러 개발팀을 설득했던 점을 예로 들면서 그런 역량은 PM으로 더욱 잘 맞을 듯 해서 지원을 권유했던 것이다" 라는 대답을 들었습니다.
모든 과정에는 전략이란 것이 필요한데 여러분이 가진 PM에 대한 관심이 진짜 다음 경력을 위해서 준비해야 하는것인지 아니면 다른 일에 대한 호기심인지를 알기 위해서는 먼저 여러분을 스스로 평가 self-assessment해보는것이 첫번째 순서일것입니다. 그러나 지금 여러분이 가진 PM에 대한 관심의 밑바닥에,
현재하고 있는 개발, 컨설팅이 싫어서
프로그래밍이 재미없고 재능도 없는것 같아서
개발자로서 고객을 만나는 일이 너무 귀찮아서
개발자 보다는 급여와 보상이 PM이 더 좋을것 같아서
뭔가 더 폼이 나는것 같아서
와 같은 현재의 상태를 네거티브 동력으로 사용하시려는 분은 능력있고, 성공적이고, 무엇보다 가장 중요한 자신의 일에 즐거움과 열정을 쏟으면서 세상을 향한 임팩트를 만드는 훌륭한 프로덕트 매니저는 될수 없다는 점을 명심하시기 바라며 첫 글을 시작합니다.
1. 개발자인 당신은 이미 5가지 강점을 갖고 있습니다.
디벨로퍼, 소프트웨어엔지니어뿐만이 아니라 요즘은 UX, DevOps까지도 개발능력이 필요하므로, 광역의 의미로 개발자의 범위에 두고 이야기를 하려 합니다. 개발자들이 모두 같지는 않으나 일반적인 개발자는 다음과 같은 다른 직군들과는 비교불가능한 다음과 같은 개발자만이 보유한 뚜렷한 5가지 장점/강점을 갖고 있습니다.
A. 태스크 주도형 Task Driven
개발자이 일하는 전형적인 방법은 어떤 프로젝트나 구현해야 할 기능을 목표나 목적으로 할때 그것을 주로 수직적 기능별로 쪼개고, 그 쪼개어진 것을 태스크로 지정하고 그 태스크를 담당자에게 할당, 태스크의 진행을 모니터하면서, 완료된 태스크들의 수직적 조합을 수평적으로 이어서 프로세스로 만들어 딜리버리를 하는것에 매우 익숙합니다.
이 역량은 PM에게도 매우 절대적입니다. 제품/서비스에 쏟아지는 요구사항(시장, 고객, 경쟁 제품/서비스)들을 테마에 따른 가중치를 가진 우선순위로 나누고, 그것에 최적의 리소스를 할당, 목표품질과 타겟 딜리버리 시기를 정하는것은 PM의 가장 코어 역량입니다.
B. 시스템간 인터랙션에 익숙 Confident with system interactions
개발자의 탁월한 장점입니다. 자신의 태스크나 완성된 기능은 단독으로 동작하기 보다는 기대하는 입력에 따른 처리를 행하고, 내 모듈이 제공해야 하는 출력을 만들어 내 보내는 일이다 보니, 당연히 다른 시스템과의 연계는 일상이 됩니다. 1:1 대응뿐만이 아닌 n:1, 1:n, n:n의 대응이 모두 가능한 모델을 설계하고 구현하는 것이 개발의 기본 구조입니다.
개발자의 기술적인 면에서 다중시스템 성숙도는, PM의 입장에서 보면 다중 관계자들 stakeholders간의 인터랙션, 커뮤니케이션 역량으로 변환 해석될 수 있고, 제품/서비스의 품질에 직접 연결되어 있습니다. PM본인이 품질에 관여할 수 있는 부분은 각 부분 pillar를 책임지는 설계자architects, 개발매니저, 디자이너, 스크럼매스터간의 유기적으로도 원할하고 명확한 수평적 인터랙션을 책임지는것이고, 이것 뿐이 아닌 수직적 인터랙션인 프로덕트리더십과의 커뮤니케이션, 고객이나 파트너와의 관계성 모두 확보해야 하는 일입니다.
C.해결 주도형 Problems to Solutions
문제를 접할때 머리속에 그것에 대한 해답을 고민하지 않는 개발자는 본 적이 없습니다. 개발자라면 그 문제가 해결될때까지, 솔루션을 찾을때까지 밥을 먹을때도, 커피를 마실때도, 출근을 하는 버스안에서도 머리속에서 떠나지 않는게 일반적인 현상입니다. '어떻게든 되겠지'가 아닌, '어떻게 해서든 해결해야지'라는 기본적인 덕목은 PM에게 있어서 어떤 상황에서도 이 서비스/기능은 꼭 딜리버리를 해야 한다는 에너지로 동작할것 이고, 그 에너지를 경험하는 모든 관계자들 stakeholders은 그것을 리더십으로 해석할 것입니다.
D. 디테일에 강하다. Attention to Detail
개발자의 눈은 보통 사용자가 보지 않는 부분을 늘 보고 있습니다. 사용자는 별로 거슬리지 않는 부분조차 늘 맘에 쓰여서 해결하기 전까지는 맘이 편하지 못합니다. '뭘 그런것까지' 라고 말하는 비개발자들의 말이 제일 이해가 안되기도 합니다. '디테일에 강하다'라는 무기는 품질을 베스트로 만들 수 있는 역량입니다. PM의 역할은 각각의 전문가 들이 놓치는 부분의 디테일을 알아야 합니다. 즉 오케스트라의 지휘자라고 생각하시면 됩니다. 각각 악기를 연주하는 최고의 예술가들이 모였을때의 소리의 강약과 잡음을 잡아 하모니를 만들어 내는 지휘자가 필요합니다.
E. 평생 배우고 익히기 life-time learner
개발자라는 직업은 평생 배우고 익히기를 게을리 할 수 없는 특성을 갖고 있습니다. 매일 아침 눈뜨면 새로운 변화의 기술이 등장해 있고, 그 신기술이 어떤 경우에는 마이너버전급의 작은 업그레이드 일 때도 있으나, 어는 경우엔 외계에선 온것 같은 새로운 패러다임이 도착해 있기도 하죠. 빠르게 익히고 사용해 보아야 세상의 변화에 늦춰지지 않을뿐만 아니라, 다음 새로운 파도를 올라탈 수가 있습니다. PM도 같은 경우입니다. 개발자처럼 도메인기술을 지속적으로 깊이 알아나가기 보다는 기술과 시장의 흐름, 디자인의 변화, 경쟁제품/서비스의 움직임, 그리고 고객 비즈니스의 상황까지 모두 알고 대처해야 합니다. 데이터는 정보가 되고, 정보가 지식이 되며, 지식이 지혜가 되려면 data to information, information to knowledge, knowledge to WISDOM, 배우고 익히는 일이 생활이 되고 몸애 베어야 하는데, 좋은 개발자라면 이미 그 덕목을 이미 충분히 갖고 있다고 할 수 있습니다.
2. 현재의 강점에 PM의 덕목 5가지를 추가하세요.
위에 열거한 개발자의 강점 5가지는 출발의 좋은 베이스지만 마무리까지는 아직 충분하지 않습니다. 이제 설명드릴 것들이 도움이 될것입니다.
A. 사용자, 고객, 그들의 비지니스를 이해
Understanding customers and their business
매번, 수없이 반복해도 모자람이 없는 말입니다. 대부분의 개발자는 그들의 손가락을 움직여 만드는 제품/서비스가 어떻게 사용되는지, 고객의 비즈니스를 돕고 있는지에 대해서 잘 모릅니다. 그리고 어느순간이 되면 별로 알고 싶어 하지도 않고, 그냥 PM이나 기획자가 원하는 대로 만들어 주는데 익숙해 집니다. PM이 된다는 것은 순간순간 고객의 입장이 되지 않으면 그들이 원하는 제품/서비스를 만들지 못하고 결국 그 시장에서 선택되어 지지 않는 다는 사실을 깨달아야 합니다. 더 나아가면 시장에서 선택받지 못하는 제품/서비스는 지속 가능한 동력이 없어집니다. 고객의 비즈니스가 내 제품/서비스의 매뉴얼이 되어야 합니다.
영어 표현에 'Eating your own dog food'이 있습니다. 고객의 비즈니스를 이해했다고 해도, 마지막에는 자신이 만든 제품/서비스는 본인이 직접 써보고 테스트해야 고객과 공감의 폭을 넓혀가며 이야기 할 수 있습니다. 나는 개발자이니까 테스트는 내가 하는 일이 아니야로는 고객을 이해할 수도, 시장을 알아갈 수도 없습니다.
B. 제품을 함께 만들 관계자들과 비전을 공유
Share the product vision with the stakeholders
많은 개발자, 기술자들의 특성중의 하나가 '내성적인 shy' 성향이 있다는 것입니다. 개발자들끼리 있으면 아무리 수다스러운 성격이라 해도, 여러 다른 역할을 수행하고 있는 사람들이 모여 있는 곳에서는 말 수가 줄어듭니다. 어쩌면 이런 개발자의 내성적인 성향이 집중도와 완성도를 높이는데 기여하는 부분일 수 있습니다. 그러나 PM은 혼자서 할 수 있는것은 거의 없습니다. PM은 철저하게 각 부문 전문가들의 브릿지가 되야 하고, 그들을 통합해야 하고, 그들에게 이 제품/서비스의 비전을 꾸준히 불어넣어야 하는 역할입니다. 매번 개발자의 전문 지식이 필요한 엔지니어링, UX, 데이터처리뿐만 아니라, 디자인, 서비스운영, 프로덕트 마케팅등 수많은 담당자와 함께 하모니를 만들어내는 오케스트라의 지휘자입니다. 그것뿐이 아닌 적절한 외교력과, 협상력, 커뮤니케이션 같은 소프트 스킬도 필요합니다. 더 이상 샤이shy 해지지 마십시오.
C. 유용성에 대한 끊임없는 탐구
Never surrender to the usability
고객의 의견과 요구사항, 마켓리서치를 통한 피드백을 참고하다보면, 제품/서비스에 대한 고객의 사용 플로우를 이해하고 알게 됩니다. 초기 PM의 실수중에는 이 참고된 사용플로우에만 매몰되어, 또 다른 고객의 사용플로우에는 적용이 안되는 제품 결함을 만들게 되는 경우가 있습니다. 개발자 였다면 신경을 쓰지 않아도 되는 부분입니다. 그냥 정해진 대로, 디자인대로 개발에 집중하면 되지만, 이제는 이 워크플로우가 정말 사용가능한것인지를 매번 검토해야 합니다. 되는것이 중요한것이 아니라 유용하게 사용되는 것이 중요한 것입니다.
여기에서 생각해야 하는 부분이 '속력 speed 와 속도 velocity를 구분' 하는 지혜가 필요합니다.
글을 읽으시는 분들 모두 다 잘 아시다시피 속력 speed은 스칼라량으로 빠르기만을 측정하는 단위라면, 속도 velocity는 이동한 거리를 측정하는 방향성을 가진 벡터량입니다. Jira와 같은 agile툴이나 스크럼툴을 써보신 분들이라면 스토리포인트나 릴리즈 번다운 차트 burndown chart가 속력speed 가아닌 속도 velocity를 측정하기 위한 하나의 메트릭이라는 사실을 많이 듣고 알고 계실겁니다.
Burndown chart원하는 속도 velocity를 위해서는 올바른 우선순위 prioritization 가 절대적으로 선행되어야 합니다. 개발자시절에 내가 잘하는 것은 빨리, 잘못하는것이나 하기 귀찮은것들은 시간이 좀 더 걸리는 식의 우선순위가 아니라, 모든 고객과 시장이 요구하고 필요한 우선순위를 정하면 그곳에 방향성도 함께 부여하는것입니다. 소수의 고객이 아닌 모든 고객의 유용성usability를 확보하는것이 중요합니다.
최근에 다시 보게된 영화 '공공의 적 Public Enermies'에서 조니뎁이 '방향성'에 대한 중요한 대사를 하는데, 이거다 싶어서 바로 캡쳐를 해 보았습니다. (제가 가진 직업병 증상중의 하나가 아닐까도 생각해 봅니다.)
D. 생활밀착형 사고가 아닌 전략적 사고 Think strategically not operationally
지난글들에게도 전략적 strategic이란 말을 꽤 많이 사용해왔습니다. 물론 손에 잡히지 않는 추상적인 의미가 강한 말이기에 이게 어쩌라는 말이냐 라는 생각을 많이 하실겁니다. 물론 저 역시 같은 생각이었습니다.
전략적사고 라는 말을 설명하기 위해 먼저 생활밀착형 사고 operational thinking을 설명드리는게 이해에 도움이 될것 같습니다. 개발자가 업무 할당을 받으면, 개발자는 그 부분을 어떻게 구현할것인가에 집중을 합니다. 이렇게 할까, 아니면 또 다른 알고리듬으로 또 다른 테크놀로지로 해결을 할까 합니다. 그런 구현을 할때 그냥 그 일에 그 업무에 집중을 할뿐입니다. 그 상황에, 이 제품/서비스에 대한 슬로건은 무엇이 되어야 하는지, 어떤 UX 플로우에 인티그레이션이 되는지, 경쟁제품/서비스에서는 어떻게 제공되고 있는지를 별로 신경을 안씁니다. 개발자로서 나의 일이 아니니까요.
Photo by Ivan Aleksic on UnsplashPM은 360도로 생각과 귀를 열어둬야 합니다. 열려있을 뿐만 아니라 유연하고 차선책이 준비되어야 합니다. 전문가, 담당자에게 항상 귀를 열고 의견과 지혜를 들어야 하는것은 기본중의 기본이지요.
좀 더 현실적인 팁을 설명드려봅니다. 위의 예의 개발자의 사고방식이 원인/요구-결과/해결 같은 1차 사고 first order thinking이라면 PM은 "이렇게 되고 나면 그 다음은 또 어떤 상황이 올까" 와 같은 2차, 3차 사고 second, third order thinking같은 순차적 사고 방법이 조금 더 전략적 사고가 될 수 있습니다. 이 순차적 검증 사고 방식을 연습하는 방법으로는 워렌버핏이 중요한 결정때 사용한다는 10-10-10 룰이라는 것이 있습니다. 지금 내리는 결정에 대해서, 10분후, 10개월 후, 10년 후에는 어떤 의미가, 어떤 느낌이 들 것인지를 스스로에게 질문을 해 보는 방법입니다.
또 다른 한가지 중요한 팁을 설명드리겠습니다. PM은 본인이 지금 하는 결정이 나중에 어렵지 않게 바꿀 수 있는 가역적 reversible 결정인지, 바꾸기 힘든 비가역적 irreversible 결정인지를 명확히 알고 판단해야 합니다. 가역적 결정이라면 나중에 신속하게 조정이 가능하기 때문에 정보가 조금 부족한 상황에서라도 시간끌 필요없이 빠르게 진행해야 합니다. 그와 반대의 경우인 비가역적 결정이 Irreversible decisions 필요한 순간에는 결정에 도달하기까지 충분한 정보를 확보해야 하고, 신중해야 합니다. 주위 전문가들과 리뷰가 필요하다면 시간을 충분히 할애해야 합니다. 밑의 그림 설명을 보시면 이해에 도움이 되실 겁니다. 가역적 결정인 경우 그 상황이 여파를 만드는 상황이라면 테스트, 실험 experiment를 하고, 아니면 바로 행동을 해도 됩니다. 돌이키기 힘든 비가역적 결정이고 여파가 따른다면 충분히 시간을 갖고 결정을 신중하게 하지만, 여파를 거의 없다면 전문가에게 위임을 해도 됩니다. 하지만 가장 중요한 사실은 내가 지금 내리고 있는 결정이 어떤 종류의 결정인지를 아는것이 가장 중요하겠죠.
Reversible vs Irreversible - Consequential vs InconsequentialE. 업무 우선순위 workload prioritization
지난번 글에서도 언급했던 "비타민이냐 진통제이냐"가 모든 우선 순위의 첫번째를 차지합니다. 그 진통제 역시 고객을 위한것인가 우리조직을 위해서 인가를 검토하는것 역시 중요합니다. 개발자들의 일반적 특성은 안정적 stable이고 검증된 certified 솔루션을 사용하는것 보다는 최신 기술에 화려함을 사용하기를 원합니다. 그것이 내가 이 기술사회에서 뒤쳐지지 않고 있다는 중요한 심리적 효과를 줍니다. 엔지니어로서 중요한 부분이고, 발전의 동력이 맞습니다. 그러나 PM의 결정은 조금 더 보수적이어야 합니다. 업무의 우선순위를 정할때 위험도 risks를 얼마나 잘 관리할 수 있는냐를 최우선에 두어야 합니다. 그 최신기술을 사용할 환경을 고객이 보유하고 있는지, 그 화려함이 제품/서비스의 퍼포먼스에 얼마나 영향을 미치는것인지, 이 최신기술의 도입을 위해서 어떤 포스트프로세스(서비스스택/디플로이먼트)를 준비해야 하는지 등등입니다. 개발자가 지닌 지적 호기심과 창의력은 제품/서비스를 혁신적으로 발전시키는데 중요하지만, 그 발전이 얼마나 안정적이고 시장이, 고객이 인정하고 실제 사용하는지에 대해서는 신중한 판단이 필요합니다.
3. 글 마무리
개발자라는 직업은 축복받은 역할을 수행하는 자랑스러운 직업임에 분명합니다. 누구보다도 실 변화를 직접 만드는 숭고한 일입니다. 그런 분들이 PM에 관심을 갖고 커리어전환을 고려하는것 또한 엄청난 에너지 포텐셜을 보여 줄 일입니다. 그러기 위해선 누가 무엇을 하란대로, 이렇게 하니까 되더라의 방법보다는 무엇이 필요한지, 어떻게 준비하여야 하는지를 객관적으로 아는것이 중요하다는 생각하여 이번 글을 준비하게 되었습니다.
물론 여기서 끝이 아닙니다. 관심이 있다면 여기저기에 수없이 널려있는 데이터, 정보, 지식들을 지혜로 만드는 일들을 부지런히 하셔야 합니다.
최근에 보게 된 흥미가 가는 10분짜리 영상을 공유하는것으로 이번 글을 마무리 합니다.
How users understand new products – Michelle Fitzpatrick
여러분들의 도전에 늘 힘찬 박수로 응원드립니다.
