- 대기업 경우
- 스타트업
- 문서를 작성하지 않다보면 커뮤니케이션 코스트 발생
- ‘개발자, DA, 디자이너가 PM/PO가 시키는 일만 수동적으로 하는 것 같다’라는 피드백을 받으면 잘못된 것
- 시니어들은 PRD를 바탕으로 협업을 한다
- Discription이 아닌 Documentation인 이유는
- 단순히 제품의 기능 관련 요구 문서가 아니고
- 비즈니스와 프로덕트 관련 요구 사항에 대한 종합 문서이기 때문
- 모든 버전과 기록이 종합되고 모두가 열어보는 한 문서
- 목적
- 문서를 쓰게 된 목적
- 프로젝트의 목적이 아님(언급은 될 수 있음)
- 이 문서를 통해 어떤 것을 싱크할 건지
- 배경
- 원칙
- 가령, 쿠팡의 경우 셀러와 구매자 간의 이해관계가 충돌할 때, 우리는 엔드유저인 구매자를 최우선으로 고려한다는 원칙을 세우면, 나중에 비슷한 문제가 발생했을 때 원칙에 따라 처리할 수 있음
- 없을 수도 있지만 대부분 한 개 이상은 필요함
- 고객은 누구이며, 그들은 무엇을 원하는가?
- Customers Hire Us
- 어떤 Job을 해결하기 위해 우리를 채용했는가
- 궁극적으로 고객에게 미치는 영향은 무엇인가?
- FAQ + 참고자료
- 불필요한 논의를 줄이고
- 새로운 내용이 논의될 경우 업뎃할 수 있다
- 한 페이지 안에 넣을 수 있도록 간략하게 작성