PRD(제품 요구사항 정의서)의 모든 것ㅣ뜻, 작성 방법, 포함 요소

제품을 책임지는 프로덕트 매니저(Product Manager, 이하 PM)에게는 제품에 대한 이해부터 우선순위를 결정하는 능력, 디자인 및 개발에 대한 지식, 원활한 커뮤니케이션 능력까지 여러 역량이 요구됩니다. 또한 논리적으로 문서를 작성하는 능력도 중요한데요.

이번 글에서는 PM의 주요 업무 중 하나인 PRD(Product Requirements Document, 제품 요구사항 정의서) 작성에 대해 소개하려 합니다.

PRD란 무엇인지, PRD를 작성할 때 포함해야 하는 핵심 요소는 무엇인지 살펴보도록 하겠습니다.

---

PRD(제품 요구사항 정의서)란 무엇인가요?

PRD(Product Requirements Document)는 제품을 만들거나 업데이트하기 위해 기능을 기획하는 단계에서 요구사항을 개괄적으로 설명하는 문서로, 제품 개발 프로세스 전반에 걸쳐 필수적인 중요 문서입니다.

기획 단계에서는 제품의 비전과 전략을 정의하고, 디자인 단계에서는 제품이 사용자 요구 사항을 충족하는지 확인하고, 개발 단계에서는 기능의 목적과 구현을 확인하고, 테스트 단계에서는 제품이 기술 요구 사항을 충족하는지 확인하고, 출시 단계에서는 제품이 시장 혹은 사용자의 의 요구 사항을 충족하는지 확인하는 데 사용됩니다.

PRD를 작성하면 개발팀 및 이해관계자에게 공유하고 제품 개발 프로세스에 참여하는 모든 사람이 제품의 요구 사항을 확인하고 개발에 착수할 수 있도록 합니다.

PRD 작성 방법

