이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 사내 어드민 툴 개선 프로젝트에서 요구사항 분석을 처음 혼자 담당했습니다. 팀장님이 사용자가 불편하다고만 알려주셔서, 먼저 실제 사용 로그 데이터를 뽑아 어떤 기능에서 이탈이 많은지를 확인했습니다. 클릭 이벤트와 페이지 체류 시간을 기준으로 상위 3개 불편 지점을 추렸고, 추가로 현업 담당자 2명과 짧은 인터뷰를 진행해 로그에는 안 잡히는 맥락을 보완했습니다. 분석 결과는 슬라이드 5장 분량으로 정리해 팀 전체에 공유했는데, 숫자만 나열하지 않고 왜 이 지점이 문제인가를 한 줄로 쓰는 방식을 썼습니다. 팀원들이 추가 질문 없이 개선 우선순위를 바로 정할 수 있었고, 이 경험 이후 요구사항을 받을 때 데이터를 먼저 확인하는 습관이 생겼습니다.
데이터 분석 결과를 팀에 공유할 때 숫자만 나열하면 각자 다르게 해석한다는 것을 경험했습니다. 클릭 이탈율 수치를 표로 정리해서 공유했는데, 팀원들이 같은 데이터를 보고 서로 다른 결론을 말했습니다. 왜 이 수치가 문제인지를 수치 옆에 한 줄로 추가하는 방식으로 바꿨더니 논의가 빠르게 수렴됐습니다. 데이터는 사실을 보여주지만 의미는 해석자가 만든다는 것을 그때 배웠습니다. 이후 분석 결과를 공유할 때 수치 아래에 왜 이게 중요한지를 한 줄씩 추가하는 방식을 기본으로 쓰고 있습니다.
데이터 공유의 목적은 같은 이해를 만드는 것이라는 것을 경험했습니다.
요구사항을 분석할 때 로그 데이터만으로 파악이 안 되는 맥락을 현업 담당자 인터뷰로 보완한 경험이 있습니다. 어떤 기능에서 이탈이 많다는 것은 로그로 확인했는데, 왜 거기서 이탈하는지는 데이터만으로 알 수 없었습니다. 담당자 두 명과 15분씩 이야기해보니 해당 기능이 원래 목적이 아닌 방식으로 사용되고 있다는 것을 알았습니다. 그 맥락 없이 개선 방향을 잡았다면 원인이 다른 곳에 있는데 엉뚱한 부분을 수정하는 결과가 됐을 것입니다.
정량 데이터는 어디가 문제인지를 보여주고, 인터뷰는 왜 문제인지를 알려준다는 것을 배웠습니다. 두 가지를 병행하는 방식이 분석의 신뢰도를 높이는 방법이라는 것을 그때 이해했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.