by
Dec 01. 2021
다른 직군에서 PM/서비스기획자가 되었을 때
TIP: 엔트로피의 법칙과 정규분포를 떠올리자
요즘 이커머스에 대한 관심과 온라인 플랫폼 기획에 대한 관심이 높아지면서 다양한 사람들을 대상으로 강의를 할 기회가 늘어가고 있다. 주변에는 다양한 직무에서 이 직무로 넘어오는 사람들이 많아지고 있다. 지금까지 10년 넘게 서비스기획 직무만 해온 나에게는 그렇게 넘어온 분들에게서 배울 점도 많지만 그 분들이 겪는 문제점들을 들으면서 서비스기획 직무와 다른 직무의 고민 포인트에 대해서 이해를 넓히기도 하게 되기도 한다.
개발, 디자인을 제외하고 프로덕트팀이 소위 '현업'이라고 부르는 타부서에서 서비스기획직군으로 넘어오는 이유 중에 가장 큰 하나는 '답답함'이다. 프로덕트에 깊게 관여하지 않는 상태에서 뭐든 말만하면 '안되요'라고 말하는 저 꽉 막힌 존재들의 그 이유를 알고 싶어서이기도 하고, 우리 프로덕트팀이 일을 못하는 게 아닐까하는 의구심에 직접 와서 그게 뭔지 파악하고 직접 개선해보고 싶은 마음을 가지고 오는 경우들이 있다.
두번째 이유는 '재밌어 보이기'때문이다. 뭔가 척척 만들어내는 그 모습에 매번 단조롭게 같은 일을 해야하는 경우라면 더더욱 프로덕트 직무로 옮겨보고 싶어한다. 그리고 밖에서 보기엔 원하는거 막 슥슥 정리하면 개발자와 디자이너가 다 하니까 쉬워보인다는 사람도 아주 간혹 있다.
두가지 모습은 사실 모두 사실이다. 재밌는 직무임에도 맞고, (좋은 협업 환경이라면) 개발자와 디자이너가 척척 해주는 것도 사실이고 게다가 속시원히 '안된다'고 말할 수도 있는 몇 안되는 조직중 하나로 보일 수 있다. 그런데 막상 직무를 건너오게 되면 다른 조직에서 보이지 않던 부분들에서 너무 어려움을 느낀다고 토로한다. 그리고 더욱이 기존의 일하던 사고방식과 다른 점들때문에 혼란을 겪기도 한다.
직무전환 후 어려움
이번에는 내 주변의 여러 직무에서 프로덕트팀으로 넘어오신 분들에게 들었던 어려움들을 정리해봤다. 흔하게 넘어오는 디자이너와 개발자는 제외했다.
1. 마케터
- 이벤트나 프로모션 등 준비에서 개발팀과 협업하는 경우가 많다보니 가장 많은 사람들이 마케터에서 서비스기획 직무로의 이동을 꿈꾼다. 그런데 막상 실제로 이동하는 경우가 가장 적은 경우가 많다. 마케팅은 항상 일손이 부족해서 사내에서 직무이동을 잘 안시켜 주기도하고, 신입으로 어디 입사하려고 하면 전직 준비가 쉽지 않다고 입을 모아서 말하고는 한다.
- 마케터의 경험이 주는 장점 : 프로덕트의 비즈니스 임팩트나 얼마나 사람이 직접 관여해야하는가나 비용에 대해서 굉장히 셈이 빠르고, 트렌드에 강한 편이고 타사의 서비스나 상품도 자주 관찰하는 좋은 눈을 가지고 있어서 아이디어의 제안이나 현업과의 소통 시 공감대 형성이 탁월하다.
- 마케터의 경험이 주는 어려움 : 마케터로의 경험은 '부분최적화의 끊임없는 고통'이었다고 설명을 들은 적이 있다. 내 맘대로 시스템을 바꾸지 못하니까 이미 주어진 환경내에서 할 수 있는 일을 하면서 매출 실적에 대한 압박을 오랜기간 받아왔기 떄문에 '언젠가 한번 활용하면 좋을 케이스'에 대해서 개발범위에 집어넣고 싶어한다. 나중에 개발요청하는 것이 얼마나 어려운지 잘 알기 때문이다.
2. MD와 오퍼레이터
- 영업MD과 오퍼레이터 역시 마케터와 비슷한 이유로 이 직무로 넘어오고자 한다. 하지만 마케터보다 실제 개발 프로젝트에 참여했던 경험이 적기 때문에 개발자 커뮤니케이션 부분에서 두려움도 높고 실제 진입장벽도 높다고 생각한다.
- 이전 직무 경험이 주는 장점 : 영업직무와 오퍼레이터 직무의 가장 큰 공통점은 '고객의 소리를 가장 가까이서 들었다는 점'이다. 내가 <코딩 몰라도 됩니다>라는 책에서 이야기했었듯 이커머스의 영업은 구매와 소싱이라기보다는 셀러와의 관계관리가 중요해졌고 오퍼레이터는 고객의 소리를 직접적으로 반영하며 거버넌스 관리 주체가 되어가고 있다. 때문에 특별히 사용자조사를 하지 않고도 사용자가 누구이고 어떻게 사용하며 무엇이 불만인지 알고 있다. 이는 엄청난 도메인 지식이자 큰 장점이다.
- 이전 직무 경험이 주는 단점 : 셀러를 대하는 조직의 공통적인 요청은 '일괄처리'와 '자동화'다. 구매 사용자를 다루는 조직이 가장 많이 듣는 것은 '특수케이스의 처리 요청'이다. 예를 들어 셀러는 상품등록부터 주문처리까지 일괄로 하고 셀러의 주문이 조금 늦더라도 취소되지 않을 온갖 다양한 방법을 원한다. 이 쇼핑몰만 운영하지 않기 때문에 극단적 효율과 매출 보장을 원한다. 오퍼레이팅 조직 중 고객센터 조직의 경험은 뭔가 정책구조보다는 원하는 최종상태에 집중된다. 교환중 반품으로 전환해달라거나 주문배송중 취소요청과 같은 까다로운 예외처리를 필요하다고 느껴서 수정해야지 한다. 하지만 곧 부딪히는 개발의 복잡한 설명은 역시나 안된다는 것이다. 심지어 이제는 기존 본인의 직무자들에게 안된다는 것을 설명해야하는 입장이 되어버리니까 더 답답하고 어렵다고 한다.
3. 회계, 전략부서
간혹 정산프로덕트에 회계담당자가 직접 오거나 전략부서에서 넘어오는 경우도 있다. 이유는 좀 다르다. 회계쪽은 직무 이해도가 높아야해서 필요한 것을 직접 기획하거나 지식때문인 경우가 많고 전략은 생각한 것을 직접 만들어내고 싶어서 넘어오는 경우가 많다. 전략기획자들의 평소 아쉬움들이 높기 때문이다. 용을 그려놨더니 뱀도 아니고 지렁이같은 산출물이 나온 기본이 들 때가 있는데 이유도 모르겠고 잘 나온다고 해도 '내것이 아닌 기분'이 들 때가 있다고 한다.
- 이전 직무가 주는 장점 : 비즈니스적으로 넓게 멀리 볼 수 있어서 앞으로 나아가야할 방향과 회사 전략적인 부분과 얼라인먼트를 잘 할 수 있다. 게다가 현업 소통능력도 높고 지원그룹 특성상 문서 처리도 능해서 여기저기 프로젝트를 잘 드러내기도 한다.
- 이전 직무가 주는 단점 : 전략 출신은 오픈 후 성과나 오류에 많이 당황한다고 한다. 전략기획은 상위레벨이기에 파지티브한 계획을 주로 하게된다. 대부분 오픈 후 겪는 자잘한 문제에 대해서 많이 패닉하거나 앞서 프로젝트 진행시 낙관하다가 크게 당황된다고 했다.
실무적인 일을 하던 회계 출신의 지인은 오프라인 업무는 다 머리속에 그려지는데 온라인 프로덕트적인 것은 하나도 떠오르지 않아서 고민스럽다고 했다. 전문지식이 더 강하게 작용하기 때문으로 보였다.
프로덕트매니저로 직무 변경시 기억해야할 것들
공통적으로 겪는 가장 큰 문제는 '개발 요청을 조절하는 것'에 있다. 개발과의 의사소통이나 시스템의 이해, UX의 이해는 프로젝트 운영에 필수적이지만 더 중요한 것이 남아있다. 프로덕트 매니저의 핵심은 '만들어내는 것'이 아니라 '관리해내는 것'이 있다는 점이다.
겉을 보기보다 시스템은 물리적이라 물리의 법칙이 작용한다. 개발해서 추가하는 '작용'을 하면 '반작용'이라는 오류나 온갖 영향범위에 대한 의사결정이 따라나오는 것은 당연하다. 생각한 것보다 고구마 줄기보다 더 심하게 따라나온다.
그치만 무엇보다도 떠올려야할 것은 '엔트로피의 법칙'이다. 열과 성을 다해서 에너지를 기획에만 뿜어대면 시스템 복잡도라는 엔트로피는 급격히 증가하고 더 빠르게 해내라고 할수록 기술부채가 쌓여서 엔트로피는 더 빠르게 증가한다. 엔트로피가 증가하면 불확실성이 높아진다. 개발후 예상도 못한 결함이 넘쳐날 수 있다.
기획자는 하고 싶은거 다 하는 사람이 아니라 중요한 것을 골라서 순서를 주는 사람이다. 이 안에서 인적자원의 심리적이고 물리적인 소진을 막는 것도 중요한 임무다. 그렇다고 요구사항을 다 걷어차란게 아니라 필요한만큼을 정확히 예상하는 연습이 필요하다. '쓸 수도 있을 법한 것' 또는 '있으면 더 좋을 것'들에 대한 객관적인 고민이 필요하다. 안그러면 정말로 엔트로피가 지나치게 증가해서 정말 건들면 오류나는 경지에 이르러서 손도 못대게 될 수도 있다.
그리고 두번째로 생각해야할 것은 경험에 대한 의존도를 낮춰야한다는 점이다. 현업의 경험은 사용자의 경험이지만 개인의 경험 혹은 일부 가장 거친 집단의 경험을 지나치게 일반화하는 것에는 무리가 있다.
나의 경험은 전체 사용자의 대표성을 띠는가?
내가 아는 사용자는 대표성이 있는가?
서비스는 확률의 정규분포 그래프에서 가장 높이 솟은 중앙을 기준으로 해서 다수의 고객에게 맞춰야 한다. 회사에 속해서 매일 보던 나는 표준 고객과는 거리가 멀고 클레임이 심한 고객도 표준 고객은 아니다.
'비즈니스 임팩트'를 고려하는 것도 중요한데 가장 다수의 고객에게 좋은 효과를 일으키는 것이 더 효과가 높은 경우가 많다. 핵심은 여러가지 고민을 할 때 객관적이어야한다는 것인데 데이터가 중요한 이유가 바로 여기서 출발한다.
요청자나 지시자가 아니다.
PM은 동료이고 지휘자다
