PRD 작성법과 샘플 템플릿
What is Product Requirements Document?
Editor's Note : 본 글은 유튜브의 프로덕트 헤드가 검수한 글입니다.
당신이 만약 PM이라면, 또는 PM이 되길 바라는 사람이라면, 아마 우연히라도 Product Requirements Document(이하 PRD)라는 표현을 들어봤거나, 이미 작성해봤을 수 있다.
혹은 이미 아주 많이 써본 상태에서 미세한 스킬 업그레이드를 원하는 중일 수도 있다.
PRD의 목적은 아이디어에서 액션으로 이어지게 하는 것이다. 이 글에서는 PRD가 꼭 포함해야 하는 것을 포함하여, 단계별 가이드와 함께, 바로 적용해볼 수 있는 템플릿을 제공하고자 한다.
PRD란 무엇인가?
PRD란, 목적, 기능 등, 제품에 반영되길 원하는 요구 사항을 담은 가이드다.
이 가이드는 기본적으로, 무엇을 만들고자 하는지, 누구를 위한 것인지, 엔드 유저에게 어떻게 가치를 제공하는지와 관련하여 소통하고자 PM이 만드는 문서다.
물론 비즈니스 팀, 테크니컬 팀이 해당 문서를 바탕으로 제품을 개발하고, 런칭하고, 시장에 적용시킬 수 있도록 지침이 되어준다.
Minal Mehta(Head of Product of YouTube)는, PRD는 프로덕트의 라이프사이클에 따라 지속적으로 업데이트 관리가 되어야 하는 살아있는 문서라고 말한다.
PRD의 내용
Title
- 이 프로젝트의 이름
Change History
- 이 PRD에 그동안 반영된 변경 사항 히스토리. 누가/언제/무엇을 바꾸었는지
Overview
- 이 프로젝트는 무엇을 위한 것인지, 왜 하려 하는지
Success Metrics
- 이 프로젝트가 잘 진행되었는지 알 수 있는 성공 지표
Messaging
- 이 기능을 고객들이 어떻게 인지하게 할 것인지에 대해 마케팅팀이 사용할 이름/표현 등
Timeline/Release Planning
- 전반적인 작업 스케줄이 어떻게 되는지
Personas
- 이 제품의 타겟 페르소나
User Scenarios
- 다양한 유저들이 이 제품을 어떤 맥락에서 어떻게 사용하게 될지와 관련한 시나리오
User Stories/Features/Requirements
- 제품에 담긴 기능들 가운데 중요한 순서와 함께, 왜 그 기능이 더/덜 중요한지에 대한 짧은 설명
Features Out
- 명확히 배제해야 하기로 결정한 요소가 있다면 무엇이고 이유는 무엇인지
Designs
- 기초적으로 필요한 스케치. 추후 실제 디자인이 디벨롭되어 감에 따라 해당 디자인을 볼 수 있는 링크 삽입
Open Issues
- 조금 더 알아봐야 하는 요소
Q&A
- 궁금해할 만한 질문들과 그에 대한 답변. 핵심 의사 결정 사항에 대해 전달할 수 있는 좋은 항목
Other Considerations
- 기타 모든 것. 스코프를 나눈 방식과 이유 등.
처음에 PRD를 작성할 때는, 아직 구체화되지 않은 부분들이 충분히 있을 수 있기에, TBD로 써놓거나 하는 것이 있어도 괜찮다.
PRD 작성 단계
Step 1 - 초안 작성
- 초안은 공개된 공간보다 Private한 곳에 먼저 쓰는 것도 좋은 방법이다. 아직 명확하지도 않고, 틀렸을 수도 있는 정보에 따라 동료들이 오해할 수도 있기 때문이다.
- TBD가 있어도 괜찮다. 보통 백그라운드, 목표, 성공 지표, 핵심 고객 시나리오 등은 MVP보다는 더 높은 완성도를 가진 기능에 기반해서 생각하는 경우도 많기 때문이다.
Step 2 - 승인 받기
초안을 바탕으로 상사의 승인을 받는다. 팀 동료나 상사는 당신의 자산이다. 사용해라.
- 그들의 피드백을 받아라.
- 당신보다 더 오래 그곳에 있었던 사람들은 당신이 알기 어려운 인사이트를 가지고 있을 수 있고, 때로는 관련된 잠재적인 어려운 부분들을 다루는 좋은 방법을 제시해 줄 수도 있다.
- 당신의 상사가 당신이 하는 일에 대해서 당연히 알아야 하기 때문도 있다.
Step 3 - 디자인팀과 공유
디자인팀 리더와 PRD를 공유하고, 그들의 피드백을 반영한다.
- 디자인은 고객에게 가까운 툴이다. 또한 디자인은 기술 작업 범위에도 영향을 미칠 수 있기 때문에, 엔지니어에게 가기 전에 디자인 팀을 개입시키는 것이 현명한 방법이다.
- 그들의 피드백을 반영하고 스펙을 논의한다. 이때, 디자인팀에게 당신의 생각을 강요하지 말아야 한다. 충분히 듣기.
Step 4 - 개발팀과 공유
개발팀 리더와 PRD를 공유하고, 그들의 피드백을 반영한다.(이때 디자인팀 리드도 함께하는 것이 좋다.)
- 디자인팀 리드와 함께, 개발팀 리드의 피드백을 받는다.
- 이 과정을 통해, PRD 상의 기능의 타당성을 확인하고, 대략적인 난이도/시간 소요 등을 확인할 수 있다. 또한 목적을 달성하는 다른 솔루션을 제안받을 수도 있다.
Step 5 - 프로젝트팀과 공유
당신의 프로젝트 팀과 공유한다.
- 다듬어진 PRD 문서를 이제 공개적인 곳에 올리고, 구성원들이 볼 수 있게 한다.
- 그들의 질문들과 가용 리소스 등을 확인한 뒤 PRD에 반영한다.
- 좋은 아이디어가 나온다면 기록한다. 이번 초기 스코프에 반영되기 어렵더라도 적어두고 추후 살펴볼 수 있도록 한다.
Step 6 - 회사와 공유
가능하면 회사와도 공유한다.
- 아마 이때에는 PRD 문서가 아닌 프레젠테이션을 할 것이다.
- 무대에서 PRD 문서를 줄줄 읽는 것은 당연히 아니고, 새로운 표현 양식을 준비해서 진행해야 할 것이다.
PRD 템플릿
세가지 포맷의 템플릿이 준비되어 있다. Google Docs, Coda, Mural이고, 모든 템플릿은 실제 PM들의 검수를 받았다.
1. Google Docs
2. Mural
3. Coda
주요 유의 사항
1. PRD는 살아있는 문서다.
: 꾸준히 헙데이트 하자
2. 유연해야 한다.
: 처음 쓸 때 TBD 쓰는 것을 두려워 말자
3. 간결/명확해야 한다.
: 핵심 결정, 관련 링크 등을 잘 남기자. 해석의 여지를 주지 말자
4. 협업의 산물이다.
: PM이 제품에 대해 오너십을 가지지만, PRD는 PM만의 일이 아니다.
5. 소통에 사용한다.
: PRD는 뽐내기 위함이 아니다. 소통을 위한 수단이다.
본 글은 아래 영문으로 된 원문을 국문으로 번역한 글입니다.
https://productschool.com/blog/product-management-2/product-template-requirements-document-prd/
*번역시 주의한 부분
chances are that : ~할 가능성이 있다. 본래 Chances that~ 인 주어절인데, 주어가 길어지기 때문에 분리.
