이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
수업 프로젝트에서 PRD를 처음 작성했을 때, 무엇을 만들지에 집중하다가 왜 만드는지를 빠뜨리는 실수를 했습니다. 이후 PRD 작성 방식을 바꿔 문제 정의와 사용자 관점의 기대 결과를 앞에 배치하고, 기능 명세는 그 다음에 오도록 구조를 잡았습니다.
배경 → 사용자 스토리 → 기능 요건 → 비기능 요건 → 성공 지표의 순서가 기술팀과 소통할 때 가장 효과적이었습니다. 특히 성공 지표를 미리 정의하는 것이 기능 구현 후 평가 기준을 사전에 합의하는 역할을 했습니다. PRD는 팀 전체가 같은 목적으로 정렬되는 문서이기 때문에, 기술보다 목적과 기준이 명확하게 담겨야 한다고 생각합니다.
PRD를 쓰면서 제가 중요하다고 배운 것은 무엇을 만들지만큼 무엇을 안 만들지를 적는 것입니다. 수업에서 PRD를 처음 썼을 때 하고 싶은 것을 다 넣었더니, 개발 단계에서 범위가 자꾸 늘어나 일정이 흔들렸습니다. 그래서 저는 이번에 다룰 범위와 다루지 않을 범위를 분명히 나눠 적는 방식으로 바꿨습니다. '이건 이번 범위가 아니다'를 명시하니, 나중에 추가 요청이 와도 기준을 두고 논의할 수 있었습니다. 범위가 모호하면 좋은 의도의 추가들이 쌓여 일정을 무너뜨립니다. PRD는 기능 목록을 늘어놓는 것이 아니라, 경계를 분명히 그어 팀이 같은 범위를 보게 만드는 문서라고 생각합니다. 그래서 저는 범위 안과 밖을 함께 적는 것을 중요하게 봅니다.
PRD를 쓸 때 제가 의식하는 것은 읽는 사람마다 보고 싶은 것이 다르다는 점입니다. 개발자는 구체적인 요건과 제약을, 디자이너는 사용자 흐름을, 사업 쪽은 목표와 효과를 먼저 봅니다. 그래서 저는 PRD에 배경과 목적을 앞에 두되, 각 이해관계자가 자기에게 필요한 부분을 빠르게 찾을 수 있게 구성하려 합니다. 또 PRD는 한 번 쓰고 끝나는 문서가 아니라, 개발과 디자인, 검수와 함께 검토하며 계속 다듬어 가는 살아있는 문서라는 것을 배웠습니다. 처음부터 완벽할 수 없어, 모호한 부분은 논의로 메워야 했습니다. 모호하게 남긴 요구사항은 나중에 재작업으로 돌아옵니다. 그래서 저는 PRD를 팀이 같은 목적으로 정렬되고, 함께 고쳐가는 기준 문서로 씁니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오페이 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.