우선 제가 입사 초기를 ‘망했어요?’라고 이름 붙인 이유에 대해 설명할 필요가 있을 것 같습니다. 저는 입사 후 지난 8개월간의 기간을 ‘망했어요?’, ‘망했군요,’, ‘망하면 안 돼요!’기로 나눕니다.
우선 이번 글과 다음 글에 다룰 첫 번째인 ‘망했어요?’편은 문제가 생겨도 이를 제대로 파악하지 못한 기간을 말합니다. 약 3개월가량의 기간에 해당하며, 재미와 두려움과 어려움이 공존하는 시기였죠. 두 번째 시기인 ‘망했군요,’편은 문제에 대해 파악했지만 해결책을 내놓지 못한 시기를 말합니다. ‘망했어요?’편과 비슷한 3개월 가량의 시간이 소요되었고, 저로서는 일종의 ‘슬럼프기’에 해당하기도 했죠. 마지막 ‘망하면 안 돼요!’편은 이후부터 지금까지 쭉 지속되고 있는 기간을 말합니다. 나름의 목표의식이 생겼고, 이를 위해 열심히 달려가고 있는 시기이죠.
아직 많이 부족한 PM이지만 저와 비슷한 고민을 하고 계실 분들을 위해, 그리고 제 나름의 기록과 정리를 위해 당분간 글을 하나하나 써 내려갈 계획입니다.
앞선 글에서 이야기했지만…
제가 이해한 바에 따르면 PM이 해야 할 일은 크게 세 가지로 나눠집니다. 마케팅과 고객사 협력, (내부) 운영이 그것이죠. 저는 입사 초기 이 세 가지 중에서 ‘고객사 협력(라고 쓰고 CS라 읽는..)’에 집중하기로 했습니다. 이유는 다음과 같습니다.
1. 입사한 회사(유저해빗)가 이전 회사와 동일한 IT분야에 해당하기는 하지만 전혀 다른 성격(이전 회사는 앱 서비스, 지금 회사는 애널리틱스 서비스)을 지닌 탓에 단기간 내에 서비스를 이해하기 어려운 상황이다.
2. 그렇다고 내부에서 서비스를 이해하기엔 (대부분의 스타트업이 그렇듯) 별도의 OJT 자료나 업무 이월을 해줄 전임자 또는 사수가 없는 상황이다.
3. 더불어 적은 인원이 최대한 많은 일을 해내야 하는 스타트업의 특성상 새로 들어온 인원이라 할지라도 가급적 빠른 시일 내에 업무에 투입되는 것이 좋다.
(그러므로) 실제 업무를 수행하는 동시에 서비스에 대한 이해도를 높일 수 있는 고객사 협력에 집중하는 것이 옳다.
그리하여 입사 둘째 날부터 고객사 미팅을 나가기 시작했습니다. 물론 저 혼자서는 아니었고, 사실상 해당 업무를 전담하고 계시던 개발자 분과 함께 말이죠. 며칠 동안 고객사를 함께 돌아보니 당장 보이는 문제점이 하나 있었습니다. 바로 ‘개발자와 고객사가 직접 연결되어 소통하다 보니 추가적인 요구 사항에 대한 거절이 힘들다’라는 것이었죠.
물론 개중에는 당연히 바로잡아야 할 부분도 있었고, 향후 개발에 저희가 참고해야 할 부분도 있었습니다.
하지만 어떤 때는 종종 ‘조금은 과하다 싶은(..?)’ 요구 사항을 하는 경우도 있었죠. 그리고 개발팀에서는 이런 일들이 명확한 우선순위가 정해지지 않은 채 주먹구구식으로 처리되고 있었습니다.
논의 끝에 약 일주일 뒤부터 고객사와의 협력 프로세스를 바꾸기로 했습니다. ‘고객사 ↔ 개발자’ 형태에서 ‘고객사 ↔ 저(PM) ↔ 개발자’의 구조로 말이죠. 사실 이 구조는 당장의 업무 효율성만 생각하면 그리 좋은 형태는 아니었습니다.
제가 서비스를 아직 제대로 이해하지 못한 상황이라 고객사에서 질문을 하면 제가 다시 담당 개발자분께 이를 전달하고, 다시 답변을 전달받아서 고객사에 전달하는 요상한(?) 구조를 지니게 되었으니 말이죠. (물론 저는 기본적으로 비 개발자 출신의 PM이라 문의사항 대응과 관련해서는 개발팀의 도움을 현재까지도 많이 받고 있는 상태입니다.)
1. 장점
(1) 별도의 교육과정 또는 이월 없이 서비스 구조를 빠르게 파악할 수 있다.
(2) 고객사의 목소리를 직접 들을 수 있기에 우리 서비스가 바뀌어야 할 점이 무엇인지 알 수 있다.
(3) 입사 초기부터 회사 내부에서 어떠한 역할을 한다는 인식을 심어줄 수 있다.
2. 단점
(1) CS 또는 미팅 등이 몰릴 때는 사실상 다른 업무를 할 수 없다.
(2) PM이라는 직책 및 역할에 대한 내부 구성원들의 의구심이 생긴다.
그래서 이 방식이 좋은 거냐고요? 사람마다, 회사마다 다르겠지만 저와 저희 회사의 입장에서는 꽤나 성공적이었다고 말하고 싶습니다. 우선 CS에 투입되는 바람에 발생하는 개발 누수를 줄일 수 있었고, 고객사와 직접 상대하며 오는 스트레스를 개발자분들이 최소한 ‘덜’ 받으실 수 있게 되었기 때문이죠. 더불어 저는 서비스 구조를 고객의 입장에서 좀 더 세밀하게 바라볼 수 있는 기회를 갖게 되었고요.
물론 지금에 와서 생각해 보면 고객사 협력에 너무 힘을 쏟는 것보다는 세 가지 요소를 모두 균형 있게 하는 것이 좋지 않았을까 싶은 생각이 들기는 합니다. 제가 원한 역할은 프로젝트 전반에 대한 관리였고, 이는 회사 역시 마찬가지였으니 말이죠.
하지만 후회는 후회일 뿐, 그때 제가 가진 역량으로 할 수 있는 최선은 고객사 협력 분야에 매진하는 거였습니다.
‘망했어요?’편에 제가 집중한 다른 한 가지 영역, ‘마케팅’과 관련해서는 다음 시간에 이어서 다뤄보도록 하겠습니다. 길고 두서 없는 글 끝까지 읽어주셔서 진심으로 감사드립니다 
이전 글
이준형님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
