이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
제가 졸업 프로젝트로 학과 스터디 모집 앱을 운영하며, 사용자 여정을 단계로 나눠 분석해본 경험이 있습니다.
"활동이 저조하다"는 막연한 문제가 있었습니다. 처음엔 제가 전체를 뭉뚱그려 보며 헤맨 적이 있었습니다. 그 뒤 저는 사용자 여정을 "앱 방문 → 스터디 탐색 → 신청 → 참여" 단계로 쪼갰습니다.
각 단계에서 사람이 얼마나 남는지 데이터로 보니, 신청 화면까지 온 사람의 3분의 2가 거기서 이탈했습니다. 진짜 약한 단계가 "신청"이라는 게 드러난 것입니다. 저는 신청 단계를 줄였고, 참여율이 올랐습니다. 저는 이 경험에서 사용자 여정을 단계로 쪼개 보면, 어느 단계가 가장 약한지가 데이터로 또렷이 보인다는 점을 배웠습니다. 전체를 뭉뚱그리면 안 보이던 약한 고리가, 단계로 나누면 드러난다는 걸 익혔습니다.
제가 졸업 프로젝트로 만든 앱의 사용자 여정을 데이터로 분석해본 경험이 있습니다.
개선할 단계가 여러 곳 같았습니다. 처음엔 제가 여러 단계를 골고루 손대려다, 어느 것도 크게 나아지지 않은 적이 있었습니다.
그 실패 뒤 저는 데이터로 "이탈이 가장 큰 한 단계"를 골랐습니다. 첫 방문 직후 사람들이 가장 많이 떠나고 있었습니다. 저는 거기에만 집중해, 첫 화면이 무엇을 하는 앱인지 한눈에 보이게 바꿨습니다. 그러자 이후 단계로 넘어가는 사람이 늘었습니다. 저는 이 경험에서 사용자 여정 개선은 모든 단계를 손대는 게 아니라, 데이터로 가장 약한 한 단계를 골라 집중하는 일이라는 점을 배웠습니다. 적은 힘으로 큰 효과를 내려면 한 곳을 정확히 골라야 한다는 걸 익혔습니다.
제가 졸업 프로젝트에서 앱의 한 단계를 개선하고 효과를 확인해본 경험이 있습니다.
저는 사용자가 많이 이탈하던 신청 단계를 손봤습니다. 처음엔 제가 바꾼 뒤 효과를 안 보고 넘어간 적이 있었습니다. 그러자 그게 정말 나아진 건지 알 수 없었습니다.
그 실패 뒤 저는 바꾸기 전과 후의 "신청 완료율"을 같은 방식으로 재서 견줬습니다. 숫자가 실제로 올랐는지 확인한 것입니다. 한 번은 바꾼 게 효과가 없어 되돌리기도 했습니다. 저는 이 경험에서 사용자 여정 개선은 "바꿨다"가 아니라 "그 단계 지표가 실제로 움직였다"로 끝나야 한다는 점을 배웠습니다. 데이터로 검증하지 않으면, 좋아졌다고 착각만 할 수 있다는 걸 익혔습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.