� PRD 작성법
#PRD #PRD작성법
� 한 줄 요약
- PRD는 Product Requirements Document이며, 살아있는 문서다.
✔️ 요새 슬랙에서 많이 오가는 내용이 있는데요. 바로, 'PRD를 확인해주세요.'라는 말이에요. 처음에는 무슨 단어인지, 무슨 말인지 몰랐는데, 반복해서 나오는 단어라 찾아보게 됐어요. 그 결과 'Product Requirements Document'라는 걸 알게 됐어요.
✔️ 사실 저희는 PRD라는 용어는 문서에서만 쓰고, 커뮤니케이션할 때는 AC라는 용어를 더 많이 써요. AC는 그냥 기술문서라고 이해하면 편해요. 솔직히 말하면 PRD 용어만 많이 봤지, 제대로된 개념을 살펴볼 생각을 못한 거 같아요.
✔️ 이왕 이렇게 된 김에 한 번 살펴보자 생각해서 살펴봤는데요. 좋은 아티클이 있어 함께 보면 좋을 거 같아 제가 요약해봤어요.
✅️ PRD란 무엇인가?
▪️목적, 기능, 등 제품에 반영되길 원하는 요구사항을 담은 가이드
✅️ PRD의 내용
▪️Title: 프로젝트 이름
▪️Change History: PRD에 그 동안 반영된 변경 사항과 히스토리, 누가/언제/무엇을 바꿨는지
▪️Overview: 프로젝트는 무엇을 위한 것인지, 왜 하려 하는지
▪️Sucess Metrics: 프로젝트가 잘 진행되었는지 알 수 있는 성공지표
▪️Messaging: 이 기능을 고객들이 어떻게 인지하게 될 것인지에 대해 마케팅팀이 사용할 이름과 표현 등
▪️Timeline/Release Planning: 전반적인 작업 스케줄이 어떻게 되는지
▪️Personas: 제품의 타깃 페르소나
▪️User Scenarios: 다양한 유저들이 이 제품을 어떤 맥락에서 어떻게 사용하게 될 지와 관련된 시나리오
▪️User Stories/Features/Requirements: 제품에 담긴 기능들 가운데 중요한 순서와 함께, 왜 그 기능이 더 또는 덜 중요한지에 대한 설명
▪️Features Out: 배제하기로 한 기능과 그 이유
▪️Designs: 디자인 시안
▪️Open Issues: 추가 확인 사항
▪️Q&A: 핵심 사항과 관련된 질답
▪️Other Considerations: 기타 사항
✅️ PRD 작성 단계
1. 초안
✔️ 명확하거나 정해지지 않은 사항이 있을 수 있기 때문에 개인 공간에 작성하며, 백그라운드, 목표, 성공 지표, 핵심 고객 시나리오 등을 작성한다.
2. 승인 받기
✔️ 상사에게 보고 후 내용을 승인 받는다. 승인 받는 과정에서 피드백을 적극 반영해, 더 나은 내용을 작성한다.
3. 디자인팀 리더에게 공유
✔️ 상사에게 공유한 것처럼 디자인팀 리더에게 공유하고, 충분한 피드백을 받아 반영한다. 이때, 자신의 생각을 강요하는 것이 아니라, 의견을 '충분히' 듣는다.
4. 개발팀 리더에데 공유
✔️ 개발팀 리더에게 내용을 공유한다. 이때, 디자인팀 리더와 함께 내용을 듣고 반영한다. 개발팀 리더의 피드백도 적극적으로 받아 내용에 반영한다.
✔️ 개발팀 리더에게 공유할 때는 PRD 기능 타당성, 대략적인 난이도와 시간 소요 등을 확인한다. 또한, 목적 달성을 위한 추가 솔루션을 받을 수 있다.
5. 프로젝트팀과 공유
✔️ 앞선 팀 리더의 피드백을 모두 반영하고 난 후, PRD 문서를 구성원들에게 공개한다. 이후, 그들로부터 피드백을 받고 가용 리소스 등을 확인해 PRD에 반영한다.
✔️ 좋은 아이디어는 기록해놔야 하는데, MVP 이후에 여력이 남으면 추가하며 디벨롭할 수 있기 때문이다.
6. 회사와 공유
✔️ 회사와 공유한다는 것은 전사 공유를 의미한다. PRD 문서를 있는 그대로 보여주는 것이 아니라, PPT와 같은 형태로 프리젠테이션으로 해야 한다.
✅️ 주요 유의 사항
1. PRD는 살아있는 문서다. 꾸준히 업데이트 해야한다.
2. 유연해야 한다. 처음 쓸 때 TBD(To Be Determined)쓰는 것을 두려워 하지 말아라.
3. 간결하고 명확해야 한다. 핵심 결정, 관련 링크 등을 잘 기록해놔야 한다.
4. 협업의 산물이다. PM이 오너십을 가지지만 PRD는 모두의 자산이다.
5. 소통에 사용한다. PRD는 소통을 위한 수단이다.
