성공을 정의하다, 성공을 측정하다
* 2018년 12월에 Brunch에 쓴 글입니다.
누구나 성공하고 싶다. 누구나 성공적인 제품(product)을 만들고 싶다. 그런데, ‘성공’이 무엇일까? 바로 이 ‘성공’을 정의하는 게 '비전 설정(이전 글)'과 함께 모든 제품의 시작이라고 생각한다.
무언가 ‘만드는 것’은 쉽다. 개발자/디자이너들의 노력을 평가절하 하는 건 아니다. 하지만 회사에서 일을 하다보면 이걸 ‘왜’ 만들어야 하는지에 대한 고민은 깊게 하지 않는 경우가 많다. 사실 모든 제품은 이 ‘왜’에서 시작한다. 그게 호기심 에서든, 아니면 고객의 불편함을 해결하는 것이든, 아니면 단순히 돈을 벌기 위해서이든. 그 ‘왜’가 단순히 무언가를 만들고 싶어서인 경우를 제외하고는, 보통 돈을 더 벌거나(매출을 늘리거나), 인간의 삶을 더 편리하게 하거나, 어떤 일을 더 편하게 수행할 수 있도록 하는 게 목적일 것이다. 그리고 비영리단체나 공공기관을 제외한 대부분의 비즈니스는 결국 수익을 더 내는 게 최종 목표일 것이다.
그럼 ‘수익을 많이 내는 것’이 회사에서 일하는 각 개인이나 팀의 ‘성공’일까? 회사 전체나 영업 조직 입장에서 보면 최종 outcome이 ‘수익’이 되어야 함은 맞다. 하지만 영업이나 마케팅 조직을 제외하고선 본인들의 노오력이 수익으로 얼마나 이어지는 지에 대해 측정하기란 어렵다. 예를 들어 ‘디자인팀’의 KPI(핵심 성과 지표)를 ‘매출(수익)’으로 잡는다고 해서, 좋은(혹은 나쁜) 디자인이 매출에 얼마나 영향을 주는 지에 대해 측정하는 것은 굉장히 어려울 것이다. 그럼 각 팀들은 어떤 식으로 ‘성공’을 정의하고 어떻게 ‘측정’해야 할까? 아니 그것보다 왜 성공을 정의하고 측정해야 할까?
왜 일을 할때 ‘성공’의 정의와 측정이 중요할까?
결론부터 얘기하자면 이 일을 “왜” 하는지에 대한 공감대를 형성하고, 실제 우리가 한 일의 결과가 "회사나 고객에게" 어느 정도 영향을 미쳤는지에 대해 측정하고 평가하기 위함이다. 이는 개개인의 Motivation과도 연관이 있다.
예를 들어 보자. 내가 결제 개발팀에서 일하고 있다고 치자. 이미 결제 SW는 잘 돌아가고 있다. 왜 회사에선 이 개발자를 계속 고용하고 있어야 할까(팀의 존재 이유는 뭘까)?
여러가지 이유가 있을 수 있다. 새로운 결제 수단을 제공하고 싶을 수도 있고, 단순히 현상 유지만 하고 싶을 수도 있고, 아니면 기존 고객의 결제 경험을 개선하고 싶을 수도 있다. 회사의 전략이나 가치관에 따라, 상황에 따라 다른 이유가 있을 것이다. 이 ‘이유’가 중요하다. 만약 그냥 현상유지만 하고자 한다면, 최대 목표는 결제 시스템이 안정되게 돌아가는 것일 것이다. 그럼 ‘성공’은 결제 시스템이 1년 동안 장애없이 돌아가는 것이라고 할 수 있고, 이걸 성취했는지는 장애율(%)이나 장애시간 등으로 측정할 수 있을 것이다. 반면, 고객의 ‘결제 경험을 개선’하는 게 주요 목표(개발팀을 두는 이유)라면, 고객의 결제 성공율이나 결제 관련한 고객센터 문의/불만 건수 등으로 ‘경험’의 질을 측정할 수 있을 것이다.
이렇게 “내가 하는 일이 회사 혹은 고객에 어떤 영향을 미쳤는지”를 측정할 수 있다는 것은, 팀의 존재이유 뿐 아니라 조직 구성원 개개인의 성취감에도 영향을 미친다. 당연히 비즈니스 지표가 좋아지거나 고객의 만족도가 높아진다면, 구성원의 성취감도 높아질 것이고 평가에도 좋은 영향을 줄 수 있을 것이다. 반면 지표가 나빠지거나 개선이 더디다면 반대의 결과가 있을 수 있지만 최소한 무언가 ‘배울 수는 있다’고 생각한다. 어떤 지표 A를 개선시키기 위해 B라는 노력을 했는데 개선이 되지 않는다면, B가 과연 맞는 해결책이었는지 회고해보고, 그 안에서 무언가 배우고 좀 더 개선된 B’ 라는 해결책을 시도해 볼 수 있다.
하지만 ‘성공의 척도’가 없거나 애매하다면 어떨까? 밤을 새서 일을 했는데, 내 노력이 회사/고객에 어떤 영향을 미쳤는지 알기가 힘들 것이다. 성공도, 실패도, 배움도 없다. 좀 과장하면 출근했고 그냥 일을 해야 하니까 일을 하는 것 아닐까?
어떻게 성공을 정의해야 할까?
성공을 정의하는 법은 쉬워보이지만 사실 쉽지 않은 경우도 많다. 이미 조직이 정해놓은 이루고자 하는 방향이 있다면 쉽게 시작할 수 있다. 예를 들어, ‘우린 고객이 얼마나 결제를 쉽게 끝마쳤는지를 나타낼 수 있는 결제 성공률을 제 1 지표로 사용할거야. 결제 수수료를 내리는 것도 중요하지만 우선은 고객의 불편함을 해소하는 게 우선이야’ 라고 조직이 방향을 설정해 놓은 경우다. 하지만 새로 시작하는 조직이나 새 제품의 경우는 어떨까? 이때는 우선 내가 ‘이루고자 하는 바’, ‘성취하고자 하는 바’를 확실히 하는 것부터 시작해야 한다. 예를 들어, 내가(우리 팀이) 이루고자 하는 게 "(우리 온라인 호텔 웹사이트를 통해) 아이를 동반한 가족여행 예약 경험을 개선하는 것”이라고 우선 정의를 하는 것이다.
이후에 항상 따라오는 질문은 ‘그럼 예약 경험을 개선했다는 걸 어떻게 측정할까?’이다. 이는 상황마다 다르고 회사나 조직의 비젼에 따라도 다를 것 같다. 최종적으로 숙소 예약을 무사히 끝마쳤는지를 보는 ‘예약 성공률’을 척도로 삼을 수도 있고, 아이를 가진 고객을 대상으로 만족도 조사를 해서 개선여부를 확인할 수 있을 수도 있다. 어느 지표를 사용하던 ‘내가 이루고자 하는 바’를 가장 잘 나타내는 지표를 찾아내면 된다. (솔직히 이 부분이 가장 어려운 경우도 많다)
그리고 위의 주요 지표 외에 내가 손해보지 말아야 할 부분(리스크를 감수할 수 없는 부분)이 있는지도 생각해봐야 한다. 예를 들어, ‘아이를 동반한 가족의 숙소 예약 성공률’를 높이는데 성공했다 하더라도 만약 ‘전체 고객의 예약 성공률’이 낮아진다면 어떻게 할까? 아이/가족 관련한 UI를 수정하다가 일반 고객의 경험에 해를 끼칠 수도 있다. 이런 결과가 생긴다면 아마도 회사 전체로서는 손해일 것이고, 팀의 주요 지표는 상승했겠지만 이를 ‘성공’이라 보긴 힘들 것이다. 이것처럼, 성공을 정의하고 측정 지표를 생각해 볼 때, 내가 손해를 감수할 수 없는 부분에 대해서도 함께 생각해봐야 한다. 이 부분을 제대로 짚고 가지 않는다면 나중에 팀이 프로젝트/기능 개선의 산출물의 성공여부를 측정할 때 문제가 될 수 있다.
이번 글에서 풀어놓은 얘기는 사실 내가 1년 동안 팀원들과 좌충우돌하면서 배운 내용이다. 내가 현재 회사에서 담당하고 있는 제품은 고객 측면이 아닌 숙소 관리자(호텔리어나 Airbnb 식 숙소의 호스트)들이 사용하는 Mobile app이다. 하지만 ‘주문을 성공적으로 마쳤느냐’, ‘숙소를 성공적으로 예약했느냐’와 같이 확실한 고객 측면의 ‘성공’과는 달리, 숙소 관리자 측면의 ‘성공’은 정의하기가 더 어렵다. 우리 사이트를 통해 더 많은 숙소 예약을 받는 게 최종 목적이겠지만, '내 제품(Tool)'이 정말 좋아서 더 많은 예약을 받았다고 쉽게 판단하긴 힘들다. 변수가 워낙 많기 때문이다. (여기서 상세한 설명은 생략하겠다)
결국 '예약 성공률', '주문 성공률' 등의 주요 지표를 사용하기 힘들고, 어떤 '문제'를 해결할 때마다 그 문제에 따라 다른 지표를 사용해서 성공을 측정해야 한다. 그러나 매번 팀원들과 고민해서 지표를 뽑아내기도 힘들고, '이 지표가 좋아진다는 게 정말 이 문제를 해결했다는 건지'(내가 맞는 측정지표를 찾아낸 건지) 등 확실하지 않은 게 한 두 가지가 아니다.
이런 내 개인적인 상황이 '성공'을 정의하고 측정하는 게 얼마나 중요하지만 어려운 것인 지 생각하고 글을 쓰게 되는 계기가 되었다. 아직도 어려움을 겪고 있는 상황이지만 한 가지 배운 게 있다면, 어떤 제품을 만들던, 문제를 해결하던, 내가 이루고자 하는 바를 우선 정의하고, 측정지표까지 확실히 설정하고 (팀원들도 이해하고 동의해야 한다) 일을 시작해야, 나중에 내 솔루션(결과물)이 무언가 개선했는지 혹은 문제를 해결했는지 알기가 쉽고, 이는 팀의 생산성 뿐 아니라 동기부여에도 영향을 준다는 것이다.
