내가 나 자신에게 매일 물었다. 백엔드 프로덕트를 다루는 PO도 프로덕트 전략을 짜야한다. PO가 되고나서 우리 프로덕트팀에 의미있고 빨리 수행할 수 있는 플랜을 짜야겠다는 것은 충분히 학습할 수 있었다.
그래서 몇가지를 고려해야 프로덕트 전략을 짤 수 있다.
회사의 비즈니스 전략
우리 프로덕트의 현재 정확한 상태와 사용자 불편사항
우리 프로덕트팀원들의 태도와 관심사
첫번째는 당연히 회사의 전략이 필요한 프로덕트를 결정하기 때문이다. 그렇다고 요청하는 것을 다 해줄 수는 없다. 항상 입버릇처럼 말하는데 '하고 싶은 것과 할 수 있는 것은 다르다.' 당장 아마존처럼 만들어달라고 말할 수는 있어도, 못만든다. 그리고 기능과 기능 사이에는 선후행 순위가 필요한 경우가 있다. 예를 들면, 상품 컬러 옵션의 추천 기능을 만들고 싶으면, 옵션을 추천할 수 있는 근거 데이터가 될만한 옵션의 추가 정보를 먼저 모으는 개발이 필요하다. 이걸 하나의 프로젝트로 보게 되면 이 프로젝트가 성과를 보는 날은 진짜 먼 훗날이 되어버린다. 이럴 때는, 백로그에 '상품 컬러 옵션 추천'은 다음 분기에 넣고 이번 분기에는 '상품 옵션별 컬러 정보 확보'가 들어가는 것이 목표로서 의미가 있어진다.
두번째로 고려하는 요소는 사용들의 불편사항과 현재 우리 프로덕트의 상태다. 오픈과 임팩트를 위해서 줄여서 개발해놓은 것을 나도 알고, 너도 알고, 모두가 아는 상태일때 이 '생략'한 feature를 개발할 것인가는 VOC가 기준이 된다. VOC가 못살겠다고 할 정도로 빠르게 해결해야하는 일이라면 이것은 꼭 다음 플랜에 넣어야 한다. 그런데 VOC의 경중은 고민이 필요하다. VOC가 들어오긴 하는데 1명만 계속 그렇고 나머지 평균적인 대다수의 사용자들에게 특별히 말이 없다면 정규분포에서 양끝에 있는 사람들이기 때문에 정말 잘 설득해서 미안하다고 후순위라고 해야한다. 안그러면 백로그에 깔려죽기 딱 좋다.
하지만 3번째는 프로덕트팀으로 굉장히 중요한 덕목이다. 이 기준은 프로덕트매니저들의 필독서인 <인스파이어드>의 저자 마티 케이건의 신작인 <empowered>의 번역본이 아직 안나와서 꾸역꾸역 원서로 읽고나서 마음에 남긴 딱 하나다. 협업이란 면에서는 서비스기획자든 PM이든 개발자와 디자이너라는 메이커들과 잘 지내는 법은 굉장히 중요한 현안이었다.
그런데 PO를 하면서 한가지를 더 고민하기 시작했다. '완수하는 것'이 아니라 '정말 제대로 잘 만드는 것'을 하려면 단순히 설득되서 욕하면서 만드는게 아니라, 정말 의미있다고 생각하며 진심을 담아서 작업을 하게 만들어야 한다는 점이다. 이게 진정한 모티베이션이자 스스로 힘을 받아서 만들어가는 프로덕트팀의 중요 덕목이다. 너무너무너무 공감이 가서 그 때부터 메이커들의 한마디 한마디를 수집하듯 주워들으며 그들의 관심사에 맞춰 일을 만들어내려고 노력하고 있다.
함께 토론하기 좋아하는 사람에게는 그렇게 맞춰주고, PO가 상세하게 정의해 오기 좋아하면 그렇게 정의해가고, 지금보다 더 많은 일을 해보고 싶어하면 그 기회를 만들어주고, 다른 범주의 일을 해보고 싶어하면 어떻게든 참여시켜 보려고 하고 있다. 그럴려면 평소에 더 자유로운 대화가 필요하다는 생각이 들었다. 한마디 한마디 지나가는 말도 허투루 듣지 않고 의도와 취향을 이해하려고 노력하고 있다.
이 프로덕트는 아무리 바꾼다고 해도 매출이랑은 직접적 연관이 딱히 없는데,
어떻게 비즈니스 임팩트를 고려하라는 거지?
그런데.. 이 모든 3가지 기준을 뛰어넘어서 잡아야 하는 업무 백로그의 핵심은 '비즈니스 임팩트'였다. 우리의 개발이 단순히 기능 출시를 넘어서 의미있어지려면 이 비즈니스 임팩트를 증명해야 했다. 이 3가지 기준에서 맞지 않더라도 '비즈니스 임팩트'가 높다면 이 업무는 중요한 업무가 된다.
근데 이 단어가 너무나 어려웠다. 대부분의 'sales_driven' 회사에서는 모든 기준이 매출로 흘러가고, 나 역시 이런 것이 익숙했던 것 같다. 성과란 대부분 고객사이드의 프론트엔드에서만 측정이 되었었다. 주문,클레임에서 계속 일해오면서 내가 생각했던 것은 '주문을 획기적으로 전환시키는 것은 상품에 달려있다'는 것이었다. 이것은 주문서에서 단독으로 이겨낼 수 있는 일이 아니었다. 이런 관점에서 백엔드 프로덕트만 다루는 우리의 프로덕트가 단편적으로 매출을 늘리는 비즈니스 임팩트를 만드는 것은 불가능했다.
특별히 엄청난 계기가 있었던 것은 아닌데, 방향을 조금 다르게 생각해보기로 하니까 힌트가 보이기 시작했다. 프로덕트의 사용자와 고객은 다를 수 있다는 것이었다. 사용자만을 생각한다면 나의 프로덕트는 매출과 연계가 없다. 하지만 내 프로덕트의 고객에게 의미가 있다면 최종적으로는 매출을 늘리거나 비용을 줄일 수 있는 가능성을 가진다는 점이었다.
무슨 말이냐면, 우리 프로덕트에 개발을 요청하는 백엔드 프로덕트와 연관된 모든 부서를 고객으로 생각하고, 고객이 요청 하기도 전에 고객이 성과를 낼 수 있는 방향으로 먼저 제안한다면 이것이 내가 만들어낼 수 있는 최고의 비즈니스 임팩트라는 것이다. 이상한 멘트처럼 들리겠지만.
예를 들어서 이커머스에서 셀러가 상품을 등록하는 화면을 생각해보자. 실제 사용자는 셀러다. 하지만 셀러가 상품을 등록하는 것 자체를 내 비즈니스 임팩트로 잡기는 어렵다. 셀러는 입점이 되어야 상품을 등록하고 거기에 종속되기 때문이다. 게다가 셀러를 고객처럼 생각하고 요청사항만 기다린다면, 현재 있는 기능을 쉽게 등록하거나 타사에 있는 기능을 추가해달라는 요청만 받게 된다. 비즈니스 임팩트를 예상하기가 어렵다. 불만을 수정하는 것은 그냥 불만만 줄일 뿐, 만족으로 이끌기 어렵다는 것은 CS업계의 공공연한 비밀이다.
여기서 고객을 셀러가 아니라 셀러 영업을 해오는 팀으로 바꿔보자. 그리고 우리가 먼저 특별한 상품특수한 데이터를 늘리거나, 새롭게 셀러에게 제안해볼 수 있는 영업적인 부분을 찾아낸다. 영업팀에서 특정 카테고리 상품이 전환율이 높다는 발표를 한다면, 그 특정 카테고리 상품을 위해서 내가 할 수 있는 프로덕트적 방법을 더 고려해서 먼저 영업팀에 제안해본다. 그리고 그 제안을 프로덕트 팀원들과 함께 고민해서 방법적인 면까지 완전히 정리해서 진행한다면? 앞서 고려한 모든 기준의 3가지에 충족할 뿐 아니라, 우리가 해낸다는 성취감도 더 높을 수 있다.
정리해본다면, 백엔드 프로덕트에서 비즈니스 임팩트를 서비스 매출로만 연관시키려면 너무나 거리가 멀다. 그리고 요청사항만 수행하다보면 프로덕트팀원들은 질린다. 대부분의 영업부서의 요청은 의지치가 너무너무 크고, 실제 수행했을 때 실패할 확률도 크기 때문이다. 오히려 요청에는 개발적으로 불가능한 방법이 더 많다. feasibility를 체크하기 어렵기 때문이다. 실행에 대한 공감이 없는 상태에서 백로그를 밀어붙이면 프로덕트팀의 의지치는 더 떨어진다. 결론은 프로덕트팀이 더 업무를 주도해야한다.
그러려면 백엔드 프로덕트는 프로덕트의 고객과 사용자를 분리하고, 고객이 충분히 활용할 수 있도록 사용자를 유도하는 뭔가 프로덕트적 개선을 고민하고 제안할 수 있어야 한다. 그리고 그 제안과정에 프로덕트팀을 충분히 끌어들여야 한다고 생각한다. 모두가 의욕적으로 일하면서도 동시에 고객들을 통해서 비즈니스 임팩트를 만들 수 있는 것이 이런 방법인 것 같다. 이것이 백엔드 프로덕트의 '성과'라고 이야기할 수 있는 일이라고 생각한다. (물론 비즈니스 임팩트를 쉽게 만들고 싶다면, 고객 사이드 일을 하는게 편할 수도 있다.)
이 내용은 프로덕트를 리딩하지 않고 프로젝트에 급급한 상태에서는 뭔소린가 싶은 글일 수 있다. 하지만 모든 기획자는 언젠가 프로덕트팀을 리딩해야하는 순간이 온다. 항상 누군가에 요청에 반신반의하며 프로젝트를 하며 살아갈 수는 없다. 지금 프로젝트를 운영하는 기술과 IT의 문법을 익히고 있다면 언젠가 좋은 프로덕트를 이끌어야 한다는 것을 기억하며 팀원들과 지내는 방법들, 더 의미있는 프로덕트를 만들기 위한 방법들에 대해서 고민해봐도 좋을 것 같다.
