세일즈팀은 인센티브제로 고용된 경우가 많다. 그래서 그들에게 시간은 돈이다. 같은 시간이라도 더 많은 고객을 만나고 제품을 팔아야 한다. 장황하게 전후 상황을 동료들에게 꼼꼼히 설명할 시간이 없다. 그래서 그들이 하는 요청은긴박하고 직설적으로 느껴질 때가 많다.
개발팀은 요청이 들어온 것을 어떤 로직을 어떻게 코드로 구성할지 고민한다. 그리고사이드 이펙트는 뭐가 있을지 등 제품이 고장 나지 않게 하기 위해 작은 규모로 보이는 개발에도 신경을 쓴다. 그래서 그들은 보수적으로 움직일 때가 많다.
운영팀은 만들어진 제품을 실제로 사용하고 운영한다. 보편적으로 그들은 제품을 가장 많이 사용하는 실무자들이기 때문에 피부로 직접 체감하는 불편함이 많을 수 있다. 그래서 그들은 디테일에 신경을 많이 쓰곤 한다.
이 외 마케팅팀, 데이터팀 등 팀들마다 보편적으로 도드라지는 화법과 성향이 존재한다. 그렇기 때문에 그들의 대화는 같은 한국말일지라도 의미가 다르게 전달되곤 한다. 프로덕트 매니저는 이런 유관부서들의 튼튼한 오작교가 되어주어야 한다. 즉 좋은 메신저Messenger가 되는 것이 프로덕트 매니저의 역할이라고 생각한다.
그들은 메신저가 필요하다.
만약 세일즈팀이 영업을 위해서 개발팀에게 아래의 요청을 직접 했다고 가정해 보자.
"고객 정보와 고객이 제품을 사용하며 누적된 특정 정보를 연결하여 추출할 수 있는 버튼을 이 페이지에 만들어주세요."
요청을 들은 개발팀은검토를 시작한다. 그들이 원하는 정보를 추출하는 것은 현재의 데이터 구조에서는 불가능하다. 따라서 백엔드 개발자들은 이에 맞춰 데이터 구조를 변경하고 관련된 API들을 만들어야 하며, 프론트엔드 개발자들은 백오피스의 특정 페이지에 버튼을 추가하고 API를 연결해야 기능 구현이 가능한 것으로 검토를 완료했다.
과연 개발팀에게 이 수고를 다 겪어서라도 개발할 만큼 세일즈팀의 요청이 와닿을까? 그렇지 않다. 개발팀은 이 외에도 유지보수와 리팩토링을 포함해할 일이 많다. 그래서 개발팀은 세일즈팀에게 이것이 (지금은) 불가능하다고 말한다.
하지만 리팩토링 등 눈에 보이지 않는 업무들은 세일즈팀에게 개발팀이 자신들의 부탁을 수행하지 못하는 이유로써 와닿지 않는다. 세일즈팀은 뚜렷하게 성과를 내지 못하는 것처럼 보이는 개발팀에게 불만을 가지고 다음부터는 부탁을 자제하기 시작한다.
사실 히스토리를 아는 입장에서는 이 기능이 데이터 구조 변경도, 심지어 버튼을 만들 필요도 없다는 것을 알 수 있었다. 세일즈팀은 영업을 위해 매주 한 번 자신들이 따로 관리하는 시트를 업데이트하기 위해 해당 데이터를 추출하는 기능을 말해달라고 한 것뿐이다. 그리고 이 정보는 이미 데이터팀에서 만들어둔 태블로에 구현되어있다. 심지어 엑셀 추출 기능까지!
결국 간단하게 해결될 수 있는 문제였지만 세일즈팀은 요청에 대한 히스토리를 개발팀에게 잘 설명하지 못했고 심지어 질문할 대상을 잘못 찾았다. 개발팀은 실제로 개발할 필요가 없는 요청이었지만 세일즈팀요청의 본질을 이해하지 못했기 때문에 다른 방법을 찾아보지 않았고, 검토를 위해 시간을 소비했다.
따라서 팀 간 의사소통의 갭을 메꿔주는 역할이 필요하다. 그리고프로덕트 매니저는 이 갭을메꿔줄 수 있어야 한다. 무엇으로? 대화와 글과 문서로!
조용히 있으면 안 된다.
세일즈팀만큼이나 고객을 많이 만나는 직군이 있다. 그것은 바로 프로덕트 매니저다.
프로덕트 매니저는 조용히 있을 시간이 없다. 조용히 있고 싶어도 주위 모두가 가만히 두질 않을 것이다. 사방에서 쏟아지는 다양한 요청들은 협업툴과 메신저를 통해 마구 쌓여있을 것이다.그리고 대부분의 요청자들은 원인과 필요한 결과를명확하게 말하지 못한다. 따라서 프로덕트 매니저는 요청의 기승전결을 정의하기 위해 내/외부로 끊임없이 소통해야 한다. 조용히 있으면 안 된다, 움직이고 떠들어야하지.
프로덕트 매니저로 근무하면 보통 2가지 유형의 고객을 만난다. 하나는 서비스를 함께 사용하며 개선점을 말해주고 나아갈 비전을 공유하는 내부 고객(직원), 그리고 또 하나는 프로덕트에 애착을 가지며 실제 돈을 내고 프로덕트를 사용하는 외부 고객(소비자)이다.
따라서 프로덕트 매니저는 신경 써야 할 일이 산더미다. 직원들이 어떻게 하면 내부 시스템을 통해 더 효율적으로 일할 수 있을지, 그들의 생산성을 어떻게 높일지를 고민하는 일부터 (외부)고객들이 어떻게 우리 서비스를 좋아하고 기꺼이 지갑을 열어주게 만들지, 경쟁사와 비교해 어떤 차별점을 가져갈지 프로덕트에 대한 전방향적인 고민해야 하기 때문이다.
물론 큰 규모의 회사는 모듈별로 나눠서 기획을 하니 기획의 타깃이 더 명확할 수 있다. 백오피스 전담 기획자, 회원/멤버십 모듈 전담 기획자, 결제 모듈 전담 기획자처럼 말이다. 이 경우에는 특정 고객 군에게 더욱 집중할 수 있을 것이다.
(하지만 나는 70명 규모의 스타트업에서 플랫폼의 프론트/백오피스를 혼자 맡게 되며 마음의 편지함이 되어버렸다.)
사실 이 회고 시리즈는 산발적으로 흩어져있던 글들을 찾아서, 살을 더 붙이고 싶은 얘기들로 재구성한 글이다. 얘기하고 싶은 것들을 하나씩 찾아 쓰고, 퇴고하다보니 글이 길어져 3부로나눴다.
