기술에 대해 "충분히 아는" PM 이 되는 길
제품 관리자(Product Manager, 이하 PM)는 기술에 대해 어느 정도 알아야 하는가? 에 대한 질문은 항상 비 기술 분야 배경을 가진 PM 들에게 숙제 같은 질문이었습니다. 얼마 전 이러한 질문에 대한 좋은 참고가 될 수 있는 글을 만나 저자의 허락 하에 번역, 공유드립니다. Pinterest 의 PM 을 맡고 있는 Lulu Cheng 이 쓴, 기술에 대해 "충분히 아는" PM 이 되는 길(Getting to “technical enough” as a product manager) 입니다.
당신은 기술에 대해 잘 알지도 못하면서 왜 검색 파트의 PM 인가요?
위 질문은 실리콘 벨리에 있다 보면 자주 맞닥뜨리는 무심한 질문입니다. 만난 지 5분밖에 되지 않는 사람에게 던질 법한 질문은 아니지만, 합리적인 질문이라고 생각됩니다.
전통적으로 제품 관리자(Product Manager, 이하 PM)에게 요구되는 조건 "컴퓨터 과학이나 관련된 분야에의 학사 학위, 혹은 이에 준할만한 실제적 경험" 입니다. 후자는 보통 "제가 만든 거에요." 라고 말한 만한 사이드 프로젝트가 있을 때를 의미하죠. 몇몇의 예외는 있지만, 기술에 대한 이해가 깊은 것(Being technical)은 "있으면 좋은 것" 이라기보단 "무조건 있어야 하는 것" 입니다.
최근 기업들은 이러한 요구 조건을 "PM 은 기술에 대해 충분히 알아야 한다." 로 다시 쓰고 있습니다. 요구 조건에 적힌 단어의 선택에 집중해 다음을 읽어 보세요. (링크를 클릭하시면 각 기업을 확인해보실 수 있습니다.*)
엔지니어들에게 아키텍쳐나 제품에 관한 결정 등에 대해 좋은 질문을 던질 수 있을 정도로 기술에 대해 알고 있어야 합니다.
기술적인 수준에서 대화를 나누는 것을 포함해 훌륭한 커뮤니케이션 능력을 가지고 있어야 합니다.
깊은 분석 능력. 컴퓨터 과학 학위나 프로그래밍 경험이 이상적이며 데이터와 특이 케이스, 분석에 대한 사랑이 있어야 합니다.
제가 조금 편향적이긴 하지만, 일반적으로 이러한 움직임은 좋은 방향이라고 생각합니다. 또한 PM 의 역할과 수요가 늘어날 수록 이런 움직임은 가속화될 것입니다. 제품 관리(Product Management)는 과학인 만큼 인문학이며, 통계학인 만큼 심리학입니다. 또 작은 디테일에 집중하는 만큼 큰 그림을 보는 것도 중요하죠. 여러분이 어떤 산업의 회사에 속해 있으며, 어떤 제품의 무슨 기능을 담당하고 있는지에 따라 요구되는 기술적인 수준과 일상 업무는 매우 달라집니다. 더불어, 존경 받는 PM 이 되기 위한 자질에는 기술적 전문성이 거의 포함되지 않습니다. ("그건 훌륭한 엔지니어를 낭비하는 방법입니다." 라고 누군가 말하기도 했죠.)
하지만 궁금증은 풀리지 않습니다. 기술에 대해 "충분히 안다." 는 것이 정확히 어떤 의미일까요? 어떻게 성취될 수 있을까요? 또한 그러는 와중 어떻게 팀 내에서 신뢰를 쌓을 수 있을까요?
제가 마케팅에서 PM 으로 직무 전환을 했을 때, 저는 이러한 궁금증을 풀어줄 만한 대답이 인터넷에 거의 없다는 사실에 놀랐습니다. 그래서 제가 Pinterest 검색 파트에서 겪은 첫 90일간의 PM 경험을 통해 나름대로 대답해 보려 합니다. 제 글이 비 기술 분야의 배경을 가진 PM 들에게 도움이 되었으면 하는 바이며, 이를 통해 더욱 더 많은 대화들이 오고갔으면 좋겠습니다.
글은 제가 좋은 PM 이 되기 위해 시도한 경험이 녹아든 두 가지 파트로 나뉘어 있습니다.
1. 기술에 대한 이해의 베이스라인을 구축하고, 시간이 지남에 따라 더 투자한다.
2. 어떻게 즉각적인 가치를 더할 수 있는 지 파악해 신뢰를 쌓는다.
기술에 대한 이해의 베이스라인을 구축하고, 시간이 지남에 따라 더 투자한다.
첫 번째로, PM 으로서 "충분히 기술적" 이 된다는 것은 어떤 의미일까요? 다양한 의견들이 있지만, 저는 다음과 같은 능력이라고 생각합니다.
1. 사용자 이슈를 따라가 잠재된 문제를 파악할 수 있다.
2. A 기능과 B 기능을 만들 때 어떤 것이 더 오래걸리는지 대략 추정할 수 있다.
3. 특정한 기획이나 제안을 적용할 때 있을만한 문제들을 예측할 수 있다.
4. 기술적인 문제들에 대한 잠재적 해결 방안을 브레인스토밍할 수 있다.
5. 새로운 기술들로 인해 생기는 기회 요소들을 발견할 수 있다.
각 능력의 상대적인 중요도는 여러분의 제품에 따라 달라질 것입니다. B2C 앱이라면 새로운 기술을 활용하는 것이 중요할 것이고, B2B 소프트웨어라면 정해진 스케쥴에 맞추어 프로젝트 범위를 정하는 것이 중요하겠죠. PM 은 이러한 이슈들의 중요도를 가늠해야 합니다.
이제 어디로 가야할 지는 조금 알았으니, 다음 질문은 어떻게 가야 하는가? 일테죠. 제가 발견한 방법들은 다음과 같습니다.
호기심으로부터 시작한다.
앞으로 있을 리스트 중, 이것만은 무조건 지켜야 합니다. 기술적인 문제들에 대한 진정성 있는 호기심은 여러분들의 든든한 동반자가 될 것입니다. 호기심이 없다면, 다음 말씀드릴 일들은 그저 '해야할 일' 일 뿐이겠지요. 특정한 지점까지는 이런 호기심을 일부러 길러내는 것이 가능은 하지만, 저라면 PM 인터뷰 도중 이러한 신호들을 찾아낼 것입니다. Ellen Chisa 가 이와 관련된 훌륭한 포스트를 썼으니, 더 관심이 있다면 읽어보시면 좋을 겁니다.
엔지니어링에 내재된 창의성을 존중한다.
바로 전 이야기와 이어지는 포인트입니다. 엔지니어링이란 무에서 유를 창조하는 행위로서, 그 안에 엔지니어의 창의성이 내재되어 있다는 사실을 잊지 말아야 합니다. 또한 엔지니어링은 복잡성을 필연적으로 동반합니다. 구현된 모든 기능의 뒷면에서 엔지니어는 항상 수 많은 결정들을 내리고 있습니다. 내리게 될 결정 사이에 섬세하고 장 단점을 비교하며 디테일을 적용하고, 특이 케이스들을 고려해가면서 말이죠. PM 으로서 이러한 절차와 역학들을 이해하는 데 실패한다면, 엔지니어들은 최선의 퍼포먼스를 내기 위해 필요한 "제품에 대한 주인의식" 을 잃게 됩니다.
엔지니어들을 괴롭힐(?) 시간을 초기에 만들어 둔다.
첫 며칠 간 여러분들이 읽을 수 있는 것은 모두 읽고, 끊임 없는 질문 리스트들을 만들어 두세요. 그리고 화이트보드 하나를 잡고, 엔지니어 한 분을 초대해 질문들을 같이 검토해 보세요. 현명한 질문을 위해선 사전에 충분한 이해도를 쌓아 두어야 합니다. 같이 질문을 검토하는 부분은 너무 미루지 마세요. 스크린을 쳐다보는 것만으로 배울 수 있는 것에는 한계가 있으며, 팀원과 함께 보내는 시간은 큰 도움이 될 것이니까요.
배운 것을 공유할 수 있는 형태로 갈무리한다.
이 지점에서 여러분들은 온갖 약어와 끄적거린 다이어그램들 속에서 허우적대고 있을 겁니다. 새로운 정보들을 전부 문서 형태로 갈무리 하세요. 갈무리한 문서를 신입 직원들과 공유하세요. 그들이 적응을 위한 리소스로서 활용할 수 있도록이요. 다른 분야 매니저들에게 여러분이 맡고 있는 분야의 소개 발표를 해 본다면 더 좋을 겁니다. 이렇게 공유하고, 발표하는 것은 여러분이 어떤 것을 알고 있으며 어떤 것을 더 파봐야 할 지 잘 알게 해줍니다.
피드백과 버그 리포트를 활용해 다양한 이슈에서 패턴을 찾아본다.
"충분히 기술적" 이라는 것이 무슨 의미인지에 대한 첫 번째 이야기로 돌아가 봅시다. "사용자 이슈들을 통해 기저에 있는 문제를 파악할 수 있다." 는 것이 첫 번째 기준이었습니다. 이를 위한 방법 중 하나는 피드백과 버그 리포트들을 짜맞춰 패턴을 파악해보는 것입니다.
PM 으로서 여러분들은 제품에 대한 피드백에 대해 첫 번째로 대응할 수 있는 영광을 가지게 됩니다. 예를 들어 보죠. 어떤 날 여러분들은 다수의 혼란스러운 버그 리포트를 받았습니다. 동료가 슬랙을 통해 "검색 내용에 작은 따옴표를 붙이면 연관검색어가 나오지 않아요." 라고 말했고, 어머님이 이메일을 통해 "'윌리엄-소노마'를 찾았는데, 결과가 나오지 않는구나. :(" 라고 말씀하셨습니다.
여러분들이 이슈를 트래킹할 수 있는 충분한 준비가 되어있다면, 다음과 같은 일들이 일어나게 됩니다.
1. 특정 버그에 대해 엔지니어들이 쓰는 단어들을 알아들을 수 있게 됩니다.
2. 다양한 이슈들이 공통적인 문제에서 나올 경우, 관련된 이슈들을 연결지을 수 있게 됩니다.
따라서 동료와 어머님으로부터 받은 리포트가 한 가지 이슈에서 생긴 것이라는 것을 알 수 있겠죠. "표준화된 자동완성 기능이 구두점들을 적절히 통제하지 못하다." 라는 기술적인 문제를요. 또한 이러한 과정을 통해 다양한 이슈들의 크기나 중요도에 대해 가늠해볼 수 있는 능력을 키울 수 있게 됩니다.
코딩과 친숙해 진다.
당황하실 필요 없습니다. "코딩과 친숙해 지는 것" 의 목표는 코드 내 언제 어디서 특정 변수들을 선언하는지 정도에 대해 답할 정도면 됩니다. 엔지니어들을 괴롭힐 필요 없이요.
핵심 개념에 집중한다.
모든 분야에는 항상 등장하는 개념들이 있습니다. 검색 분야에서의 정확도 vs 재현율이라던가, 데이터 모델링에서의 카디널리티(Cardinality) 등이죠. 컴퓨터 과학 내에서 그러한 개념들을 파악해보고, 구체적으로는 여러분들의 제품 분야에서도 알아보세요. 이러한 작업들은 학습의 우선순위를 파악할 수 있게 해 줍니다.
철면피가 된다.
커닝햄의 법칙에 따르면, "인터넷에서 정답을 얻는 가장 좋은 방법은 질문을 올리는 것이 아니라, 잘못된 대답을 올리는 것이다." 라고 합니다. 여러 관점에서 이 말은 PM 의 역할에 대한 완벽한 비유로 볼 수 있죠. 제품의 기능이나 스펙에 관한 초안, 낙서 등을 만들어 다른 사람들이 씹고 뜯고 맛보고 즐길 수 있게 하는 것이 여러분들의 일입니다. 못생긴 빨대 인간들을 그려놓는 것이 중요한 게 아니고, 이러한 일이 대화 자체를 시작되게 만든다는 것이 중요합니다.
어떻게 즉각적인 가치를 더할 수 있는 지 파악해 신뢰를 쌓는다.
새로운 기술을 배우는 것은 시간이 걸립니다. 하지만 일과 함께라면 풀타임으로 학생이 될 수 있는 사치 같은 건 없습니다. 여러분들이 즉각적으로 영향을 미치고 기여를 시작할 수 있는 분야를 찾아내야 합니다. 하지만 이건 그렇게 어렵진 않습니다. 애초에 여러분들이 고용 된 이유 자체가 여러분들이 가진 기술과 능력 덕분이니까요.
데이터를 파고든다.
팀 내 각 역할은, 다른 사람들이 함께 일하고 싶도록 만드는 슈퍼 파워들이 있습니다. 디자이너라면 고해상도 프로토타입 등을 빠르게 만들 수 있는 능력이라던지, 엔지니어라면 빠르게 프로토타입을 구현하고 언제 코드들을 가다듬을 지 판단하는 능력 등이죠.
제가 생각하기에 PM 의 슈퍼 파워는 데이터에 대한 능숙함입니다. "ABC 라는 기능이 얼마나 쓰이죠?" 라는 질문이 튀어나왔을 때, "대충 123 정도요." 라고 바로 대답할 수 있는 능력이죠. 그러면 여러분들은 신뢰를 쌓게 됩니다. 제품 분석 쪽에 있는 사람들이 PM 으로 많이 가는 이유도 이에 있다고 생각됩니다.
실제적으로는, 데이터에 대한 능숙함이란 것은 다음과 같은 일들을 할 수 있는 것입니다.
1. 어떤 프론트 엔드와 백 엔드 데이터들이 어떻게 로깅되는 지 알고 있다.
2. 데이터가 어디에 저장되는지 알고 있다.
3. 데이터들을 쿼리하는 방법을 알고 있다.
4. 실험의 결과를 분석하는 방법을 알고 있다.
5. 가장 좋은 디자인 사례들을 찾아 실험할 수 있다.
프로젝트가 진행될 수 있도록 장애 요소를 치운다.
효율적인 미팅을 진행하세요. 이는 다음과 같은 것들입니다.
1. 미팅의 목적이 참가자들에게 전달되었다.
2. 의사결정에 필요한 사람들이 모두 참가한다.
3. 미팅의 시작에 적절한 정도의 맥락이 공유된다.
4. 미팅이 끝날 때 분명한 액션 아이템들과 소유자들이 있다.
5. 회의록을 작성하고 지체 없이 공유 한다.
지나치다 싶을 정도로 커뮤니케이션하고, 기록하세요. 언제 이메일을 쓰거나 쓰지 않는게 좋을 지 잘 파악하세요. 다른 팀에게서 자주 받는 질문들은 답변들을 모아 스스로 답변을 찾아볼 수 있는 장소를 만들어 주세요.
엔지니어들에게 질문하세요 : "지금 하고 있는 일 중에 하지 않았으면 하는 일은 뭐가 있나요?" 버그 리포팅, 로그 상세 요구 기술, 데이터 뽑기, 다른 팀으로부터의 요청 처리 등, 엔지니어들이 하고 있는 일 중에 여러분이 할 수 있는 일을 찾아 덜어 주세요.
경험과 강점에 기댄다.
일을 막 시작했을때, 전 다른 사람들에게 제가 기술 백그라운드를 가지지 않았다는 것을 알리고 싶지 않아 제 마케팅 배경에 사람들이 주목하는 것을 피하려 했습니다. 바보같은 짓이었죠. 제가 가진 백그라운드가 제가 PM 이 된 이유 중 하나이기도 했을 테니까요. 이메일 캠페인을 진행하는 것이든, 빠른 설문을 하는 것이든, 사용자 인터뷰를 진행하는 것이든, 작은 성취들을 쌓아 나가 모멘텀을 형성하세요.
의사결정 과정에 활용될 수 있는 프레임워크를 제공한다.
이전의 슈퍼파워 비유를 기억하시나요? 이번 것은 데이터에 대해 아는 것만큼 중요합니다. 좋은 PM 은 그들이 참여하는 모든 대화를 명료하게 만들어 줍니다. 날카로운 질문을 던질 줄 알죠. 당신이 어떤 문제를 왜 풀고 있으며, 어떻게 그것을 측정할 것인지, 그리고 어떤 순서로 문제를 풀어갈 것인지 말해 줄 수 있습니다. 더 중요한 것은, 좋은 PM 이 만들어 공유한 "생각의 프레임워크" 를 통해 PM 이 자리에 없더라도 팀의 모든 사람들이 최선의 결정을 할 수 있게 만드는 것입니다.
팀에게 큰 맥락을 공유하는 시간을 가진다.
PM 으로서 여러분들은 종종 팀의 대표로 어떤 미팅에 참여한다거나, 이메일 참조를 혼자 받게 됩니다. 팀 외부와의 상호작용을 팀 내 모두에게 항상 공유하세요. 이렇게 공유하는 데에 즉각적인 장점은 없겠지만, 지속적인 공유를 통해 누적된 맥락에 대한 이해도는 팀원들끼리 논쟁거리가 될 만한 사안을 직접적으로 이야기하는 것을 쉽게 만들어 줍니다. 시간이 지남에 따라 팀원들은 여러분들에게 질문과 고민거리들을 안고 찾아오게 되겠죠.
아직 배울 것이 많은 제품 팀 소속으로서, 번역을 하며 많은 도움이 되는 글이었습니다. 글을 읽는 모든 분들도 배울 것을 얻어가셨으면 합니다. 감사합니다.
