이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 신기능 출시 후 성과 분석 보조를 맡으면서 어떤 지표를 어떤 순서로 봐야 하는지를 처음 정리했습니다. 출시 직후에는 오류율·서버 응답 시간·크래시 빈도를 먼저 확인해 기술 이슈가 없는지 점검했습니다. 48시간 이후에는 기능 사용률·첫 사용까지의 시간·태스크 완료율을 봤고, 2주 뒤에는 해당 기능을 사용한 그룹과 미사용 그룹의 리텐션 차이를 비교했습니다. 이 순서가 중요한 이유는 기술 이슈가 있는 상태에서 비즈니스 지표를 보면 노이즈가 섞이기 때문입니다. 분석 결과 기능 사용자 그룹의 D14 리텐션이 11%p 높다는 점을 발견했고, 해당 기능을 온보딩에 포함시키는 방안을 제안했습니다. 성과 분석에서 핵심은 기술·사용성·비즈니스 지표를 단계별로 순서 있게 확인하는 것이라는 점을 배웠습니다.
제품 출시 후 성과 분석에서 제가 가장 의식하는 건, 전체 평균만 보면 안 된다는 점입니다. 같은 지표도 획득 채널이나 시장, 세그먼트별로 쪼개면 전혀 다른 패턴이 나와 개선 레버를 특정할 수 있습니다. 평균 리텐션이 그럭저럭이어도, 특정 채널로 들어온 사용자만 유난히 빨리 떠난다면 거기가 손볼 곳입니다. 그래서 저는 다운로드나 전환, 리텐션 같은 지표를 단계별로 보되, 항상 세그먼트로 나눠 어디가 약한지를 짚으려 합니다. 다만 제 한계도 인정합니다. 저는 이 원리를 이해하는 단계라, 실제로 출시 전에 '이 지표가 몇 % 개선되면 성공'이라는 기준을 정해 분석을 성공·실패 판단으로 잇는 설계를 해 본 경험은 적습니다. 또 세그먼트를 잘게 나누면 각 그룹 표본이 작아져 결론이 흔들릴 수도 있습니다. 그래서 성과 분석을 전체 평균이 아니라 세그먼트로 쪼개 개선 레버를 찾되, 성공 기준을 미리 정해 결정으로 잇는 역량을 더 키우려 합니다.
인턴 때 신기능 출시 후 성과 분석을 보조하며, 제가 정리한 건 어떤 지표를 어떤 순서로 보느냐였습니다. 출시 직후엔 오류율·서버 응답·크래시 빈도를 먼저 봐 기술 이슈가 없는지 점검했습니다. 48시간 뒤엔 기능 사용률과 첫 사용까지의 시간, 태스크 완료율을 봤고, 2주 뒤엔 그 기능을 쓴 그룹과 안 쓴 그룹의 리텐션 차이를 비교했습니다. 이 순서가 중요한 이유는, 기술 이슈가 있는 상태에서 비즈니스 지표를 보면 노이즈가 섞이기 때문입니다. 분석 결과 기능 사용자 그룹의 14일 리텐션이 11%p 높아, 그 기능을 온보딩에 넣자고 제안했습니다. 분석이 결정으로 이어진 셈입니다. 다만 제 한계도 인정합니다. 저는 보조 역할이라, 출시 전에 성공 기준을 미리 정하거나 채널별로 쪼개 보는 데까진 못 갔습니다. 또 리텐션 차이가 그 기능 덕인지 다른 요인인지 엄밀히 가르진 못했습니다. 그래서 단계별 순서로 보는 토대 위에, 성공 기준 설계와 귀인 분석을 더 키우려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.