PM에게 필요한 데이터 능력은 어디까지일까?
PM에게 필요한 적정 데이터 능력
데이터, 알면 좋은 것과 알아야 하는 것
몇 년째 너도 나도 데이터를 외치고 있다. 데이터 리터러시가 필요하다, 데이터가 없으면 일을 하지 말라, 데이터 드리븐 한 의사결정을 하라 등등... 그리고 어떤 이들은 "아직도 000 안 배웠니?" 또는 "000라면 ㅁㅁㅁ는 할 수 있어야지"라는 식의 문구를 내세워 불안 심리를 자극하고, 유행하는 각종 기술 또는 개념을 배울 것을 종용한다.
그리고 이러한 유행 내지는 불안 심리는 기획자 또는 PM을 준비하거나 이제 막 이 직무에 들어선 이들에게도 여지없이 찾아오고, 이들의 우려 섞인 질문들을 곳곳에서 찾아볼 수 있다.
"기획자가 되려면 데이터를 얼마나 해야 하나요?"
"문과생인데 데이터 공부하면 따라잡을 수 있을까요?"
"R을 해야 하나요 Python을 해야 하나요?"
"머신러닝부터 배우면 될까요?"
"통계도 배워야 하나요?'
물론 무엇이든 원론적으로는 알아서 나쁠 것은 없다. 우리 모두는 교양인이기에 인문학을 알면 좋고, 우리 모두는 자본주의 체제에 살기에 거시경제와 미시경제를 두루 알면 좋다. 우리 모두는 언젠가 위급상황에 처할 수 있기에 응급구조부터 전시 대피 요령을 익혀두면 좋고, 우리 모두는 한민족이기에 역사를 알면 좋으며, 우리 모두는 IT 서비스에 둘러 쌓여 살기에 컴퓨터 공학에 대한 기초적인 이해를 알면 좋다.
그러나 우리의 시간은 늘 한정되어 있기에, '알면 좋은 것'과 '알아야 하는 것'은 다를 수밖에 없다. 그리고 이는 기획자 혹은 PM에게도 마찬가지다. 이 일을 하기 위해 알아야 하는 것과 알면 좋은 것은 엄연히 다르다.
기획자, PM이 하는 일과 데이터
그럼 서비스 기획자 혹은 PM이 갖춰야 할 데이터 능력은 무엇일까?
이를 정의하기 앞서, 대체 서비스 기획자 혹은 PM이 하는 일이 무엇인지를 정의해보자. 그리고 이를 정의하기 위해 아래와 같이 생각을 펼쳐나가 보자.
1. 모든 제품/서비스는 고객의 문제를 해결하기 위해 제작 및 제공된다.
2. 제품/서비스를 담당하는 기획자, PM 역시 고객의 문제를 해결하기 위해 일한다.
3. 다만 우리는 고객을 사전에 100% 알 수 없으니, 언제나 늘 예측할 뿐이다.
4. 예측이 사실인지 확인하기 위해 각종 조사와 실험을 진행하거나 제품을 출시해 반응을 살펴본다.
5. 예측과 실제를 비교하기 위해 조사 및 실험 결과와 제품 내 지표를 살펴본다.
쉽게 말해 서비스 기획자 또는 PM이 하는 일이란 단순하게는 고객에 대한 가설을 세워 이를 검증하는 게 전부다. UX/UI, 세부 정책 정리 등의 테스크는 모두 이를 위한 과정 중 일부에 지나지 않는다.
그리고 위의 맥락에서 기획자, PM이 데이터를 배우는 이유는 '빅데이터가 유행이라서', 혹은 '요즘엔 데이터가 대세라서'가 아니라, 오롯이 아래의 이유에서 출발해야 한다.
1. 어떤 데이터를 수집, 추적 tracking 해야 내가 세운 가설을 확인할 수 있을지 검토 및 설계하기 위해서
2. 수집된 데이터 중 무엇을, 어떤 기준으로, 어떻게 봐야 내가 세운 가설의 결과를 올바르게 확인할 수 있을지 이해하기 위해서
3. 실제로 수집된 데이터를 데이터 분석가 또는 개발자에게 요청하지 않고 빠르게 확인하기 위해서 (혹은 그런 사람이 팀에 없어서..)
4. 검증된 결과를 팀과 이해관계자에게 쉽게 또는 제대로 공유하기 위해서
데이터와 관련하여 PM이 하는 일과 필요한 데이터 능력
그럼 구체적으로 PM은 데이터와 관련하여 무엇을 알아야 할까?
물론 이는 당연히 조직마다, 팀마다 다를 것이다. AI 제품의 설계를 다루는 PM과, 외주로 웹페이지 구축을 담당하는 서비스 기획자와, 일반 B2C 제품을 다루는 PM에게 필요한 '데이터'에 대한 이해와 역량은 다를 수밖에 없다.
다만 인서비스를 다루는 PM이라면 공통적으로 아래의 일들을 리딩 하거나 참여하게 될 텐데, 각각의 테스크에서 필요한 데이터 능력이 요즘 이야기하는 '머신러닝' 또는 '빅데이터'의 범주는 아닐 것 같다.
1. 설문조사, 인터뷰 ▶ 인사이트를 위한 비율 정도만 알면 된다 (00명 중 00명)
2. UT ▶ 정성적 적근이므로, 인사이트를 위한 비율 정도만 알면 된다 (00명 중 00명)
3. A/B 테스트 ▶ 통계적으로 유의미한지 확인하기 위한 지식들 (P-value 등. 그마저도 Google Optimize는 베이지안 기법으로 p-value를 취급하지 않아 필요 없다.)
4. 단발성 이벤트 ▶ 오픈율, 클릭률 등의 비율(%) + 이걸 심기 위한 UTM작업
5. 제품 데이터 집계를 위한 세팅 ▶ GTM 등
6. 제품 데이터의 확인, 분석 ▶ 가설 수립과 약간의 데이터 리터러시
특히 A/B테스트의 경우 자체 테스트 플랫폼을 지닌 조직이 아닌 이상 Google Optimize 등을 사용할 텐데, 아래 고객센터의 설명과 같이 Optimize는 흔히 말하는 양측/단측 검정에서 유의 수준α과 기각역(1-α)을 설정하고, 유의 수준 p-value를 확인하는 식으로 접근하지 않는다. 다시 말해, 실험의 분석을 위해 통계에 대한 이해도 거의 필요로 하지 않는다.
반면 결국 어떤 데이터를 어떻게 보고 싶은가? 는 데이터의 영역보다는 논리적으로 가설을 세우는 일의 중요성에 가깝다. 그러니까, 분석 툴을 다루기에 앞서 정말로 물어봐야 하는 건 '데이터를 배워야 하나요?'가 아니라
1. 내 가설을 확인하기 위해선 유저의 어떤 행동 event을 기준으로 봐야 하나?
2. 이걸 정확히 보기 위한 조건은 무엇인가?
ㄴ 디바이스를 구분해야 할까?
ㄴ 특정 시점, 기간을 기준으로 해야 할까?
ㄴ 특정 유형의 유저를 대상으로 해야 할까?
가령, "할인을 제공하면 제품을 구매하는 유저가 증가할 것이다"라는 가설이 있다고 가정해보자. 이 가설을 검증하기 위해 봐야 하는 지표는 무엇인가? 여기에서 말하는 할인이 정확히 무엇인가? 제품은 어떤 제품을 의미하는가? 유저는 대체 어떤 유저를 의미하는가? 이 질문에 대한 답이 명확하지 않다면 어떤 툴과 인프라가 있다한들, 분석은 무의미하다. 그러니까 정말로 중요한 건 가설이다.
그럼에도 데이터 관련된 무언가를 해야겠다면...
그러나 제너럴리스트인 pm이 비단 가설만 세우고 말로만 떠들고 업무를 끝마칠리는 없다. 가설이 명확하더라도, 실제로 일이 돌아가기 위한 크고 작은 업무들을 조율하거나, 직접 하기 위해선 결국 이런저런 툴을 익히거나 세팅하는 일들이 생기기 마련이다.
아마도 그래서 결과적으로는
1. 전사적으로는 측정할 수 있는 툴을 세팅하기 위해 Amplitude 등
2. 특정 활동, 프로모션 등의 추적을 위한 코드를 심기 위해 GTM, UTM 등
3. DB에 쌓인 결과를 추출하기 위해 SQL
4. 결과를 통계적으로 분석하기 위해 Excel, R/Python 등
등을 배우게 되지 않는가 싶다.
나 역시 어느새 GTM, UTM에 대해 이해하게 되었고, GTM 이벤트와 속성을 설계하여 개발 시 제품 내에 함께 반영되도록 요청하고 있으며, 백엔드 개발자 분과 확인하여 제품의 DB 구조를 파악하여 필요시엔 직접 SQL로 데이터를 추출, 조회하고 있다. DB에서 가져온 데이터의 분석은 Excel을 통해 통계적으로 확인하고, Amplitude를 통해 제품의 앞단에서 발생한 데이터를 분석한다.
그러나 이 모든 툴의 이해 또는 습득이, 명확한 가설 설정과 문제 정의에 앞서지는 않는다.
그러니까 PM의 시작도 끝도 가설이고, PM에게 필요한 데이터 능력은 어디까지나 가설을 제대로 검증하는데 필요한 만큼이라는 생각이다.
PM에게 필요한 데이터 능력은
가설을 제대로 검증하는데 필요한 만큼만아닐까?
