프로덕트 매니저로써 내가 했어야 하는 것들
PM 입사 3개월. 그러나 저도 프로덕트 매니저는 처음이라서요
지난해 10월, 첫 이직을 했다.
나의 첫 스타트업은 pre-A가 갓 끝난 시점의 코리빙/코워킹/브랜드 공간을 개발, 운영하는 오프라인 기반의 조직이었다. 10명 남짓하던 그 시절, 사소하게는 가구 운반 같은 운영도 하루의 일과였고, 이후로는 운영 관련 데이터 파이프라인을 구축하고 관리하는 운영 관리를 담당했다. 이후 여러 장소의 고객들에게 통일된 서비스 제공을 위해 서비스 기획과 Project Managing을 담당했다.
성장하는 시장과 조직이었지만 오프라인 비즈니스, 그중에서도 부동산 개발, 운영 비즈니스의 특성상 end-user인 입주자/멤버에 대한 이해의 부족과, 정량적인 접근이 불가능에 가까운 점이 늘 아쉬웠다. 무엇보다 '고객의 문제를 해결하고 가치를 제공함으로써 비즈니스의 목표를 달성한다'는 이해가 부족했다.
그러다 지난 10월, 고객과 문제 해결, 그리고 가설 검증을 중요시한다는 JD에 반해 Series A가 끝난 조직의 Growth Product Manager로 합류했다. 보통 PM이라고 할 때 이야기하는 서비스 기획도 해봤고, 프로젝트도 관리했지만, 프로덕트 매니저에게 기대되는 역할은 전혀 달랐다. 요즘 식으로 이야기하면 "저도 프로덕트 매니저는 처음이라서요" 같았던 3개월.
그리고 아래는 지난 3~4개월의 스스로에 대한 소회다.
아쉬운 것 + 그렇지만 깨달았으니 이제라도 개선할 수 있는 것
1. 팀과 동료에게 다가가는 게 늦었다
팀 내 구성원 및 다른 팀의 동료들에게 먼저 다가가는게 늦었다. 새로운 곳에 왔으니 '적응'을 해야 한다고 생각했고, 그 적응이라는 게 기존의 체계, 문서를 파악하는 게 전부라고 생각했다. 일하는 방법, 문서, 기존 히스토리가 모두 '사람'에게 있다는 걸 놓치고, 남는 시간엔 문서를 먼저 들여다봤다.
물론 이유는 있다. 스타트업, 특히 같은 직무의 동료가 없는 조직 특성상, 먼저 나서 무언가를 알려주는 사람은 없었기에, 문서 등을 읽고 파악하는 시간은 절대적으로 필요했다. 알아야 하는 것에 어느 정도 알게 되었다는 생각이 들고 나서야 사람들을 만날 여유가 생겨 티타임 점심 등을 함께 했지만 이는 이미 팀에 합류한 지 3개월이 되어가는 시점이었다. 순서가 거꾸로였다.
만약 다시 돌아갈 수 있다면, 어떤 팀의 누가 어떤 문제를 해결하는지, 어떤 점을 요청할 수 있고 어떤 점을 도와줄 수 있을지를 좀 더 이야기 나눠 볼 것 같다. 그리고 이를 제일 우선순위로 둘 테다.
일하는 방법, 문서, 기존 히스토리가 모두 '사람'에게 있다
2. 틀리는 것에 대해 두려워했다
이건 아마 성격, 성향의 문제인 것 같다. 다만 누가 혼내는 걸 두려워한다거나, 자존심이 세다는 의미가 아니다. 정확히는, 나의 주장, 의견이 100% 맞다는 보장이 없으면 자신감을 잃는다. 삶이든 일이든 100%라는 건 없다는 걸 알면서도, 종종 그런다.
특히 이러한 성향은, 누가 알려주는 사람이 없다는 환경 때문에 조금 더 심해졌던 것 같다. 온보딩 없이 거의 바로 투입되어야 했고, 정보나 방법론을 충분히 숙달하지 못했(다고 생각했)고, 그러니 나는 틀릴 것이라는 생각이 더욱 강해져 더욱 소극적으로 변했다.
이는 대표님과의 1:1 미팅을 통해 적절한 균형을 찾아가고 있다. "기획자는 많이, 깊이 고민하는 사람이 맞지만 틀리지 않기 위해 고민하다 보면 시간만 쓸 뿐이다. 틀리는 건 상관없다. 다만 틀린 뒤에 배워갈 수 있도록, 최소한의 '가설'만 들고 오면 된다." 생각해보니 애자일agile과 그로스growth라는 게 모두는 처음엔 무조건 틀림을 전제로 하는 일이다.
틀리지 않기 위해 고민하다 보면 시간만 쓸 뿐이다. 틀리는 건 상관없다. 다만 틀린 뒤에 배워갈 수 있도록, 최소한의 '가설'만 들고 오면 된다.
3. 고객에 대한 이해가 늦었다
팀에 합류 후 제품의 레거시와 정책 파악을 먼저 했다. 물론 제품에 대한 파악은 무조건 필요하다. 제품/서비스에 대해 일관되고 공통된 이해가 없다면, 이는 장기적으로 불편 너머 위험을 초래할 수 있으니까. 주요 정책을 문서화해두는 것, 특히 이를 개발자가 아니라 고객과 서비스 운영자가 참고하고 이해할 수 있는 언어로 바꿔 놓는 작업은 꾸준히 가져가야 할 과정이다.
그러나 이게 고객 개발과 이해에 앞서지는 않는다. 만약 처음으로 다시 돌아간다면, 정책 문서보다는 기존의 고객 개발 문서-인터뷰, 설문조사 등-를 먼저 살펴봐 고객의 아바타, 우리 서비스를 쓰는 이유 등을 먼저 이해하고, 필요하다면 직접 설문, 인터뷰 등을 할 테다.
특히 단순히 '다 같은 고객'으로 취급하지 않고 1) 유형별, 이해관계별로 segement를 나누고 2) 현시점에서 핵심 유저를 정의하는 작업 역시 잊지 않을 테다.
제품에 대한 파악은 무조건 필요하다. 그러나 이게 고객 개발과 이해에 앞서지는 않는다.
했지만 앞으로 계속할 것 & 더 잘해볼 수 있는 것
1. 정책 문서화
어찌 되었건 서비스에 전반의 각종 정책에 대한 이해는 공통되고 일관되어야 한다. 고객의 CS, VOC를 담당하는 이들은 이를 바탕으로 에러 사항에 대해 안내하고, PM은 각 팀의 요청 사항 혹은 문의 사항에 대해 답변할 수 있다. 또한 기존 서비스를 리뉴얼하거나 새로운 서비스를 기획할 때에도, 기존의 레거시 파악은 필요하다.
문서화는 흔히 '대기업/공공기관 스러운 일'이라는 인식이 있다. 그러나 이는 문서 없이는 일을 못하는, 태도에 가깝지 문서 자체가 없어도 되는 조직은 어디에도 없(다고 믿는)다. 문서화는 비단 내부 구성원의 편의뿐만 아니라, 최종적으로는 고객에게 믿을 수 있고 안정적인 서비스를 제공하기 위한 필수 작업이고, 제작자들이 업무에 집중하고 + 서비스 전체를 이해하기 위해 PM이 해야 할 일이 맞다고 생각하고 있다.
다만 다양한 이해관계자들에 의해 실험과 변형이 일어나는 서비스이다 보니, 눈에 보이는 단위의 정의description이 아닌, 말 그대로 핵심 정책policy에 대해 정리하고, 이것이 왜 그렇게 정해졌는지, 어떤 이해관계자의 어떤 가치/편의를 위한 것인지를 덧붙여 정리해두는 방향으로 수정이 필요하다.
2. 안정적인 QA를 위한 Test Case
조직에는 한때 서비스 기획자가 있다고 했다. 그러나 지금까지의 문서(의 부재)를 통해 미루어보건대, 지금 정도의 서비스 범위, 크기를 안정적으로 구축~QA 하기 위한 시도는 아쉬운 부분으로 남아있는 듯했다.
팀에 합류하고 나서 제일 놀랐던(?) 점은 QA를 위한 Test Case가 없었던 점이었다. 정확히는 있기는 한데, 구조적이지 않아다. 개발자들이 TC를 작성하기도 했고, 때론 실서버에 배포 후 확인을 하기도 한 듯했다. 그래서 팀에 합류 후 서둘러 최종 배포 전에 Test Case를 통한 QA를 할 것을 제안했고, 이를 챙기고 있다.
역시나 이는 쓸데없는 문서 작업을 늘리는 게 아니라, 오히려 고객에게 우리가 전달하기로 한 가치를 제대로/안정적으로 전달하기 위한 과정이다.
3. 서비스의 구조 파악과 주요 지표의 정의, 그리고 대시보드화
팀에 합류 후 제일 먼저 한 작업 중 하나는 이 제품이 돌아가는 구조와 그 구조 내에서 우리가 챙겨봐야 할 지표의 정의였다. 그러나 3개월이 지난 지금 돌이켜보니, 구조의 일부를 놓친 것도 있다. 또한 팀이 함께 보기 편하도록 대시보드를 만들었다고 생각했지만, 편의성/가독성이 떨어지는 듯하다.
다시 세팅한다면 (곧 세팅 다시 할 거지만) 사용자 수와 각 구간의 전환율 너머
- 신규 유저와 기존 유저를 분리하고
- (별도의 마케팅 활동을 하지는 않지만) 신규 유저의 경우 유입 경로도 파악하며
- 특히 주요 활동의 경우 핵심 유저의 레벨/계층에 다라 따로 분리하여 추적하고
- 이 외에도 우리 유저들이 서비스를 사용하는 환경과 패턴 등에 대해서도 파악할 수 있게 할 예정이다
여전히 고민 중인 것
1. 리더십
리더란 팀 또는 어떤 단위 부서의 '장'인 줄로만 알았다. 그러나 제품의 성장을 담당하는 Growth PM은 일견 리더로서의 소양이 필요함을 체감하고 있다. 이를 체감하게 된 계기는 아래와 같다.
1) PM은 해결할 문제를 제시해야 한다. 문제를 발견하고, 이를 정의하여 설명할 수 있어야 한다. 가령 어떤 구간의 전환율이 급격히 떨어졌거나, 활동이 줄어들었다면, 이를 문제로 인식하고 그것이 문제가 되는 이유를 추측 및 정의해야 한다. 그래야만 그 문제를 풀기 위해 어떤 활동을 할 수 있는지 팀이 명확하게 이해할 수 있다.
2) PM은 해결할 문제의 우선순위를 정해야 한다. 산적한 여러 문제 중 어떤 문제를 먼저 풀 것인가? 그걸 풀어야 하는 이유는 무엇이며 그것이 우선시되는 이유는 무엇인가? 를 설득시킬 수 있어야 한다. 팀원의 리소스는 귀하다.
3) PM은 우리가 풀고 있는 문제가 비즈니스의 어디에 기여하는지 명확하게 설명할 수 있어야 한다. 제안한 그로스growth 과제를 왜 하는 건지, 하면 어디에 좋은 건지. 역시나 팀원의 리소스는 귀하다. 또한 이는 고객도 좋고 우리도 좋은데 회사는 그다지 좋지 않은 이상한 상황, 을 피하는데 필요하다.
2. 커뮤니케이션
이는 위 1번의 리더십에 대한 고민과 이어진다. 방향을 제시하고, 문제를 설득하고, 이유를 설명하는 과정이 난해 해선 안 된다. 또한 너무 급작스러워서도 안 된다.
결국 PM/기획자는 '우리 저 문제를 풀어볼까?'라고 제안하는 것뿐, 실제로 그 문제를 푸는 주체는 동료/팀원인 디자이너와 개발자다. 그러니 누구나 이해할 수 있도록 쉽게 말할 것. 뜬금없지 않게 빌드업을 할 것. 근거는 충분히 마련할 것. 그러나 이를 준비하겠다고 너무 오래 걸리지도 않을 것.
어쩌면 제일 어렵고, 평생 연습할 부분이 이 리더십과 커뮤니케이션이라는 생각이 든다.
