이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
제가 졸업 프로젝트로 교내 도서관 좌석 예약 앱을 만들 때, 사용자의 진짜 문제를 이해하는 게 가장 어려웠습니다.
처음엔 제가 "자리가 부족할 것"이라고 짐작하고 기능을 정했습니다. 그런데 막상 만들어보니 사람들이 잘 안 썼습니다. 짐작이 빗나간 것입니다.
그 실패 뒤 저는 학우 열 명을 직접 만나 이야기를 들었습니다. 그리고 도서관에서 사람들이 자리를 어떻게 찾는지 직접 지켜봤습니다. 그러자 진짜 불편은 "자리 수"가 아니라 "빈자리가 어디 있는지 모르는 것"이라는 게 드러났습니다. 저는 이 경험에서 사용자 문제는 책상에서 짐작하면 안 되고, 직접 듣고 보는 데서 찾아야 한다는 점을 배웠습니다. 인터뷰와 관찰이라는 가장 단순한 방법이, 가장 정확한 단서를 줬다는 걸 익혔습니다.
제가 졸업 프로젝트에서 학과 스터디 모집 앱을 운영할 때, 사용자의 문제를 데이터로 찾아낸 경험이 있습니다.
"가입자는 느는데 활동은 안 한다"는 막연한 문제가 있었습니다. 처음엔 제가 짐작 하나만 믿고 화면을 바꿨다가 효과가 없던 적이 있었습니다.
그 실패 뒤 저는 사용 기록을 단계별로 살펴봤습니다. 신청 화면까지 온 사람의 3분의 2가 중간에 이탈한다는 게 보였습니다. 진짜 문제는 "활동 의지"가 아니라 "신청 과정이 번거로운 것"이었습니다. 저는 신청 단계를 줄였고 활동률이 올랐습니다. 저는 이 경험에서 사용자 문제는 말로 안 보일 때, 행동 데이터가 알려준다는 점을 배웠습니다. 어디서 사람들이 멈추는지를 데이터로 보면, 진짜 문제가 드러난다는 걸 익혔습니다.
제가 4명 팀과 교내 셔틀버스 이용 데이터를 분석하며, 사용자 문제를 한 가지 방법으로만 보면 안 된다는 걸 배웠습니다.
저는 처음에 탑승 데이터만 봤습니다. 특정 시간대에 사람이 몰린다는 건 보였지만, "왜" 그런지는 숫자만으로 안 보였습니다.
그래서 저는 데이터에 더해, 설문을 맡은 팀원의 사용자 응답 기록과 맞춰봤습니다. 그제야 "강의 시간표 때문"이라는 진짜 원인에 닿았습니다. 처음엔 제가 데이터만 믿고 결론을 서둘렀다가 되짚은 적이 있었습니다. 그 실패로 저는 데이터는 "무엇"을, 인터뷰는 "왜"를 알려준다는 점을 배웠습니다. 사용자 문제를 깊이 이해하려면 두 방법을 같이 써야 한다는 것을 익혔고, 이 자세를 실무에서도 이어가고 싶습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.