좋은 제품을 만들기 위한 PRD 작성법과 샘플
PRD는 어떻게 작성하는게 좋을까?
개인적으로 PM, PO로 일하면서 얻고 싶은 경험은 지속적으로 고객들에게 사랑받는 좋은 프로덕트를 만드는것이라 생각한다.
그러기 위해서 우리는 오늘도, 내일도 끊임없이 프로덕트를 만드는 전쟁터의 최전선에서 많은 사람들과 의사소통하며 고통(?)을 받고 있는게 아닐까 생각한다.
그렇다면 좋은 프로덕트는 어떤 과정을 통해 만들 수 있을까?
프로덕트를 만들때 가장 시간을 많이 들여야하는것은 '문제정의'라고 생각한다.
문제가 제대로 정의되지 않으면 고객의 본질적인 문제를 해결하기 힘들고 잘못된 문제정의 또는 아예 문제정의를 하지 않는다면 누군가의 뇌피셜로 필요해보이는 기능을 덕지덕지 붙이게 되고 결국 고객이 원하지 않는 기능을 출시하여 프로덕트 퀄리티를 낮추게 되며 시장에서 도태되는 프로덕트, 아무도 찾지 않는 프로덕트를 만들 가능성이 매우 높다.
좋은 제품을 만들어도 시장에서 살아남기란 정말 힘들다...대다수의 IT 기업들이 워터폴보단 애자일 방식으로 업무를 하고 있기 때문에 정해진 기능에 따라 와이어프레임, 스토리보드를 작성하기보단 PRD를 바탕으로 상황을 분석하고 문제정의부터 논리와 근거를 쌓아가는 방식으로 업무하는 추세인 것 같다.
그러면 우선 PRD가 어떤 문서인지 알아보자
1. PRD가 뭐에요?
PRD(Product Requirements Document)는 서비스 또는 프로덕트를 만들 때 어떤 문제를 해결하고 어떤 기능을 제공하며 어떤 방식으로 운영할 것인지를 정리한 문서이다.
"이전에 기획자들이 작성하던 '요구사항 정의서'랑 같은거 아닌가?" 라고 생각할 수 있지만 요구사항 정의서와 달리 프로덕트를 만드는 과정 전반에 걸쳐 다양한 이해관계자들과 제품 팀원들에게 공유해야 할 내용을 포함하고 있다.
왜 PRD를 작성해야할까?
1) 스프린트 기간동안 중심축 역할
- 여러 이해관계자(경영진, 기획, 디자인, 개발, 마케팅 등)가 모두 같은 목적을 가지고 프로덕트의 문제를 해결할 수 있도록 중심을 잡아주는 역할을 한다.
- 스프린트 중간중간에 의사결정이 필요할 때, PRD에 명시된 목표와 요구사항을 기준으로 삼으니 판단이 빨라진다.
2) 의사소통 비용 절감
- "어떤 목적으로 무엇을 만들고 이 요구사항이 왜 필요한지"가 정리되어 있어 불필요한 회의나 혼선이 줄어든다.
- 각 팀원(혹은 외부 협력사)에게 동일한 정보를 제공함으로써, 협업 과정에서 발생하는 혼선을 최소화한다.
3) 목표 및 일정 관리에 용이
- PRD에 명시된 핵심 목표, 우선순위, 마일스톤 등을 통해 팀 전체가 동일한 일정을 바라보고 움직일 수 있다.
- 프로젝트가 진행되면서 생기는 여러 돌발 상황(기능 추가, 이슈 발생 등)에도, PRD를 기준으로 일정 및 우선순위를 재설정하기 쉬워진다.
4) 리스크를 사전에 줄일 수 있음
- "Must-have"와 "Nice-to-have" 기능을 구분해두면, 갑작스런 범위 변경이 생겨도 빠르게 대응 가능하다.
- 초기 기획 단계에서 비즈니스 가치, 기술 난이도, 사용자 니즈 등을 검토해두면, 일정 지연이나 예산 초과 등 리스크를 미리 식별할 수 있다.
5) 지속적인 개선과 업데이트 가능
- PRD는 한 번 쓰고 끝나는 정적 문서가 아니라, 제품이 진화하면서 계속 업데이트되는 '살아있는 문서'다.
- 개발·운영 중 발생하는 변경사항을 PRD에 반영해두면, 나중에 회고나 후속 프로젝트 진행 시에도 참고하기 용이하다.
6) 신규 팀원 온보딩에 효과적
- 새로 합류한 팀원이 "우리 제품은 왜, 누구를 위해, 무엇을 만드는지"를 빠르게 파악할 수 있는 가이드 역할을 한다. (프로덕트를 막 만들기 시작한 단계에서는 One pager의 역할을 하기도 한다.)
- 필요 기능과 기술 스택, 디자인 가이드를 체계적으로 정리해두면, 온보딩 시간이 단축되고 팀워크 형성에도 도움을 준다.
PM이면 이렇게는 일하지 말자...2. PRD는 어떻게 작성하는거에요?
PRD는 모든 기업, 모든 팀이 같은 템플릿을 쓰지 않기에 정답이라고 할 문서는 없다.
그렇지만 핵심적으로 담겨야 할 내용은 비슷하기 때문에 여기서 설명하는 모든 내용들 포함하진 않아도 되고 각 회사의 상황에 맞게 수정하면 된다.
1) 개요(Overview)
우리 프로덕트에 어떤 문제가 있는지, 이를 해결하기 위해 무엇을 할것인지 간략하게 배경과 목적을 작성한다.
주로 이 프로덕트(또는 기능)을 왜(Why) 만드는지, 마주한 문제를 어떻게 해결할 수 있는지를 작성하여 팀원들이 모두 같은 이해도를 가지고 진행할 수 있도록 설명해야한다.
예시) 장바구니 이탈률 개선 프로젝트
1. 개요(Overview)
발견된 문제
최근 사용자 데이터(Analytics)를 분석해보니, 장바구니에 상품을 담은 후 결제까지 진행하지 않고 이탈하는 비율이 50% 이상으로 높게 나타남.
이커머스 전체 지표(전환율) 저하와 매출 손실로 이어지고 있음.
개선 방향
장바구니~결제 과정을 UX/UI 측면에서 간소화하고, 결제 직전 프로세스(쿠폰 적용, 배송지 선택 등)를 개선하여 장바구니 이탈률을 낮추고 구매 전환율을 높이는 것이 목표.
2) 목표(Goals)
나의 경우 목표를 작성할때는 크게 3가지로 나눠서 작성한다.
Business Goals, User Goals, Non-Goals 로 나누는데 이렇게 해두면 팀원들과 의사결정할때 기준으로 삼을 수 있다.
Business Goals 에는 주로 회사의 KPI와 연관지어 '매출 증가', 'MAU', 'Retention' 등의 지표를 목표를 두고 작성한다. (OKR이 있다면 거기에 맞추면 되고 그게 아니라면 경영진들이 원하는 비즈니스 목표에 맞춰서 향상 시켜야하는 지표를 작성하면 된다.)
예시 1: 신규 기능 론칭 후 3개월 내 MAU 50% 증가
예시 2: 신규 판매 채널 확보를 통해 분기별 매출 10% 증가
"단순히 숫자만 높이자" 라는 메시지보다 "특정 지표를 어떤 방식(신규 기능/마케팅/제품 개선 등)으로 언제까지 달성할 것인지"가 명확해야 팀원들이 이해하고 움직이기 쉽다.
Business Goals는 회사 전체의 성장을 견인하는 것이므로 다양한 부서와 협업이 필요할 수 있다. 부서별·직군별로 협의하여 모든 이해관계자가 공감대와 책임을 갖도록 하는 것이 중요하다.
User Goals 에는 이 프로젝트(또는 기능)을 통해서 우리의 고객이 어떤 가치를 얻을 수 있는지를 작성한다. 주로 UX와 연관된 목표들이 포함된다. 예를 들어 "A 과정을 간편화해 유저가 원하는 정보를 빠르게 찾을 수 있도록 한다"처럼, 사용자 관점에서 작성해야 한다.
예시 1: "1분 이내에 사용자가 원하는 상품을 찾을 수 있게 UX 간소화"
예시 2: "사용자가 서비스 첫 화면에서 주요 기능을 파악하도록 UI 개선"
User Goals가 충족되지 않으면, 아무리 Business Goals(매출, 트래픽 등)가 달성된다고 해도 장기적인 사용자 만족도나 제품 경쟁력이 떨어지게 된다.
실제 사용자 피드백, 사용자 조사(인터뷰, 설문, 현장 관찰 등) 등을 통해 정량적·정성적 인사이트를 얻어두면 User Goals 설정이 훨씬 명확해진다.
User Goals를 통해 사용자 중심 의사결정을 할 수 있게 되며 장기적으로 제품 품질과 브랜드 이미지를 향상시키는 데 크게 기여할 수 있다.
Non-Goals는 우선순위가 낮거나 이번 프로젝트 범위에 포함되지 않는 목표를 적는다.
"이것까지 하게 되면 너무 범위가 커진다"
"이번에는 중요한 지표와 직접적 연관성이 없다"
"추가적인 R&D 시간이 필요한 기능이다"
이런 식으로 분류해두면 이후 이슈가 발생했을 때 빠른 의사결정이 가능하다. "이건 Non-Goals에 들어가 있으니 현재 리소스는 중요한 기능 구현에 집중하자"와 같이 모두가 합의한 기준을 바탕으로 의사결정할 수 있다.
Non-Goals에 작성된 내용들은 대부분 백로그 형태로 기록해두면 다음 Task로 고려할 수 있다.
다만 목표를 작성할때는 너무 많지 않되, 수치를 포함하여 구체적으로 2~3개만 작성하여 집중할 수 있도록 하고 지표간에 충돌이 발생하여 고객경험이 헤쳐지지 않도록 하는것이 중요하다.
목표가 불명확하면 프로젝트는 산으로 간다.2. 목표(Goals)
Business Goals
- 장바구니→결제 단계 전환율을 10% 이상 개선해, 월 매출 5% 추가 상승 기대.
- ‘주문 완료’까지의 프로세스 간소화로 고객 만족도(재구매율) 향상.
User Goals
- 불필요한 입력 단계나 복잡한 UI로 인해 결제를 포기하는 사용자를 줄인다.
- 결제 전 할인/쿠폰 정보를 직관적으로 안내해, 사용자 편의성 및 혜택 인지도를 높인다.
Non-Goals
- 새로운 상품 카테고리 확장(이번 프로젝트는 장바구니 UX 개선에 집중)
- 글로벌 배송 기능(향후 다른 프로젝트에서 검토)
3) 사용자 시나리오(User Scenarios)
사용자 관점으로 구체화하기 위해서는 시나리오가 필요하다. 기능이 추가 됐을때 고객들이 어떻게 사용할지 예상할 수 있고 그 과정에서 고려해야하는 UX가 무엇인지를 알 수 있다. 또한 이를 바탕으로 엔지니어들은 예외 케이스를 찾아낼 수 있어 좀 더 안정적인 프로덕트를 만들 수 있도록 돕는 역할을 한다.
3. 사용자 시나리오(User Scenarios)
페르소나
- 20대 후반 직장인 B, 평소 쇼핑 앱으로 의류·화장품을 자주 구매함.
- 장바구니에 2~3개 상품을 담아두고, 밤에 한꺼번에 결제하는 습관이 있음.
시나리오
1) B가 상품을 장바구니에 추가 → 장바구니 페이지로 이동.
2) 이전에는 배송지, 쿠폰 적용, 결제 수단 선택 등이 각각 별도 화면으로 분리돼 번거로웠음.
3) 개선 후, 장바구니 페이지에서 배송지·쿠폰·결제수단을 한눈에 확인/설정 가능.
4) 결제 화면에서 추가 할인 혜택 안내 메시지를 보고, 즉시 결제 진행.
5) B는 2~3분 만에 결제를 완료, 결제 완료 화면에서 배송 예정일과 주문 내역을 확인.
*예외 상황: 결제 실패 시 재시도 안내, 쿠폰 만료 알림, 미리 등록해둔 결제수단이 유효하지 않을 경우 대체 수단 안내 등.
4) 성공 지표(Metrics/KPIs)
프로젝트가 끝난 뒤, 우리가 도입한 기능이나 서비스가 실제로 어떤 성과를 냈는지 확인하고 회고하기 위해서는 명확한 성공 지표가 필요하다.
예를들어 "고객이 이 기능을 얼마나 자주 이용하는가?" "우리 매출에 얼마만큼 기여하는가?" "서비스 평판은 어떻게 달라졌는가?" 등 구체적인 수치와 데이터를 통해 성공 여부를 파악할 수 있어야 한다.
단순히 '지표 수치'만 확인하는 것이 아니라 지표별 목표치를 사전에 설정해두고 그 원인과 인사이트를 찾는 것이 중요하다.
성공 지표: "도입 후 3개월 이내에 일일 활성 사용자(DAU)가 30% 상승"
결과 회고: "DAU가 25% 상승에 그쳤다면 왜 목표에 미치지 못했는가? 사용자 유입 프로세스가 불편했는지, 프로모션이 부족했는지, UI/UX 개선이 더 필요했는지 분석하고 학습한다."
4. 성공 지표(Metrics/KPIs)
- 장바구니→결제 전환율: 기존 45% → 55% 이상 달성.
- 주문 완료까지 평균 소요 시간: 기존 대비 30% 단축 (현재 평균 4분 → 3분 이하 목표).
- 장바구니 내 쿠폰 사용률: 기존 20% → 30% 이상 (UX 개선으로 할인 혜택 알림을 적극 안내).
5) 핵심 기능 목록(Features & Requirements)
프로젝트에서 모든 기능을 다 개발하면 좋겠지만 보통 스프린트라는 제약된 일정과 리소스에서 진행하기 때문에 기능은 우선순위를 3가지로 나눠 분류한다.
Must Have
- 필수조건, 반드시 구현되어야 하는 기능
- 이 기능이 없다면 제품/서비스의 핵심 가치를 전달할 수 없음
Should Have
- 필요조건, 매우 필요하다고 생각하는 기능
- 사용 편의성을 높이거나 핵심 프로세스 효율화를 위해 필요한 요소
Could Have
- 선택조건, 사용자 만족도를 높일 수 있으나, 반드시 필요한 것은 아님
- 일정과 리소스에 여유가 있을 때 추가적으로 개발할 기능
해결해야하는 문제에 따라 Must Have, Should Have까지는 포함되고 여유가 된다면 Could Have까지 개발하기도 한다. 문제를 해결하기 위해 필요하다고 생각하는 기능을 모두 리스트업한 후에 목표에 따라 기능별 우선순위를 매기고 팀의 속도에 따라서 Could Have까지 진행해도 되고 백로그로 남겨도 된다.
5. 핵심 기능 목록(Features & Requirements) - 보통 표로 작성
단일 페이지 장바구니 UI (Must Have)
- 배송지, 쿠폰, 결제수단 등을 단일 페이지에서 처리
자동 쿠폰 적용 & 알림 (Must Have)
- 사용 가능한 쿠폰이 있으면 자동 적용 후 할인 금액 표시
배송지 간편 편집/선택 (Should Have)
- 최근 사용 배송지 불러오기, 자동 완성 기능
결제 수단 우선순위 설정 (Should Have)
- 등록된 여러 결제수단 중 기본값을 선택, 실패 시 다른 수단 안내
추가 할인 혜택 소개(팝업/배너) (Could Have)
- 카드사 제휴나 한정 프로모션을 안내 (사용자 선택 유도)
6) 기술 요구사항(Technical Requirements)
프로젝트를 진행하는 과정에서 외부 API, 시스템, 클라우드 서비스, 데이터베이스 인프라, 보안 규칙 등 기술적인 의사결정이 필요한 순간들이 많다. 이때는 관련 내용을 사전에 충분히 리서치하고 문서화해두면, 엔지니어들과 긴밀하게 협의할 수 있어 개발 리스크를 크게 줄일 수 있고 필요한 일정을 빠르게 파악할 수 있다.
외부 서비스를 이용하게 되면 제약사항도 생기고 경우에 따라 개발 스펙 자체를 조정해야하는 경우도 생기기 때문에 반드시 사전에 리서치하고 커뮤니케이션 하는게 중요하다. (QA 엔지니어와 커뮤니케이션 하는 과정에서도 반드시 필요하다.)
그냥 해줘.6. 기술 요구사항(Technical Requirements)
외부 결제 서비스(PG사) 연동 개선
- 현재 사용 중인 PG사가 결제 토큰(간편결제) 기능을 지원하는지 확인 필요
- 자동 쿠폰 적용 로직과 결제 프로세스를 통합할 때, PG사 API 호출 시점이 달라질 수 있으므로 개발팀과 사전 협의
계정/쿠폰 데이터 관리
- 쿠폰/적립금 정보가 외부 CRM 시스템에서 연동되는 구조 → CRM API 응답 시간, Rate Limit 등 체크
- 기존 DB 스키마(장바구니 테이블)에 배송 옵션·할인 정보 컬럼 추가 필요
백엔드 로직/서버 부하
- 장바구니 페이지가 단일 페이지로 합쳐지면서 API 호출이 늘어날 수 있음 → Redis 캐싱, DB 인덱스 최적화 등으로 대응
- 주문/결제 완료 시 푸시 알림(Push 서비스) 연동 체크
QA 및 장애 대처
- 모바일(안드로이드/iOS) 환경 별 테스트, 웹 브라우저(Chrome/IE/Edge 등) 호환성 테스트
- 결제 모듈 장애 발생 시 이벤트 롤백 절차, 사용자 재시도 프로세스 문서화
7) 일정 계획(Timeline) 또는 목표일(Target date)
프로젝트 진행 시 세부적인 일정은 보통 스프린트 플래닝에서 최종적으로 결정하지만 때로는 경영진과 협의된 날짜나 마케팅 일정 등에 맞추어 출시해야 하는 경우가 있다. 비즈니스와의 연관성을 고려하여 중요한 이정표(Milestone)나 목표 일정을 간단히 명시해두면 팀원들에게 설명할때도 여러모로 도움이 된다.
일정에 따라 개발 범위가 조정될 수 있으니 경영진과 최대한 많이 소통하여 주요 일정에 변동이 있는지 체크하도록 하자.
7. 일정 계획(Timeline) 또는 목표일(Target Date)
비즈니스 일정 & 이벤트
- 다음 달 말(예: 4월 말)에 봄맞이 프로모션 캠페인 예정: 이 시점에 맞춰 장바구니 개선 버전 런칭 권장
- 마케팅 팀에서 쿠폰 대규모 발행 이벤트(“봄 세일”)도 준비 중 → 쿠폰 자동 적용 로직 출시 타이밍이 중요
*주의사항
- 외부 CRM(쿠폰) API 연동 시 예상보다 지연 가능(담당 부서 일정 확인 필요)
- 마케팅 캠페인 일정(봄맞이 프로모션)이 바뀌면 전체 일정 재조정
8) 예상 질문(Q&A)
프로젝트나 기능 기획을 정리한 PRD를 읽다 보면 문서를 읽는 팀원, 경영진 등 들이 궁금해할 만한 질문이 자연스럽게 생긴다. 이때 자주 나올 법한 질문과 해당 질문에 대한 답변을 미리 문서에 작성해두면 커뮤니케이션을 효율적으로 진행할 수 있다.
스스로 작성한 문서를 보고 예상 질문에 대한 내용을 추가하다보면 '본문에 적는게 좀 더 명확하겠다' 같은 생각을 할 수 있어 전체적으로 문서가 탄탄해지는데 도움이 된다.
8) 예상 질문(Q&A)
Q: 장바구니 개선 후 기존 UI를 사용하고 싶은 사용자는?
A: A/B 테스트 기간에는 50%만 개선 UI 노출, 이후 전수 적용 예정.
Q: 쿠폰 자동 적용이 유저 선택권을 제한하지 않나?
A: "자동 적용" 후 다른 쿠폰으로 변경 가능한 옵션을 제공, 사용자에게 최종 선택권 부여.
Q: 이번 달 프로모션에도 적용되나?
A: 일정상 이번 달 말에 베타 버전 완료, 내부 리뷰 후 4월 프로모션 시작 전에 정식 배포 목표.
9) 추가 자료(References)
PRD를 작성하면서 참고했던 사이트나 사용자 인터뷰, 시장 조사, 경쟁사 분석 등은 프로젝트의 출발점이자 근거가 된다. 이 자료들을 링크 또는 별첨 형식으로 정리해두면, 프로젝트를 검토하는 모든 이해관계자가 쉽게 배경 지식을 확인하고 논리적 근거를 파악할 수 있다.
마무리하며
좋은 프로덕트를 만든다는 것은 잘 정의된 문제를 적절한 솔루션으로 풀어내는 과정의 연속이다.(문제를 해결하는것엔 정답이 없다)
여기서 PRD라는 문서는 그 과정을 돕기 위한 효율적인 도구이고 나침반이라고 생각한다.
앞서 언급했듯 많은 IT 기업이 애자일 방식을 채택하고 있기에 정해진 기획서가 아니라 진화 가능한 PRD를 더 중요하게 여기는 추세이다.
처음에는 PRD를 작성하는게 어렵고 귀찮을 수 있지만, 한 번 작성해두면 프로젝트가 진행되는 동안 모든 의사결정 과정이 훨씬 수월해질거라고 생각한다.
또한 PRD를 통해서 "문제정의 → 논리와 근거 쌓기 → 구현 → 반복 검증" 이 일련의 과정을 체계적으로 진행하도록 도와주고 요즘 채용공고 JD에서 많이 보이는 문제해결 프로세스를 가장 깊게 고민할 수 있는 부분이 아닐까 생각한다.
결국 지속적으로 고객들에게 사랑받는 좋은 프로덕트를 만들기 위해서는 문제정의부터 탄탄하게 시작해야 하며 그 과정에서 PRD가 큰 역할을 담당한다는 사실을 기억했으면 좋겠다.
