📃 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는 소통을 위한 수단이다.