PM으로서 나는 지금 어디에 있을까?
6가지 항목에 맞춰 스스로를 평가해보자
[Kevin과의 1:1 멘토링 1번째 과제]
코드스테이츠에서 진행하는 PM 부트캠프 with 쿠팡에 합격했다. 3주간의 실제 프로그램 전 1:1 멘토링을 진행하고 첫 번째 과제를 받았다. (기쁘다!) PM의 6가지 항목을 보고, 나는 과연 어느 부분에 강점/약점을 가지고 있는지 파악을 한다. 그리고 각 항목에 대해서 어떻게 개선할지 등에 대해 정리하는 과제이다.
6가지 항목은 다음과 같다.
제품과 디자인 인사이트 (Product and design insight)
영향과 결과 (Impact and results)
전략과 리더십 (Strategy and leadership)
분석적인 유창성 (Analytical fluency)
기술적 소양 (Technical literacy)
의사소통과 협업 (Communication and collaboration)
(자세한 내용은 PM의 소양을 스스로 점검해보자 에서 볼 수 있다. Medium 글인데, 영어 공부 겸 번역을 했다.)
평가 기준
진행했던 프로젝트를 다시 생각해보며, 잘한 것과 아쉬운 점을 토대로 평가하였다.
(글을 다 써보니, 사례가 정확한 숫자의 이유를 대변하진 않는 것 같다..)
5점 만점으로 평가했고, 순위를 정하기 위해서 동점은 피하고 0.5 점을 추가했다.
최고점과 최저점은 주지 않았다. 더 성장해야 한다고 생각했고, PM으로서 알아야 할, 해야 할 일에 대해서는 알고 있기 때문이다.
Overview
제품과 디자인 인사이트 (Product and design insight) : 4.5
영향과 결과 (Impact and results) : 3
전략과 리더십 (Strategy and leadership) : 4
분석적인 유창성 (Analytical fluency) : 3.5
기술적 소양 (Technical literacy) : 2
의사소통과 협업 (Communication and collaboration) : 2.5
Details
제품과 디자인 인사이트 (Product and design insight) : 4.5
Product Manager로서 가장 중요한 것은 Product와 User를 이해하는 것이라고 생각한다. 내가 만들고 싶은걸 만드는 게 아니라, 사용자가 필요한 걸 만들어야 하기 때문이다. 이를 위해서 항상 고객과 소통하고 데이터를 보려고 한다. 그리고 이를 바탕으로 개선안을 제안하고 수행한다.
사례
첫 회사인 스위처에서는 모든 고객 접점을 담당했다. 고객이 필요한 것과 불편해하는 것을 듣고 데이터까지 확인했다. 자연스레, 제품과 비즈니스 전반에 다양한 인사이트를 갖고 개선안을 제안했다. 간단한 사례로, 앱 내 '예약' 기능을 개선하여 해당 기능을 사용하는 비율을 높였다. 이는 유료 사용자 전환율이 상승하는 성과까지 이어졌다. 지금 담당하는 제품 또한 마찬가지다. Product 개선을 위해 끊임없이 제품과 고객을 탐구해야 한다. 그리고 이를 기반으로 팀원에게 새 기능이나 개선안을 제안하고 공감시켰다.
전략과 리더십 (Strategy and leadership) : 4
이 항목은 2019년 내가 가장 집중한 분야다. 함께 일하는 팀원이 서로 다른 목표와 방향성을 가지면 일이 제대로 진행되지 않는다. 이를 위해 PM은 올바른 방향성을 제시해야 하고, 그들이 방향을 잃지 않도록 동기부여시켜야 한다. 그리고 협업을 위한 환경과 마음가짐 또한 중요하다.
사례
작년 한 해 7명의 팀원을 리딩 했다. 협업을 위한 환경을 위해 애자일 문화도 도입하고, 협업 툴도 소개했다. 그중 가장 중요한 것은 목표를 잡고, 업무의 방향성과 마음가짐의 align을 맞추는 것이었다. 이를 위해, 회사에서 얘기하는 비전 (장기 목표)를 파악하고, 이에 맞는 중/단기 목표를 설정하고 팀원들과 공유했다. 또한, 작은 세미나와 월 단위 회고를 진행하며 팀원 간의 합을 맞춰가는 노력을 계속하였다. 초기 업무 내용이나 진행 방식에 대한 부정적인 피드백은 시간이 지남에 따라 점차 사라졌고, 팀원들의 업무 만족도 역시 향상되었다.
분석적인 유창성 (Analytical fluency) : 3.5
앞서 얘기했듯, 사용자 데이터는 정말 중요하다. 이때, 정성/정량적 데이터 둘 다 중요하다. 정량적 데이터를 통해 어떤 현상이 발생하는지 파악한다. 그리고 정성적 데이터로 왜 그 현상이 발생했는지 이유를 찾는다. 이를 이용하여 인사이트를 가지고, 지표를 도출하여 개선방향을 세운다.
사례
데이터를 보는 것의 중요성은 알고 있지만, 어떤 데이터를 볼 지 정하는 것은 또 다른 문제이다. 데이터를 보는 것보다 더 중요한 것 같다. Firebase에서 제공하는 retention을 보았는데 앱 릴리즈 시점과 1년 운영 후 수치가 비슷했다. 그동안 사용자 버그를 수정하고, UI를 몇 가지 수정했지만 retention 자체에는 변화가 없었다.(관련 CS는 발생비율을 현저히 줄었다.) 목적에 맞는 지표를 세우고 데이터를 봐야 한다는 것을 배웠고, 앱 개선을 위한 Aha moment를 찾기 위해 다시 데이터를 살펴보았다. 이 과정에서 앱 설치 후 이틀간 앱의 기능을 사용하는 인원은 30일까지 사용하는 비율이 최대 60% 이상 높다는 것을 발견했고, 이를 지표로 삼아 개선안을 기획하였다.
영향과 결과 (Impact and results) : 3
Product backlog 에는 항상 수많은 아이디어와 업무가 존재한다. 그렇기 때문에 우선순위가 중요하다. 이 기능이 지금 정말 필요한 것인지, 아님 있으면 좋은 정도인 지 파악해야 한다. 또한, 결과를 내기 위해선 팀 내 리소스를 고려해야 한다. 이를 고려하지 않는다면 일정에 맞춰 개발을 마치지 못하고, 반대의 상황에선 의미 없는 결과만 나올 수 있다.
사례
6개월 전에 추가했던 기능에 대해 다시 한번 생각하면서 어떤 결정을 내리는 것이 더 현명했을까? 고민을 해보았다. 당시, 앱 내 사용자가 문제를 겪으면 바로 문의를 할 수 있는 방법이 없었다. 또한, E-mail로 들어오는 문의가 있었는데 따로 관리가 되지 않아서 증발되는 문제가 있었다. 2가지를 해결하기 위해 앱 내 이메일 문의하기 기능 추가를 진행하였다. 게시판이나 앱 내에서 문의/응답이 이뤄지는 방식도 생각했지만, 개발 공수가 더 많이 들고 이보다 높은 우선순위의 기능 때문에 진행될 수 없었다. 그리고 6개월이 흘러, 문의/응답을 앱에서 모두 볼 수 있게 기능을 개선하려고 한다. 내가 6개월 전에 내렸던 선택은 최선이었을까? 후자를 택했다면 어떤 결과가 나왔을지 알 수 없다는 점이 아쉽다.
의사소통과 협업 (Communication and collaboration) : 2.5
의사소통을 잘한다는 것은 팀원과의 원만한 관계를 갖는다는 뜻이 아니다. 그들의 의견을 듣되, 옳은 방향성으로 계속 갈 수 있게 공감시키고 설득해야 함을 뜻한다. 이런 과정에서 팀원의 감정과 인격이 다치면 안 됨은 물론이다. 직급 등의 요소가 아니라 순수히 Product을 위한 방향성이 논리적으로 설명되고, 데이터와 같은 객관적인 근거로 기반되어야 한다.
사례
전략과 리더십 (Strategy and leadership)에서 얘기한 대로, 개발팀 내에서는 문제가 없이 잘 수행했다. 하지만, 다른 팀(특히나 나보다 직급이 높은 사람들)과의 대화가 매끄럽지 않았던 적이 있었다. 아무리 논리적인 설명이나 근거 자료를 제시해도 설득이 되지 않는 경우가 있었다. 가령, 현재 앱은 10개 국어로 서비스되고 있다. 이를 위한 개발 공수는 엄청나지만, 10개국에는 전체에서 매출이 일어나진 않는다. "제공하는 다국어를 줄이자는 의견을 어떻게 설득을 했어야 하는가?"에 대한 방법은 아직도 찾고 있고, 계속적으로 성장해야 할 항목이다.
기술적 소양 (Technical literacy) : 2
기술적 소양은 계속 경험을 하면서 배워 가야 하는 항목 같다. 개발자만큼의 정보는 알 수 없고, 알 필요도 없다고 없는 것 같다. 다만, 내 분야에서 필요한 정도는 충분히 공부가 가능하고, 개발자에게 방해가 되지 않아야 한다고 생각한다.
사례
공유받은 텀블벅의 사례처럼 "API가 뭐예요?"라고 묻는 일은 다행히 없었다. 기본적으로 서버와 클라이언트의 의미를 이해하고 있고, 앱 개선 시 기능 추가, UI 변경 등 업무에 따른 사이드 이펙과 예상 시간을 체크하는 데는 문제가 없었다. 하지만, 고민이 되는 시점은 개발자가 "이건 좀 어려운 거예요"라고 말했을 때 납득이 되지 않는 상황에서의 대처였다. Unity로 만들어진 Application이었는데, 앱 내 Input field가 2개로 나오는 상황이었다. 회사 내 디자이너뿐만 아니라 지인들 역시 "이거 왜 이래?"라고 물어볼 정도였는데, 개발자는 관련된 Plug in 찾아봤지만 없다고만 대답했고 직접 구현하려면 시간이 오래 걸린다고 했다. 이 상황에서 정확히 '오래'라는 시간을 가늠할 수 없었고, 직접 plug in을 찾아볼 수도 없어서 답답한 상황이었다. 약 10개월이 흐른 시점에서 들어온 인턴에게 관련된 과제를 주었고, 해당 plug in을 찾아서 소스 수정을 한 뒤 해당 상황을 해결했다. 사실 이때 많은 생각이 들었다. 앞으로 이런 상황이 동일하게 발생한다면 어떻게 대응해야 할까? 주변 개발자들에게 도움을 매번 빌려야 하는 걸까? 위 5가지 항목은 발생한 이슈를 해결하기 위해 내가 어떻게든 할 수 있지만, 위 사례는 내가 아무것도 할 수 없다는 것에 대해 많은 답답함을 느꼈었다.
실제로 글을 쓰면서 Kevin과 멘토링을 하면서 매겼던 순서와는 조금 차이가 발생했다. 최대한 구체적으로 사례를 생각해보면서 작성을 해보니, 이슈가 생겼을 때 내가 직접 해결할 수 있는가? 여부가 점수를 매기는데 많은 영향을 끼친 것 같다. PM은 이슈가 생겼을 때 직접 해결하거나 해결을 할 수 있게 도움을 줘야 한다고 생각하는데, 이 때문에 개인의 무능함을 느꼈던 항목에 대해서는 추후 더 많은 공부를 해야겠다는 생각을 했었다.
