제품 요구사항 프레젠테이션은 PRD를 그대로 복사한 문서가 아닙니다. 검토에서 필요한 문제, 범위, 제외 항목, 수용 기준, 미결정 사항을 먼저 보여 줍니다. 검토한 개요로 텍스트를 프레젠테이션으로 옮긴 편집 가능한 초안을 만들 수 있지만, 요구사항과 한계는 반드시 실제 PRD에서 가져와야 합니다.
문제와 목표 다듬기
사용자 문제와 검토에서 내려야 할 결정부터 제시합니다. 사용 관찰이나 문의 패턴처럼 관련 증거를 넣되, 데이터가 말하는 범위를 넘어 확정적으로 표현하지 마세요. 목표는 원하는 변화를 설명하며 기술적 해결책을 미리 정하는 문장이 아닙니다.
범위와 제외 항목 분리하기
포함할 사용 사례와 의도적으로 제외할 사례를 따로 적습니다. 제외 항목은 검토 과정에서 범위가 조용히 커지는 것을 막습니다. 가정과 열린 질문은 확정 요구사항이 아니라 별도 상태로 표시하세요.
검증 가능한 수용 기준 쓰기
누가, 어떤 조건에서, 무엇을 할 수 있어야 하는지 관찰 가능한 결과로 작성합니다. 측정 기준 없이 ‘쉽다’나 ‘빠르다’라고만 쓰지 마세요. 각 기준에 우선순위와 알려진 의존성을 연결합니다.
의존성과 위험 보여 주기
연동 지점, 데이터 출처, 법무 검토, 다른 팀의 결정을 표시합니다. 의존성이 곧 차단을 뜻하지는 않으므로 상태, 담당자, 다음 행동을 함께 적습니다. 확인되지 않은 일정을 약속처럼 제시하지 않습니다.
결정 로그 넣기
마지막에 결정, 선택지, 추천안, 근거, 담당자, 기한을 짧은 표로 정리합니다. 결정됨, 제안됨, 확인 필요를 분리하면 회의 후 실제 합의 내용이 남습니다.
검토용 기본 구성
- 문제, 목표, 검토 질문
- 대상 사용자와 근거 있는 맥락
- 범위와 제외 항목
- 요구사항과 수용 기준
- 의존성, 위험, 가정
- 미결정 사항과 다음 단계
각 슬라이드의 중심을 하나의 결정이나 근거로 유지하세요. 프레젠테이션은 검토를 빠르게 하는 자료이지 전체 PRD를 대체하지 않습니다.
형식의 한계
프레젠테이션은 의사결정을 위한 입구입니다. 전체 명세나 구현을 대신하지 않습니다. PRD 연결을 남기고 변경 사항을 표시하며, 검토에서 확인된 내용만 확정된 사실로 다룹니다.
검토에서 결정할 질문 정하기
‘공유 받은편지함 기능의 첫 릴리스 범위를 승인한다’처럼 시작합니다. 결정권자, 검토 예정일, 사용자 또는 비즈니스 문제를 함께 적습니다. 프로젝트 이름만으로는 자료가 올바른 질문에 답하는지 알 수 없습니다.
관찰된 증거와 경계를 사용해 문제를 설명합니다. ‘대화가 큐 사이를 이동하면 지원 담당자가 맥락을 잃는다’는 문제이고, ‘새 라우팅 서비스를 만든다’는 구현 가설입니다. 늦게 참여한 사람도 첫 슬라이드에서 결정, 추천안, 범위와 미해결 위험을 알 수 있어야 합니다.
범위를 세 층으로 나누기
릴리스를 포함, 제외, 보류로 나눕니다. 포함 항목은 사용자 행동이나 관찰 가능한 결과로 씁니다. 공유 받은편지함의 예로 한 큐에 대화를 배정하고 담당자를 표시하며 인수인계를 기록하는 기능을 들 수 있습니다. 감정 기반 자동 라우팅과 모바일 클라이언트는 제외 예시입니다. 실제 약속된 기능으로 받아들이지 않도록 표시하세요.
두 요구사항이 충돌하면 트레이드오프를 보여 줍니다. 빠른 첫 버전에서 하나의 ID 공급자만 지원하고 나머지를 다음 단계로 미룰 수 있습니다. 결과와 그 타협을 받아들일 담당자를 함께 적습니다.
가장 작은 유용한 사용자 흐름 설명하기
트리거, 사용자의 중요한 선택, 예상 결과가 포함된 핵심 흐름 하나를 고릅니다. 주요 경로를 이해한 뒤에 예외를 별도로 다룹니다. 각 단계에 필요한 정보, 사용자 행동, 피드백을 넣고 정책이나 외부 서비스 의존성을 표시하세요. 화면을 채우려고 존재하지 않는 컨트롤을 만들지 않습니다.
요구사항을 바꾸는 접근성과 오류도 표시합니다. 요청이 거절되거나 연결이 끊기거나 권한이 없을 때 무슨 일이 일어나는지 적습니다. 성공 경로만 있는 흐름은 완전한 요구사항이 아닙니다.
수용 기준을 검증 가능하게
조건이 주어지고 행동이 일어났을 때 어떤 결과가 보이는지 관찰 가능한 문장으로 씁니다. 기능, 품질, 운영 준비 기준을 구분하세요. 위험이 큰 기준에는 자동 테스트, 사용성 세션, 보안 검토, 부하 테스트, 수동 점검 같은 검증 방법을 붙입니다. 검증 방법은 성공 보장이 아니라 출시 전 합의한 확인 방식입니다.
의존성과 선택지 드러내기
ID 공급자, 데이터 이전, 법무 검토, 디자인 시스템 구성요소, 다른 팀의 API를 담당자와 상태와 함께 적습니다. 일정에는 이 검토에 필요한 통합·테스트·결정 지점만 표시하고 불확실한 추정치를 약속처럼 쓰지 않습니다. 대안은 학습 시간, 되돌릴 수 있음, 사용자 위험과 유지보수 부담으로 비교하고 선택 기준을 밝혀야 합니다.
기록할 수 있는 승인으로 마무리
범위 승인, 조건부 승인, 구체적인 수정 요청 중 하나를 선택하도록 요청합니다. 무엇을 승인했고 무엇을 제외했는지, 다음 담당자와 재검토일을 결정 로그에 남깁니다. 근거가 약하면 학습 목표가 명확한 탐색 과제나 프로토타입을 제안합니다. PRD와 버전 날짜를 함께 보내 당시 알고 있던 사실, 선택, 미해결 사항을 보존하세요.
검토에 필요한 근거 정리하기
각 요구사항이 어떤 문서나 관찰에서 나왔는지 짧게 연결합니다. 명세의 문장, 사용자 관찰, 법무 확인과 기술 제약은 서로 다른 정보이므로 라벨을 붙여 구분하세요. 그래야 논의가 취향이 아니라 확인 가능한 항목으로 돌아옵니다.
요구사항이 충돌할 때는 긴 목록에 함께 넣지 말고 무엇을 우선했는지, 수용한 위험과 나중에 다시 볼 조건을 한 줄로 표시합니다.
수용 기준 예시 만들기
조건, 행동, 예상 결과의 조합을 회의에서 바로 읽을 수 있는 예로 작성합니다. ‘권한이 없는 사용자는 전송할 수 없다’, ‘연결이 복구되면 보내지지 않은 내용을 잃지 않는다’처럼 확인할 상태를 구체적으로 적습니다. 측정 기준 없는 ‘빠르다’나 ‘직관적이다’는 수용 기준으로 사용하지 않습니다.
위험이 높은 조건은 누가 언제 어떤 방법으로 확인할지 연결합니다. 방법이 정해지지 않았다면 미결 항목으로 돌리고 결정권자와 기한을 적습니다.
의존성 추적하기
외부 API, 인증, 데이터 이전, 디자인 시스템, 법무 판단처럼 다른 팀의 상태에 좌우되는 요소를 목록으로 만듭니다. 각 항목에 담당자, 현재 상태와 다음 확인일을 추가합니다. 담당자가 없는 의존성은 위험 또는 결정 항목으로 승격하세요.
판단 로그 남기기
회의가 끝나면 승인한 범위, 제외한 범위, 조건, 담당자와 재검토일을 표로 정리합니다. ‘검토하자’로 끝내지 말고 승인, 조건부 승인, 수정 요청 중 하나를 선택하세요.
근거가 부족하면 무엇을 알아야 판단할 수 있는지 학습 목표가 있는 조사나 프로토타입으로 분리합니다. 불확실한 일정과 성공률을 확정된 계획처럼 쓰지 않습니다.
버전 날짜와 변경 이유도 함께 기록합니다.