구글의 프로덕트 매니저인 Omar Eduardo Fernández(현재는 GitLab에서 PM으로 재직)은 2020년 본인의 블로그에 PRD 작성에 대한 글(How to write a PRD (Product Requirements Document)을 발행했습니다. 이 글은 WHY 기반의 문서 작성 방법에 관해 설명하며, 많은 사람들의 관심을 받았는데요.

이 글에서 Omar Eduardo는 PRD 작성에 대해 몇 가지 핵심이 되는 내용을 말하고 있습니다. 아래 내용은 블로그 원문의 내용을 요약하여 정리한 글입니다.

1. 사용자 문제 및 비즈니스 우선순위 결정의 근거를 포함해 주세요.

PM은 개발할 기능의 우선순위를 명확히 해야 합니다. PRD에 명확한 우선순위를 설정함으로써 PM은 해결 방법에 따른 기능과 디자인을 평가하고 복잡성과 사용자 가치의 균형을 맞추는 데 도움이 됩니다.

PRD에는 개발 프로세스를 고려하여 사용자 문제와 개발 목표를 검토하고, 해결 방안에 대한 내용을 작성해야 합니다. 사용자 조사 결과, 다양한 옵션에 대한 토론과 평가, 기술적 한계, UX 고려 사항, 리소스 및 예산, 타임라인 요구 사항 등이 포함됩니다. 그리고 이 내용은 이해관계자들(개발자, 디자이너, 영업, CX 등등)과 의사 결정권자와 공유하고 진행이 되어도 괜찮은지 의견을 받아야 합니다.

이 내용을 확인받는 이유는 꼭 지금 해결해야 하는 일인지 체크하고, 괜한 시간을 낭비하여서 하지 않아도 될 기능을 개발하는 실수를 피하기 위함입니다.

2. 해결 방안에 대한 세부 정보를 추가하세요.

PRD에는 개발 및 디자인 프로세스를 고려하여 제안된 해결 방안에 대한 세부 정보가 작성되어야 합니다. 이 정보에는 사용자 조사 결과를 확인할 수 있는 문서, 다양한 옵션이나 아이디어에 관해 토론한 회의 내용, 기술적 한계, UX 고려 사항, 리소스 및 예산 제약, 타임라인 요구 사항 등이 포함됩니다. 또한, 다른 팀(혹은 기술)에 대한 종속성 및 관련 링크도 포함되어야 하며, 같이 협업하는 팀원들이 PRD를 이해할 수 있도록 작성되어야 합니다.

3. UX 및 개발 설계 문서를 참조하세요.

PRD는 구축해야 할 기능과 목적을 명확히 하고 개발, UX 디자인 문서를 포함하여 기능이 구축되는 방식을 문서화합니다. 이 단계에서는 고려된 옵션에 대한 피드백을 제공하고 PRD에 설정된 우선순위를 다시 확인합니다. PM은 설계를 마무리할 때, 개발자와 디자이너의 파트너가 되어 우선순위를 명확히 하고 사용자 가치와 복잡한 기능의 균형을 맞추는 부분을 설명할 수 있어야 합니다.

4. PRD를 업데이트하여 기능 범위를 결정하세요.

PRD를 업데이트하여 기능 범위에 대한 결정을 내리고, UX 및 개발 설계 문서와 중복되지 않도록 합니다. 중요한 결정과 절충안, 기술적 고려 사항, 다른 팀에 대한 종속성, 사용자 개인정보 보호 또는 법적 문제 등을 명시하고, 향후 중요한 기능을 활성화하기 위해 특정 버전의 기능을 구축하기로 한 경우에도 기록합니다.

5. 다른 사람들과 공유하여 의견을 구하세요.

PRD와 필수 변경 사항을 자주 공유하여 다른 사람들의 의견을 구하는 것이 중요합니다. PRD에 대한 의견을 구하기 위해 관련 이해관계자와 상호작용하고, 업데이트 사항을 빠르게 공유하여 누락된 사항을 고려할 수 있도록 합니다. 이를 통해 PRD의 결정된 내용과 근거를 빠르게 확인하고, 의견을 나눠 장단점을 고려할 수 있습니다.

6. 개발 중에도 PRD를 계속 업데이트하세요.

개발 중에는 종종 기능 범위와 타임라인 사이에서 절충안, 타협점을 찾아야 할 때가 있습니다. 일반적으로 개발 주기 동안 범위를 줄여야 고객에게 기능의 중요한 부분을 빠르게 출시할 수 있습니다. PRD를 계속 업데이트하고 타임라인 및 범위에 대한 중요한 업데이트를 다른 팀과 공유하세요. 이를 통해 팀은 능동적으로 계획하고 빠르게 문제를 해결할 수 있습니다.

_{(출처 : How to write a PRD (Product Requirements Document)}

PRD 구성 요소 7

일반적으로 PRD에는 아래 7가지 내용이 포함됩니다. PRD에 포함되어야 하는 구성 요소는 개발 범위와 회사마다 차이가 있을 수 있습니다. 해야 할 일이 명확하고 이해관계자들과 합의가 잘 되어있다면 반드시 모든 요소를 포함할 필요는 없습니다.

1. 제품 개요(요약과 배경)

제품의 목적, 해결해야 할 문제에 대한 요약, 왜 이 문제를 해결해야 하는지 근거를 작성합니다. 기획, 개발의 중요성을 강조할 수 있는 근거 데이터(설문조사, 인터뷰, 지표)를 참고하면 좋습니다.

최근 몇 달간 사용성에 대한 이슈가 있거나, VOC 내용에 반복적으로 나오는 키워드들을 데이터로 정리할 수도 있습니다. 혹은 신규 개발의 경우 시장의 상황이나 변화, 경쟁사의 제품의 성장 등을 추가할 수 있습니다.

2. 비즈니스 목표 혹은 지표

제품을 개발하는 이유와 기대되는 비즈니스 성과, 제품이 달성해야 하는 비즈니스 목표로 사용자가 제품을 사용함으로써 달성하고자 하는 비즈니스 결과를 작성합니다. 현재 시점의 데이터와 예상 가능한 데이터를 비교할 수 있도록 작성하는 것이 좋습니다.

1. 비즈니스 목적 분석 : 먼저 비즈니스가 달성하고자 하는 목표를 분석합니다. 예를 들어, 매출 증가, 시장 점유율 확대 등이 될 수 있습니다.
2. 키 성과 지표(KPI) : 비즈니스 목표에 따라 측정 가능한 KPI를 식별합니다. 예를 들어, 매출 증가를 목표로 한다면 매출 증가율, 고객 당 평균 거래 금액, 신규 고객 유입 비율 등을 KPI로 사용할 수 있습니다.
3. 목표 수치 설정 : 각 KPI에 대해 목표 수치를 설정합니다. 예를 들어, 매출 증가율을 10%로 설정할 수 있습니다.

3. 핵심 고객 또는 사용자 정의

고객 및 사용자는 제품 기획에서 항상 중심이 되는데요. 우리 제품을 사용할 사용자에 대해 정의합니다.

제품에 다양한 기능이 있을수록 사용자는 세분화할 수 있습니다. 신규 개발이 되었을 때 갈증이 해소될 사용자가 어떤 문제와 어려움을 겪고 있는 사용자인지 분명하게 기술합니다. 아래와 같은 방법으로 사용자를 정의하는 방법도 있습니다.

4. 핵심 사용자 여정(Critical User Journeys, CUJ)/사용자 스토리(User Story)

신규 개발 후 3번에서 정의한 사용자가 목표한 달성할 수 있는지 작성합니다. CUJ는 사용자의 문제와 필요에 집중하여, 사용자가 제품 또는 서비스를 사용할 때 가장 중요한 요소를 파악하고 해결하는 데 도움이 됩니다.

이 때 중요한 건 사용자 요구에 집중하며, 해결 방안에 집착하지 않는 것입니다. 특정 해결 방안이나 기능에만 집중할 경우, 근본적인 문제 해결과 멀어질 수 있습니다. 핵심 사용자 여정은 문장으로 작성할 수도 있지만, 사용자 여정 지도와 같은 시각화된 자료로 만들기도 합니다.

사용자 그룹 선택/핵심 시나리오 선정/사용자 시나리오 작성/문제 해결 방법 작성/추가 정보 및 대안 작성과 같은 내용이 포함됩니다.

사용자 스토리(User Story)란?

User Story는 사용자가 제품 또는 서비스를 이용할 때 생기는 상황, 목적, 요구사항 등을 간결하고 명확하게 표현한 문장입니다.

“(고객/사용자 유형)은 (목적/목표)를 위해 (필요/욕구)를 원한다” ”(고객/사용자 유형)쇼핑을 자주 하는 나는, (목적/목표)결제 정보를 저장하여 매번 새롭게 정보를 다시 입력할 필요 없이, (필요/욕구)빠르게 결제할 수 있기를 원한다.”

이렇게 작성된 유저 스토리는 제품 또는 서비스를 개발할 때 사용자 중심으로 기능을 설계하고 개발할 수 있도록 도와줍니다.

5. 기능적 요구 사항

제품 또는 서비스에서 수행되어야 하는 특정 작업이나 기능에 대한 내용을 작성하고, 제품이 제공해야 하는 기능과 우선순위를 표시합니다. 이는 개발 과정에서 매우 중요한데요. 명확하게 정의된 요구사항은 팀 간의 의사소통을 원활하게 하며, 제품이나 서비스의 품질을 높이는 데 큰 역할을 합니다.

기능적 요구 사항은 아래 내용과 같이 우선순위를 표시하여 작성합니다. PM이 단독으로 작성하는 것보다, 개발자와 소통하며 작성하는 것이 좋습니다.

1. 먼저 대상 사용자를 정합니다. 예를 들어, 음식 주문 앱의 사용자라면 “음식을 주문하려는 사용자”가 됩니다.
2. Must Have는 반드시 구현되어야 하는 기능으로, 해당 사용자가 해당 기능 없이는 앱을 사용할 수 없다는 것입니다. 예를 들어, 음식 주문 앱에서는 메뉴를 선택하고 주문을 결제하는 것이 Must Have가 될 수 있습니다.
3. Should Have는 반드시 필요한 것은 아니지만, 해당 사용자가 매우 필요하다고 생각하는 기능입니다. 예를 들어, 음식 주문 앱에서는 메뉴를 검색할 수 있는 기능이 Should Have가 될 수 있습니다.
4. Could Have는 선택적인 기능으로, 해당 사용자가 원한다면 사용할 수 있는 기능입니다. 예를 들어, 음식 주문 앱에서는 특정 음식점의 할인 정보를 확인할 수 있는 기능이 Could Have가 될 수 있습니다.

6. 프로젝트 일정 및 배포 계획

제품 개발 및 출시 일정을 작성합니다. 일정은 PM 혼자서 세우는 것이 아니기 때문에, 함께 개발해야 하는 팀원들과 이해관계자, 의사 결정권자와 소통하며 일정을 세워야 합니다.

기능 출시와 관련된 여러 고려 사항과 마케팅, 영업, CS 부서가 출시 일정에 맞춰 각 팀의 업무를 준비할 수 있도록 일정에 대한 논의가 되어야 합니다.

7. 기타 참고 문서

와이어 프레임, 스토리보드, UX 리서치 결과 등등이 첨부되면 좋습니다. 또한 트렌드를 확인할 수 있는 레퍼런스 자료들도 첨부합니다. 이러한 자료들은 문제를 해결하는 방법에 도움이 될 수도 있고 설득력 있는 자료로 쓰일 수 있습니다.

이외에도 PRD 문서에는 다양한 정보를 포함할 수 있습니다. 팀/팀원의 이름, 진행 상태, 투자 가치 여부, 정책에 관련된 내용, Q&A를 추가할 수 있으며 개발 단계나 난이도에 따라 더욱 간략하게 작성할 수도 있습니다.

전반적으로 잘못 작성된 PRD는 지연, 잘못된 커뮤니케이션, 타겟 고객의 요구를 충족하지 못하는 제품으로 이어질 수 있습니다. 제품의 목적, 요구 사항 및 개발 일정을 명확하게 설명하는 동시에 모든 관련 이해 관계자의 피드백과 의견을 통합하는 PRD를 신중하게 작성하는 것이 중요합니다.

_{글 함윤제 Product Manager (PM 부트캠프)
편집 조주연 Content Manager}

---