이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
프로젝트 기획을 진행할 때 가장 중요하게 생각하는 것은 문제 정의의 명확성입니다. 무엇을 만들지보다 왜 만드는지가 불명확하면 중간에 범위가 계속 늘어나는 경향이 있습니다. 팀 프로젝트에서 기획 초반에 사용자 인터뷰 3건만 진행했는데도, 처음 가정했던 핵심 문제와 실제 사용자 불편이 달랐던 경험이 있습니다.
기획 수정이 개발 도중 발생하면 리소스 낭비가 크기 때문에, 초반 검증 단계를 짧게라도 두는 것이 전체 속도를 높인다는 것을 배웠습니다. 관리 측면에서는 기능 목록과 우선순위를 스프레드시트로 정리하고, 각 기능의 영향도와 구현 비용을 함께 기재해 팀원 간 의사결정 기준을 공유했습니다. 우선순위가 불명확하면 중요한 기능이 밀리고 나중에 급하게 만드는 상황이 생깁니다.
기획은 결국 우선순위 결정의 연속이라는 결을 프로젝트를 거치며 배웠습니다.
팀 프로젝트에서 기능이 너무 많이 쌓여 무엇부터 만들지 결정하지 못하는 상황이 생겼습니다. RICE 프레임워크(도달범위·영향도·확신도·노력)를 처음 적용해봤는데, 숫자로 환산하니 의견이 다를 때 근거를 갖고 대화할 수 있었습니다. 처음 제안된 기능 18개 중 8개만 1차 출시 범위로 줄였고, 나머지는 다음 스프린트 후보로 남겼습니다. 출시 후 사용자 피드백을 보니 1차 범위 8개 중 실제로 많이 쓰인 것은 4개였고, 나머지 14개를 전부 만들었다면 그 4개에 집중할 시간이 없었을 것이라는 걸 알게 됐습니다. 기획 관리 측면에서는 기능 목록에 '출시 여부'와 '실제 사용 여부'를 함께 기록하는 습관이 생겼습니다.
기획 결과는 출시 여부가 아니라 사용 여부로 측정해야 한다는 것을 이 경험에서 배웠습니다.
이전 프로젝트에서 팀원마다 '완성'의 기준이 달라 개발 후반에 추가 요구가 쏟아진 경험이 있었습니다. 이후에는 시작 전에 OKR 방식으로 목표와 핵심 결과를 문서에 먼저 정리했습니다. '사용자 가입 후 3일 내 첫 행동 완료율 60%' 같은 식으로 기준을 수치화해두니 새로운 기능 제안이 나왔을 때 '이게 Key Result에 기여하는가' 하나로 걸러낼 수 있었습니다.
주간 체크인 때 KR 현황을 짧게 확인하는 루틴을 만들었더니 범위가 이탈하는 시점을 2주 안에 발견하게 됐습니다. 이전에는 출시 직전에 범위 문제를 발견했는데, 이번에는 중간에 조정했습니다. 기획은 처음 결정이 아니라 주기적으로 재확인하는 작업이라는 결을 이 경험에서 얻었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 스마일게이트 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.