왜 서비스 기획자로 멀쩡하게 다니던 회사를 퇴사했을까
서비스 기획자와 PMO는 목표, 우선순위, 설득의 근거가 다르다
*오늘의 글은 '도그냥'님의 콘텐츠에 대해 한 달 전에 스터디했던 내용을 기반으로 PMO-서비스 기획자의 차이 및 퇴사 회고를 다루고 있기에 특성상 반말로 작성할 예정입니다.
Project Manager, Product Manager, Product Owner 등 프로덕트 직무를 부르는 다양한 명칭에 대해 이 글에서는 ‘PMO’로 통일하여 설명하겠습니다.
* 너무 길어져서 쓰다가 1편/2편으로 잘랐습니다. 미리 스포일러를 보신 분께는 양해를 구해요...(다음에 본 내용 또 올라간다는 소리...)
왜 서비스 기획자로 멀쩡하게 다니던 회사를 퇴사했을까
기획자는 ‘제품의 완성’을 위해 일하고,
프로덕트 매니저는 ‘제품의 성공’을 위해 일한다.
약 1년간 (조팝꽃) 서비스 기획자로 일하고 최근 퇴사했다.
가장 큰 이유는 내가 일했던 조직에서 정해진 서비스 기획자 역할의 한계 때문이었다.
물론 PMO/서비스 기획자를 그저 이름만으로 능동/수동적 포지션이라 딱 잘라 말할 수는 없다.
PMPO라고 모두 다 ‘생태’인 것도, 서비스 기획자라고 모두 다 ‘동태’인 것도 아니다. 오히려 조직 문화나 협업 문화가 능동적이거나 수동적이기에 그렇게 보일 뿐(-대개 'IT/웹 기획자'라는 이름으로 채용 공고를 내는 조직이 경험상 다소 수동적일 확률이 높다-) 서비스 기획자라고 수동적으로 일만 받는 것이 아니라 충분히 주도적으로 프로젝트를 끌어 나갈 수는 있을 것이다. 그러나 전 회사의 서비스 기획자는 (설득이나 설명해주는 사람이 거의 없이) 주어진 일을 하는 사람에 그쳐 있었기에 일의 의미를 직접 찾아야 했고, 협업/회고/지표 기반 설득 문화를 중시하지 않았기 때문에 성장하기 어려울 것이라는 판단이 들었다.
목표와 책임의 정도가 다르다.
일단 '모던 타임즈' 해야 하는 서비스 기획자당시의 조직에서 신입 서비스 기획자에게 요구된 제1의 미덕은 ‘스토리보드를 빠르게 쳐내는 스킬’이었다. 일단 신규 기능을 빠르게 오픈하는 것이 중요했기 때문에 장기적인 관점에서 담당 서비스가 어떻게 굴러갈 지에 대한 고민까지 할 필요는 없었다. (물론 운영팀이 따로 있어서 그들의 업무 범위에 해당하긴 했다.)
겨우 겨우 ‘서비스 기획자’ 타이틀을 힘들게 얻었는데, 어느 순간 기획 실무뿐만 아니라 개발 조직을 매니징하고 관리하는 ‘PM’으로서의 업무와 책임까지 가지게 됐었다. (근데 의사 결정 권한은 1도 곁들여 있지 않은... ^^ 제품 기획자보다는 '욕받이 무녀'에 가까웠다.)
REAL로 '쇼미 더 머니' 할 책임이 있는 PMO...PMO는 서비스나 기능을 오픈한 이후에 '진짜 일'이 시작된다. 런칭한 기능이 비즈니스 임팩트(=돈을 벌어 왔는가)를 낳았는지가 중요하기 때문에 결과에 대한 비즈니스적 책임에서 자유롭지 않는 것이다.
나의 경우 대고객 서비스가 아닌 내부 동료가 사용하는 어드민 플랫폼을 담당하고 있었기 때문에 '운영팀의 업무 생산성이 정말로 좋아졌는지'까지 생각해야 했고, 실제로 런칭 이후 클라이언트인 유관부서로부터 시시 때때로 받은 피드백을 끊임없이 제품에 반영하느라 무한 수정을 해야 했다.
우선순위/확장성에 대한 고려가 다르다.
서비스 기획자는 일단 제일 빠른 놈부터서비스 기획자는 일단 일어날 수 있는 일들을 Dummy로 쌓아두고, 오래 걸릴 일들을 1·2차로 나누어 재구축할 때로 미루는 경향이 있다. 그리고 1·2차에 대한 우선순위 산정을 '개발 공수'를 두고 하는 경우가 많다.
PMO는 (돈 버는) 빅 픽처를 그려야 한다. 시장과 밀당을 하면서...그러나 PMO는 장기적인 '프로덕트 로드맵' 관점에서 비즈니스 성과를 낼 수 있도록, 지금 하는 개발이 헛되지 않도록 최소한의 MVP만 오픈하면서 시장의 PMF를 확인해야 한다.
이를 머리로는 알고 있긴 하지만, 비즈니스를 만드는 팀이 아니라면 (-특히 사이드 프로젝트 팀-) 개발 우선순위를 정할 때 '빠르게 구현할 수 있는 개발 공수인가'가 될 가능성이 높다. 어쨌든 무보수(열정 페이)로 진행되기에 PMO의 치맛바람(-논리-)도 팀원들의 입김(-자율 의지-)을 이길 수는 없기 때문에 실제 본업을 하면서 틈틈이 구현하는 Maker팀의 리소스도 존중해야 한다.
구라는 아니지만 PM 한 번 믿어 봐... 이게 다 고객을 위한 거라구...'어쨌든 남은 기한 내에 빠르게 타임 어택을 할 수 있는가' 그리고 '기대 효과를 100% 증명할 수 있는지'가 충분히 납득되지 않으면, 개발자/디자이너의 NO, It's busy now 스탠스는 절대 변하지 않았다.
주도성/팀을 설득하는 근거
PMO는 요구사항을 던지는 클라이언트가 없을 수도 있고, 할 일과 비즈니스를 만들어 유관 부서에 협업을 요청해야 하는 경우가 많다. 앞서 말했듯 추후 사업과 프로덕트를 어떻게 성장시킬지 객관적인 설득이 되지 않으면 팀은 움직이지 않는다.
그렇기 때문에 이번 제품 런칭을 통해 어떤 지표가 개선되고, 이는 사용자에게 어떤 영향을 주며, 우리 사업을 어떻게 발전시킬 수 있는지 객관적인 데이터로서 설명할 수 있어야 한다.
여담으로 아래의 사진은 내가 정말 감명받은(...) 한 아이의 아이패드 사달라고 부모님을 설득하는 PPT인데 이거야 말로 (약간의 데이터만 곁들이면) PMO 설득의 정수라고 생각했다. (근데 심지어 70%라고 얼추 계산도 했다) 나는 이 나이 먹고도 무지성으로 조르는데... 또 한 번 반성하게 되었다.
이 친구... PMO 싹수가 노랗다(여기서 약간의 데이터만 곁들인다면 펄펙)총 정리
한눈에 정리하자면 이렇게 말할 수 있을 것 같다. (물론 서비스 기획자라고 설득의 근거가 없는 것은 아니겠지만 업계에서 상대적으로 PMO에게 더 바라고 있는 역할로 이해하면 좋을 것이다.) 이 기준에 따라 회고해보자면, 나의 지난 나날들의 목표는 '버그/오류 없는 제품의 완성'에 가까웠다. 이에 대한 한계를 인지하고 있었고 담당하는 제품을 데이터 기반으로 개선하고 싶었다. 그래서 사이드 프로젝트 팀에서 사업 도메인과 제품 특성을 고려하여 장기적인 관점에서 달성해야 할 핵심 목표를 세우고, 어떤 부분을 개선해야 사용자의 이탈률이 줄어 들 지 고민해보았다. 결과가 나올 때까지는 또 한참의 시간이 걸릴 것이다. PMO의 갈 길은 매우 멀다... ^^.......
영감을 준 콘텐츠
도그냥님은 사랑입니다...(언젠가 검색어로 유입되신다면 하트를 흔들어 주세요...)
https://www.youtube.com/watch?v=9ikuy4fz6uY&t=1s
https://brunch.co.kr/@windydog/560
