PRD(Product Requirement Document)

PO/PM이라면 PRD 작성에 꽤 많은 시간을 할애한다. 나는 워터폴 조직과 애자일 조직에 있으면서, 어떤 것이 정답인 PRD인지 계속 고민을 해왔다. 회사와 조직 나름대로의 맞는 양식이 정해져 있지만, 여러 아티클을 읽고 사내 강의를 들으며 공통적인 특징들이 있어 정리해 보았다.

---

PRD(Product Requirement Document)

PRD란 제품 요구 사항 정의서로, 왜 그리고 어떻게 제품을 만들 것인가를 담은 문서이다.
 

PRD에 들어가는 항목

I. Problem Alignmnet
1. 프로젝트
- 어떤 것을 하는지 서술
- 스토리 형태로 유즈 케이스와 어느 정도의 임팩트가 있는지 서술
2. 문제점
- 우리 고객과 비즈니스에 어떤 문제를 주고 있는지 서술
 : 우리 고객은 누구인데, 이런 것을 하고 싶지만, 이러한 문제로, 이렇게 하고 있다
- 문제가 있다고 생각했던 근거
3. 목표
- 우리가 성공했다고 할 수 있는 근거 (측정가능한 지표, 측정할 수 없는 것도 포함)
- 목표로 삼지 않은 지표가 있다면 해당 지표와 근거
- 목표 지표, 베이스라인, 타깃일
4. 가설
 : 우리가 만약 이렇게 한다면, 유저 행동은 이렇게 변할 것이고, 이것은 무슨무슨 지표에 긍정적인 영향을 줄 것이다
- 어떤 지표에 어느 정도 규모의 영향을 주는지에 대한 예상치
 
II. Solution Alignment
1. 피처
- 문제를 해결하기 위한 해결책
- 해결책의 우선순위및 옵셔널 리스트, 중요도
- 프로젝트의 규모와 버전을 설정
2. 플로우
- 우리 고객이 경험할 서비스의 플로우 (다이어그램, 스크린숏 등)
- 디자이너/개발자들과 논의하여 에지케이스, 시나리오 등을 디테일하게 작성
3. 리스크 & 트레이드오프
4. 디자인
 
III. Launch Plan
1. 마일스톤
2. 담당자(PO, 디자이너, 개발자, 분석가, 마케터 등)
3. 체크 리스트
 
IV. Appendix
1. 히스토리 및 변경사항
2. Q&A
3. 리서치(경쟁사 분석, 지표, 서베이 등)
4. 회의록
 

---

"이 일을 왜 하는지"에 집중한다면 훌륭한 PRD를 작성할 수 있을 것이라 생각이 든다. 또한 이것 또한 문서이기에 TL;DR(Too Long; Don't Read)라는 생각으로 작성해야겠다. 무엇보다도 기획자든, 디자이너든, 개발자든, 그 누구든 자신의 직무와 상관없이 소통할 수 있는 환경이 뒷받침될 때, PRD가 더 의미가 있는 것 같다.