부트캠프 수강생을 대상으로 멘토링 또는 포트폴리오 피드백을 할 때 자주 마주하는 아쉬운 부분이 몇 가지 있다. 그중 하나가 지표인데, PM을 지망하는 분들이 지표에 대해 여전히 일종의 환상(SQL이나 Python을 배워야 하나요 등) 있는 반면, 그 환상에 가려 정작 중요한 실체를 잊고 있기 때문이다.
주로 매출액, 페이지뷰, 사용자 수, 유입률 등이 프로젝트의 성공의 정의 또는 KPI가 되곤 하는데, 몇 가지 간단한 질문에 대답하지 못한다. 분명 수업에선 강사님이 선행지표니 후행지표니 SMART지표니 하는 개념을 설명했지만 아직 와닿지 않을 테고, 방안 구상에 빠져 지표는 깊게 고민하지 않았기(못했기) 때문일 테다.
지표란 무엇인가? PM에게 왜 중요한가?
지표(index)란 어떤 추상적인 현상, 상황을 드러내는 기록이다. 조금 더 구체적으로 표현하면, 알고 있지만 타인에게 설명하거나 전달하기 어려운 현상, 상황을 포착하여 고정된 형태로 기록해 낸 자료이다. 세상을 이해하는 수단이자, 증명하는 수단이다.
PM에게 지표가 중요한 이유는 궁극적으로 세 가지다.
1. 문제를 발굴하기 위해서
2. 문제의 실체를 (재)정의하기 위해서
3. 가설을 검증하기 위해서
왜냐하면 PM의 일이란 본질적으로 프로젝트 관리, 화면/정책 설계가 아니기 때문이다. 이는 일이 돌아가게 하기 위한 부수적인 작업 또는 세부 과제 중 하나일 뿐이다. (단, 프로젝트 매니저나 외주 기획자라면 예외. 이들에겐 일정 관리와 정책 설계가 고객이 원하는 바요 계약의 핵심이다.)
PM의 일은 결국 시장에 존재하는 고객의 문제를 발굴하여 정의하고, 이를 해결할 것으로 추정되는 방안을 구상 및 설계하여, 이를 수행한 후 결과를 통해 해결여부, 즉 가설을 검증하는 것이다. 그리고 이 과정을 논리적이고 객관적으로 진행하기 위해 지표가 존재한다. 특히 통찰 또는 감으로도 문제를 발굴, 정의할 수 있지만 검증은 불가능하다.
어떤 지표를 봐야 하는가?
그럼 PM은 어떤 지표를 봐야 하는가? 제품에 따라 수많은 지표가 있겠지만 궁극적으로는 고객의 문제를 해결했음을 증명할 수 있는 지표, 또는 고객이 문제 해결을 위해 제품과 상호작용하는 과정에서 남긴 행동이다.
(또한 앞서 말했듯 지표란 어디까지나 현상을 포착한 결과물일 뿐이므로, 제품을 통해 고객이 성공한 모습, 혹은 Before에서 변화한 After의 모습이 뚜렷할수록 지표를 정의하기 좋다)
당장에라도 법정에 선다고 생각해 보자. 판사가 묻는다."ㅇㅇㅇPM 씨, 당신의 고객에게 정말로 가치를 제공했습니까? 문제를 해결한 게 맞습니까? 고객의 돈과 시간만 탐한 건 아닙니까? 이를 어떻게 증명하시겠습니까?"
제법 규모가 자리 잡은 조직이라면 분석가가 변호사로 함께하겠지만, 스스로를 변호하고 증명할 제1의 책임은 PM 스스로에게 있다.
그런 관점에서 우선은 고객에게 직접 묻는 만족도(CSAT) 나 추천지수(NPS) 등이 증거가 될 수 있다. "이것 보십시오 판사님, 고객이 이렇게나 만족한다고 하고 또 주변에 추천도 한다고 합니다. 제품이 엉망이었더라면 과연 가당키나 했겠습니까?"
그러나 고객의 말은 누락과 왜곡에 취약하다. 불만족한 이들은 응답도 없이 이탈하기 마련이고, 리뷰 상단에 노출되라며 일부로 가장 높은 만족도 점수와 함께 불만족 사유를 길게 적는가 하면, 의도적으로 리뷰 테러를 하는 이들도 있기 마련이니까. 그래서 판사는 다시 묻는다. "추정할 순 있지만 아직 부족합니다. 다른 증거는 없습니까?"
그래서 고객의 행동이 등장한다. 제품이 문제를 해결했자면, 그래서 만족했다면 자주 오겠지, 만족했다면 또 오겠지, 만족했다면 오래 머물겠지,.... 하는 추정을 하는 셈이다. 물리적 법칙, 증명된 인가관계가 있는 건 아니지만 상식적인 수준에서의 추론을 통해 혹은 뛰어난 변호사(분석가)가 있다면 상관관계를 통해 증명할 수 있는 행동의 기록들.
"이것 좀 보십시오 판사님, 현장에 남은 고객의 흔적입니다. 이 족적과 동선을 보면 필시 제품이 만족스러웠다는 걸로 볼 수 있지 않습니까?"
지표, 판사 앞의 최종 변론
다시 말해 PM이 봐야 할 지표는 고객의 말과 행동을 통해 정말로 나의 제품이 고객의 문제를 해결했음을 증명할 수 있는 지표다. 고객의 답변이든 그들이 인지하지 못하고 남긴 기록이든.
이에 부합하지 않으면, 몇 번의 질문으로 쉽게 반박될 수 있는 지표일 가능성이 높다. 허상지표며 후행지표고 제품의 문제해결과 본질적으로는 무관하다. 예컨대 사용자 수와 유입률은 마케팅을 통해 단발성으로 조작할 수 있으며, 전체 사용량은 일부 사용자에 의해 왜곡될 수 있으며, Saas 제품의 도입률은 세일즈 담당자의 간곡한 노력으로 잠시 개선된 듯 보일 수도 있다. 이런 지표를 근거로 들이미는 순간 판사의 양형 사유를 듣고 말게 된다. "탈락. 피고인은 고객의 문제를 해결했음을 검증할 책임이 있음에도 불구하고 이를 드러내는 합리적인 지표에 대한 고민의 흔적이 보이지 않음."
잊지 말자. 지표는 PM에겐 최종 변론의 증거물임을. 그 책임은 변호사(분석가)가 아닌 스스로에게 가장 먼저 있음을.
덧붙임1. 사용자 수나 매출액도 봐야하지 않느냐는 질문 역시 자주 받는다. 고객 문제를 해결하지 못하는데 사용자 수가 늘고 매출액이 느는 제품이 있을까. 거청하게 제품을 논할 팔요 없이 동네 미용실, 골목길 떡볶이 가게부터 통하는 논리다. 투자금을 이용한 무리한 마케팅으로 한 철 유입을 만들 순 있을지도 모르지만.
덧붙임2. 그런 관점에서 PM에게 필요한 데이터 능력이란 나의 두루뭉실한 가설을 명확히 만들고 이를 지표로 추상화&구체화할 수 있는 능력이다. SQL, Python이 아니고. 전자가 있다면 후자는 사람에게든 생성형AI에게든 부탁하면되지만, 반대는 아무 소용이 없다.