이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대학교 캡스톤 프로젝트에서 팀 전체의 기능 목록을 관리하는 역할을 맡았을 때, 처음에는 팀원마다 중요도 기준이 달라서 계속 충돌이 생겼습니다. 그래서 저는 임팩트와 개발 비용을 각각 3단계로 점수화해서 매트릭스로 정리하는 방식을 제안했고, 팀이 동의한 뒤부터는 논쟁이 수치 판단으로 바뀌었습니다.
Notion 칸반 보드에 각 기능의 점수와 근거를 기록해 두어서 중간에 요구사항이 바뀌어도 재정렬 이유를 명확하게 설명할 수 있었습니다. 사용자 인터뷰 결과가 들어올 때마다 점수를 갱신했고, 최종 발표 때 우선순위 결정 과정을 투명하게 보여줄 수 있었습니다. 우선순위는 한 번 정하는 게 아니라 새로운 정보가 들어올 때마다 계속 갱신해야 하는 것이라는 걸 그 프로젝트에서 배웠습니다. 그 경험을 앞으로도 이어가고 싶습니다.
캡스톤 중반에 사용자 인터뷰 결과가 들어오면서 처음 정한 우선순위가 흔들리는 상황이 생겼습니다. 인터뷰에서 중요도가 낮다고 판단했던 기능을 사용자들이 자꾸 언급했습니다. 그 시점에 우선순위를 완전히 다시 짜야 하는지 고민이 됐는데, 기존 매트릭스에 인터뷰 데이터 점수를 추가 입력해서 변화량을 먼저 확인했습니다. 결과적으로 해당 기능의 사용자 가치 점수가 올라갔고, 2순위에서 1.5순위 정도의 위치로 조정됐습니다.
우선순위를 한 번 정한 것으로 끝나는 게 아니라 새로운 정보가 들어올 때마다 같은 기준으로 다시 평가하는 것이 로드맵 관리라는 것을 그때 이해했습니다. 기준이 일관되면 변화도 설명이 된다는 것이 그 경험의 핵심이었습니다.
기능 우선순위를 팀 안에서 논의할 때 처음에는 각자 중요하다는 기능이 달라서 대화가 제자리를 맴도는 상황이 계속됐습니다. 의견이 다른 것이 문제가 아니라 비교 기준이 없어서 논쟁이 수렴이 안 됐던 것이었습니다. 임팩트와 개발 비용을 3단계로 수치화해서 각 기능에 점수를 붙이자고 제안했고, 팀이 동의했습니다. 그 이후부터 '이 기능이 더 중요하다'는 말 대신 '이 기능의 임팩트 점수가 높고 비용은 낮으니 우선순위가 올라간다'는 방식으로 논의가 바뀌었습니다.
수치 자체보다 판단 기준을 공유하는 것이 팀 안에서 빠른 합의를 만드는 방법이라는 것을 그때 경험했습니다. 기준이 없으면 이견이 쌓이고, 기준이 있으면 이견이 데이터로 바뀐다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.