이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 사내 개발자 도구 개선 프로젝트에서 Product Owner 역할을 부여받아 3주 스프린트를 두 번 운영했습니다. 처음에는 백로그 항목을 많이 쌓아두면 좋다고 생각했는데, 실제로는 명확한 수용 기준(Acceptance Criteria)이 없는 항목이 개발 완료 후에도 재작업으로 이어지는 경우가 생겼습니다. 이를 보완하려고 각 스토리에 '언제 이 기능이 완료됐다고 볼 수 있는가'를 한 문장으로 적는 규칙을 팀에 제안했고, 두 번째 스프린트부터는 재작업 건수가 절반으로 줄었습니다. 또한 이해관계자 리뷰 시간을 스프린트 종료일 하루 전으로 당겨 피드백 반영 시간을 확보했습니다. 제품 오너십이란 기능을 나열하는 일이 아니라 완료의 기준을 팀이 공유하게 만드는 일이라는 점을 이 경험에서 배웠습니다.
Product Ownership에서 제가 또 한 건 이해관계자 리뷰 타이밍을 당긴 것입니다. 스프린트 종료일에 리뷰하면, 피드백을 반영할 시간이 없어 다음 스프린트로 밀렸습니다. 그래서 리뷰를 종료일 하루 전으로 당겨, 그날 받은 피드백을 바로 반영할 여지를 만들었습니다. 한 번은 그 하루 덕에, 막판 수정을 제때 끝낸 적이 있습니다. 오너십은 기능을 나열하는 게 아니라, 어떻게 굴러가게 만들지를 책임지는 것이었습니다. '맡았다'가 아니라, 제가 어느 흐름을 바꿨는지 말할 수 있었습니다.
언제 피드백을 받느냐가 반영 여부를 갈랐습니다. 작은 일정 조정이 결과를 바꿨습니다.
Product Owner로서 제가 본 결과는 재작업이 절반으로 준 것입니다. 처음엔 수용 기준 없는 백로그 항목이, 개발 완료 후에도 재작업으로 이어졌습니다. 그래서 각 스토리에 '언제 이 기능이 완료됐다고 볼 수 있는가'를 한 문장으로 적는 규칙을 제안했습니다. 두 번째 스프린트부터, 재작업 건수가 절반으로 줄었습니다. 막연히 '깔끔해졌다'가 아니라, 재작업 건수라는 숫자로 효과를 봤습니다.
완료의 기준이 흐리면, 만들고도 다시 만들었습니다. 그래서 오너십의 핵심은 완료의 기준을 팀이 공유하게 만드는 것이라고 배웠습니다. 측정이 그 규칙이 통했음을 증명했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.