이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학부 캡스톤 프로젝트에서 교내 분실물 신고 서비스를 기획했습니다. 처음에는 팀원 4명끼리 "이런 기능이 있으면 좋겠다"를 나열했는데, 나중에 실제 학생 10명을 인터뷰해보니 우리가 중요하다고 생각한 기능과 실제로 필요한 기능이 달랐습니다.
우리는 분실물 사진 업로드 기능을 핵심으로 생각했는데, 인터뷰하니 "사진보다 위치 정보가 더 중요하다"는 답이 많았습니다. 어디서 잃어버렸는지를 알아야 찾을 수 있다는 당연한 이야기인데, 기능 목록만 보고 있으면 놓치게 됩니다.
그 경험에서 "사용자를 직접 만나기 전에 기능을 확정하지 말자"는 습관이 생겼습니다. 인터뷰 10명이 많지는 않지만, 그 10명이 방향을 완전히 바꿨습니다. 지금도 기획을 시작할 때 가장 먼저 하고 싶은 게 사용자 인터뷰입니다.
동아리에서 회원들이 쓸 내부 일정 관리 도구를 기획한 적이 있습니다. 처음에는 기능 목록부터 만들었는데, 어디에 초점을 맞춰야 하는지 방향이 흔들렸습니다. 팀원마다 원하는 기능이 달라서 논의가 길어졌습니다.
그때 "이 도구가 누구의 어떤 문제를 해결하는가"를 한 문장으로 쓰자고 제안했습니다. "동아리 신입 회원이 일정 공유 때문에 놓치는 회의가 없도록 한다"고 정했더니, 기능 논의가 훨씬 빨라졌습니다. "이 기능이 그 문제를 해결하는가"라는 기준이 생기니까 판단이 명확해졌습니다.
제품 비전이 거창하거나 길 필요는 없다고 생각합니다. 오히려 짧고 구체적일수록 의사결정 기준으로 쓰기 좋다는 걸 그때 배웠습니다. 그 이후로 프로젝트를 시작할 때 가장 먼저 "이게 누구의 어떤 상황을 바꾸는가"를 적는 습관이 생겼습니다. 방향 정의가 기능 나열보다 먼저여야 한다는 감각은 그때부터입니다.
팀 프로젝트에서 서비스 기획을 맡았을 때, 처음에는 사용자 경험만 생각하고 운영 측면을 놓쳤습니다. 사용자가 자유롭게 태그를 입력할 수 있는 기능을 넣었는데, 나중에 보니 비슷한 의미의 태그가 수십 개 생겨서 검색이 오히려 어려워졌습니다.
결국 관리자 승인 방식으로 바꾸거나 자동 정규화를 넣어야 했는데, 기획 단계에서 "이 기능이 운영될 때 어떻게 관리되는가"를 생각했으면 피할 수 있었습니다. 사용자 편의를 주면 운영 복잡도가 올라간다는 걸 그때 처음 실감했습니다.
이후에는 새 기능을 기획할 때 "이게 실제로 운영되면 누가 어떻게 관리하는가"를 함께 적는 습관이 생겼습니다. 고객 경험과 운영 가능성이 함께 검토돼야 기획이 완성된다고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.