드디어 긴 기획과 개발 과정을 거쳐 새로운 기능이 세상에 나왔습니다. 뿌듯함은 잠깐, PM의 진짜 일은 이제부터 시작입니다. 릴리즈 버튼을 누르는 순간, 기다렸다는 듯이 피드백 지옥이 시작되죠.
해피 케이스*라면 KPI를 초과 달성하고 회사의 전략 지표들이 크게 오르겠죠. 하지만 최악의 경우, 고객센터에는 예상치 못한 버그 리포트가 쌓이고, 커뮤니티에는 "이 기능 왜 이래요?"라는 불만이 올라옵니다. 슬랙 채널에는 팀원들의 "데이터 좀 봐주세요" 같은 요청이 쏟아지고요.
* 해피 케이스(Happy Case): 프로그래밍에서 모든 조건이 정상적이고, 기능이나 프로세스가 예상대로 작동하는 경우
처음엔 모든 피드백이 귀하고 중요해 보이지만, 감정적으로 반응하거나 모든 요청을 수용하려 들면 금세 매몰됩니다. 여기서 PM의 역할은쏟아지는 물줄기를 필터링하고 방향을 잡아주는 댐과 같습니다. 이때 필요한 건 감정이 아니라 판단, 바로 숫자입니다.
이번 주제는 설레는 서비스 런칭 이후 우리가 마주하는 현실, 바로 '숫자 앞에 선 PM의 이야기'입니다. 특히 20대 주니어 PM이나 사회초년생이라면, 막 "MVP 출시!"를 외치고 한숨 돌리려는 순간, 쏟아지는 데이터와 피드백 앞에서 길을 잃기 쉽습니다. 하지만 숫자는 우리의 가장 강력한 무기이자 나침반이 됩니다.
오늘은 서비스 런칭 이후 PM이 데이터를 어떻게 읽고, 사용자의 목소리와 연결하며, 이를 바탕으로 서비스를 지속적으로 발전시켜 나가는지에 대한 저만의 노하우를 꾹꾹 담았습니다.
PM이 지표를 읽는 법
릴리즈 직후 쏟아지는 피드백과 초기 데이터는 가설 검증의 첫 단계입니다. 우리가 기대했던 사용자 행동이 실제로 일어났는지, 핵심적인 문제점은 무엇인지 '객관적으로' 파악해야 합니다. 이제 그 수많은 피드백을 숫자로 어떻게 읽고 정리할지 살펴보겠습니다.
