이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
제품 성공을 측정할 때 저는 먼저 North Star 지표 하나를 정의하는 것부터 시작합니다. 모든 팀이 공유할 수 있는 단일 목표 지표가 있어야 방향이 분산되지 않습니다. 예를 들어 구독 서비스라면 주간 활성 사용자 수나 갱신률이 North Star가 될 수 있습니다. 그 아래에는 이를 움직이는 선행 지표를 배치하는데, 온보딩 완료율·핵심 기능 사용률 같은 행동 지표들이 이에 해당합니다. 인턴 때 데이터 분석 보조를 하면서 매출만 보다가 행동 지표를 같이 봤을 때 원인 진단 속도가 달라지는 걸 경험했습니다. 측정 구조 자체가 팀의 의사결정 품질을 결정한다고 생각합니다.
제품 성공을 측정하는 방법에서 제가 실제로 시도해본 건, 사용자가 핵심 기능을 '처음에' 어떻게 경험하는지 추적하는 것이었습니다. 기능이 많아도 첫 경험이 나쁘면 이탈하고, 처음을 잘 넘기면 이후 지표가 달라진다고 생각했습니다. 토이 프로젝트로 간단한 할 일 관리 앱을 만들었을 때, 첫 화면에서 항목을 하나 추가하기까지 걸리는 시간을 측정해봤습니다.
평균 45초가 걸렸는데, 이게 높은 건지 낮은 건지 판단 기준이 없었습니다. 비슷한 앱을 써보니 평균 20초 이하였고, 그 차이에서 어느 화면에서 사용자가 멈추는지 직접 관찰하게 됐습니다. 아직 실제 프로덕트를 운영한 경험은 없습니다. 하지만 제품 성공의 첫 측정 기준은 사용자가 핵심 행동을 처음 완료하는 데 걸리는 시간이라는 감각은 생겼습니다.
제품 성공을 측정할 때, 제가 중요하게 생각하는 건 어느 지표를 선택하느냐에 따라 무엇이 희생되는지도 함께 봐야 한다는 것입니다. 지표 하나를 올리면 다른 지표가 내려가는 경우가 있고, 그 거래를 의식하지 않으면 좋은 지표가 나쁜 결정을 가릴 수 있습니다. 토이 프로젝트에서 사용자 체류 시간을 늘리는 것을 목표로 삼았을 때, 알림을 늘렸더니 체류 시간이 올라갔습니다. 하지만 함께 확인한 만족도 피드백에서 "알림이 너무 많다"는 불만이 나왔고, 체류 시간이 오른 게 긍정적인 이유가 아닐 수 있다는 걸 깨달았습니다. 그 이후로는 측정 지표를 정할 때 "이 지표를 올리면 어떤 지표가 내려갈 수 있는가"를 함께 확인하는 방식을 써봤습니다. 아직 실제 PM 경험은 없습니다. 하지만 제품 성공 측정은 지표를 고르는 것이 아니라 지표 간 거래를 의식하는 것이라는 감각은 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 와이즐리컴퍼니 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.