사내 ‘완성형 PM되기 스터디’에 참여하면서 글을 읽고, 나누고, 배우는 종합적인 경험을 기록하는 블로그 시리즈입니다.
인스파이어드 책 자체가 얼마나 PM들에게 유명한지는 더 설명하지 않아도 될 것 같다. 그래서 스터디에 참여하면서 이야기 나눴던 주제들을 기반으로, ‘이야기 나눈 주제가 책에서는 어떤 키워드로 언급되었는지’, ‘나는 어떤 의견을 말했는지’, 그리고 ‘스터디에서 어떤 인사이트를 얻을 수 있었는지’ 위주로 정리한다.
우리가 일하고 있는 ‘교육 기반의 프로덕트팀’이 가질 수 있는 안티 패턴은 무엇이고, 어떤 시스템으로 극복할 수 있을까?
안티 패턴?. 책에서는 안티 패턴을 ‘자주 사용되지만 지양해야 할 행동’으로 정의한다. 나는 성장을 방해하는 레거시적인 업무적 행동을 의미한다고 받아들였다. 그런데, 내가 하고 있는 업무적 행동이 ‘어떻게’ 나쁘다고 생각할 수 있을지 궁금했고 스터디에서 그런 안티 패턴에 대해서 속 시원하게 이야기 할 수 있을지 궁금했다.
스터디에서는 다음의 내용이 주요하게 다뤄졌다.
‘결국 우리의 고객은 (예비)수강생 또는 수료생인데, 현재 그들이 공유해주는 이슈 그 자체를 기반으로 다음 행동을 준비하는 업무가 많다.’
나도 일을 하면서 문제를 먼저 정의하고, 그 문제가 우리 고객이 정말 해소하고 싶어하는 것이라면 솔루션을 만들어야 한다 것을 항상 염두한다. 그런 일을 지금 또 하고 있기도 하다. 그렇지만, 어떤 채널을 통해서든, 산발적으로 들어오는 문제 혹은 이슈 그 자체를 해결하기 위해서 고민하고 있던 업무를 내리고 다른 업무에 신경을 분산하게 되는 것도 분명 있다.
이 토론의 중점은 `CS vs CX‘로 이어졌다. 대다수의 성장하는 스타트업이 CS 포지션에서 CX로 그 업무적 바운더리를 넓혀가고 있다. 단순하게 고객의 목소리를 어떤 반대적 산물로 되돌려주는 CS적(Customer Satisfaction) 경험이 아닌, 다음에는 그런 목소리를 전하지 않아도 되는 환경을 구축하는 CX적(Customer Experience) 산물을 만들기 위해서다. 그 이야기를 할 수록, 지금까지 구축하던 솔루션의 대부분이 CS적인 측면에 많이 치우쳐진 나도 모르는 ‘안티 패턴’이 있었음을 알게 되었다.
책에서는 안티 패턴을 방어하는 두 가지 방법을 안내하고 있다. 그 중에서 우리가 겪고 있는 안티 패턴의 극복법 또는 우회법은 첫 번째 내용인, ‘매우 강력하고 목적의식이 강한 문화를 만들고 확실히 자리 잡게 하는 것’을 들 수 있다. 우리가 일하는 방식을 CX적인 산출물을 만드는 것에 집중하는 것이다. 그리고 그런 업무적 인식을 팀 전체의 뿌리러 뻗어갈 수 있게 업무적 시스템을 만드는 것이 필요하다. 그러면서도, 지금 우리가 잘 하고 있는 고객 목소리의 수집을 바탕으로 고도화된 자동화를 통한 데이터 필터링이 다음 (교육) 솔루션으로 산출될 수 있게 업무를 하면 된다.
30명이 넘는 대규모 교육 조직이 과연 제품팀스럽게 일할 수 있을까?
앞서 말한 안티 패턴의 극복을 위해서라도, 우리의 교육팀 전체를 조금더 (책에서 말하는) ‘제품팀’, ‘피자 두 판 규모의 팀’으로 계속 구분해가려는 시도가 더 필요하다. 단순하게 팀원의 규모를 넘어서 ‘비즈니스적으로 매우 어려운 문제를 함께 해달하려는 분명한 목표’를 공유할 수 있는 ‘실행 조직’을 만들어야 하는 것이다. 계층을 이루지 않고도 각자의 위치에서 동일한 솔루션 구축을 목표로 일할 수 있는 조직으로의 개편이 필요할 수 있는 것이다. (그렇게 의사결정이 되어가고 있고.)
최근에 나는 그런 ‘실행 조직’에서 우리 회사의 Core Value 중 하나인 Move Fast and Review, Improve를 경험 할 수 있었다. 문제를 크게 3가지로 정의하고 문제에 맞는 솔루션을 기획 후 1달 이내로 3개의 프로세를 모두 배포했다. 매일 9시-10시 가까이에 퇴근하면서도, 솔루션에 대한 목표의식이 강해서 즐겁게 일할 수 있었다. (엄청 한숨을 많이 쉬긴했다. ) 그래서 더욱, 우리팀이 이렇게 ‘실행 조직’으로 변모할 수 있겠다는 생각이 강해졌다.
분명 교육과 관련된 제품을 만드는 팀이 반드시 ‘제품팀’으로 가야하는 것이 아닐 수 있다. 그렇지만 우리의 팀은 팀에 주어진 ‘일의 범위’와 ‘일의 유형’을 각기 다른 고객 여정을 기반으로 나누려고 한다. (물론 내가 정하는건 아니지만) 우리 프로덕트의 고객 여정 한 사이클이 기타 다른 일반적인 IT 프로덕트와는 차원이 다르게 길기 때문에 제품별(=고객 여정별) 팀 분리는 또다른 안티 패턴 방지를 위해서 필요해 보인다. 지극하게도 나의 의견이다.
함께 스터디에 참여하고 있는 우리 팀, 타 부트캠프팀 크루들의 동의를 얻고 (모자이크를 할 줄 몰라서 그냥 박스로 가림) 스터디 장면을 캡쳐하여 올린다. 모두들 2시간이 어떻게 흘러가는지 모를 정도로 즐겁게 자신의 의견을 높이고 스터디원의 의견을 경청했다. 😎
