분석을 마쳤다고 끝이 아니었다.
데이터에서 나온 인사이트를 실제 기획서로 만드는 것 — 오늘은 그 과정 전체를 거쳐 PRD를 완성했다.
분석 → 문제 정의 → 가설 → 해결안 → 기능 명세 → A/B 테스트 설계까지, PM이 기획서 한 장에 담아야 하는 것들을 처음부터 끝까지 정리한다.
1️⃣ PRD란 무엇인가 — 오늘 처음 완성한 기획서
PRD(Product Requirements Document)는 PM이 "왜 이 기능을 만드는가, 어떻게 만들어야 하는가"를 정리한 문서다.
단순한 기능 정의서가 아니라, 데이터 → 문제 → 가설 → 해결 → 검증 계획까지 논리적 흐름이 하나로 이어지는 구조여야 한다.
| 섹션 | 내용 |
|---|---|
| 페르소나 선택 | 왜 이 유저 그룹을 분석했는가 |
| 현황 분석 | 베이스라인 + 핵심 레버 검증 + 세그먼트 분석 |
| 문제 정의 | 데이터 기반 문제 서술 |
| 가설 | 해결하면 어떤 결과가 나올 것인가 |
| 해결 방안 | Before / After + 기능 범위 |
| 목표 (KPI) | Primary / Secondary / 가드레일 지표 |
| 기능 요구사항 | 개발팀에 전달할 기능 명세 |
| A/B 테스트 계획 | 통계 설계 + 성공/실패 기준 |
| 향후 로드맵 | 현재 기능 이후 단계적 확장 방향 |
2️⃣ 문제 정의 — 숫자보다 "구조"를 보는 것
분석이 끝나면 PM이 해야 할 첫 번째 일은 "숫자를 나열하는 것"이 아니라 "왜 전환이 안 되는가"를 구조적으로 설명하는 것이다.
① 전체 미전환 규모 → 개선 대상이 얼마나 큰가
② 핵심 원인 → 리뷰를 보지 못한 채 이탈하고 있다
③ 구조적 문제 → 가장 많은 유입 경로(검색)에서 리뷰 섹션에 도달 전 이탈하는 레이아웃 구조
→ 이 세 가지가 연결될 때 "단순 데이터 나열"이 아니라 "문제 정의"가 된다.
문제 정의는 한 문단으로 쓴다. 수치·원인·구조가 하나의 문장 흐름 속에 자연스럽게 이어져야 한다.
테이블은 보조 자료로, 핵심 내용을 수치별로 나눠서 재확인하는 용도다.
- 누가 얼마나 손실을 보고 있는가 (모수 + 비율)
- 핵심 원인은 무엇인가 (리뷰 미열람, 레이아웃 구조 등)
- 어느 경로·구간에서 문제가 집중되는가 (Search results, 31~51초 이탈 구간)
- 세 가지가 논리적으로 연결되는 하나의 문장 흐름
3️⃣ 가설 수립 — 상관관계와 인과관계를 구분하기
분석에서 "리뷰를 본 유저의 전환율이 높다"는 것을 확인했다.
하지만 이것만으로 "리뷰를 보여주면 전환율이 올라갈 것"이라고 단정하면 안 된다.
상관관계 (데이터로 확인된 것)
리뷰를 클릭한 유저의 전환율이 클릭하지 않은 유저보다 압도적으로 높다.
선택 편향 가능성 (경계해야 할 것)
구매 의향이 원래 높은 유저가 리뷰를 더 많이 보는 것일 수 있다.
→ 리뷰가 전환을 만드는 게 아니라, 살 사람이 리뷰를 보는 것일 수 있음.
인과관계 검증 방법
A/B 테스트 — 리뷰 정보를 강제로 노출한 그룹과 아닌 그룹을 비교해야 한다.
가설은 이 구분을 명시해야 한다. "현재 데이터는 상관관계이며, A/B 테스트로 인과관계를 검증한다"는 문장을 PRD에 명확히 포함했다.
[개입]을 하면 → [대상]이 → [결과]를 보일 것이다
예: 장바구니 버튼 상단에 별점·리뷰 수·구매 만족도를 UX Writing으로 추가하면,
검색 결과에서 유입되어 짧게 머물다 이탈하는 유저가 스크롤 없이도 리뷰 신뢰 정보를 접하게 되어,
고가 상품(30만원 이상)을 조회한 유저들의 장바구니 전환율이 상승할 것이다.
4️⃣ RICE 프레임워크 — 우선순위를 데이터로 결정하기
해결 방법이 여러 개일 때 "어떤 것을 먼저 만들 것인가"를 결정하는 것이 PM의 역할이다.
RICE는 그 판단을 직관이 아니라 데이터로 하는 프레임워크다.
RICE = (Reach × Impact × Confidence) ÷ Effort
| 항목 | 의미 | 점수 기준 |
|---|---|---|
| Reach | 영향받는 유저 수 | 실제 인원 수 (명) |
| Impact | 전환율 개선 기여도 | 1~5점 |
| Confidence | 효과 확신도 | 0~1 (0%~100%) |
| Effort | 개발 난이도 | 1~5점 (높을수록 어려움) |
오늘 PRD에서 RICE를 적용한 결과:
| 개선 레버 | RICE 점수 | 선택 이유 |
|---|---|---|
| ✅ 버튼 상단 리뷰 신뢰 정보 노출 | 656 (1위) | Impact·Confidence 높음 + Effort 가장 낮음 |
| 리뷰 섹션 페이지 상단 이동 | 123 (2위) | 전체 레이아웃 재설계 필요 → Effort 높음 |
| 체류시간 연장 유도 (콘텐츠 강화) | 10.6 (3위) | 효과 인과관계 미검증, Effort 높음 |
| 할인 전략 강화 | 7.7 (4위) | 데이터상 효과 없음이 이미 확인됨 |
각 항목의 점수를 어떤 근거로 매겼는지 반드시 함께 명시해야 한다.
근거 없는 점수는 "그냥 하고 싶은 것을 합리화한 것"처럼 보인다.
내부 데이터 수치 + 외부 연구 레퍼런스를 함께 제시할 때 설득력이 생긴다.
5️⃣ 기능 요구사항 — PM이 개발팀에 전달하는 언어
해결 방안이 정해지면 PM은 그것을 개발팀이 구현할 수 있도록 명세로 변환해야 한다.
"리뷰 정보를 보여주세요"가 아니라, 어떤 데이터를 어떤 형태로 어떤 조건에서 보여줄지 구체적으로 써야 한다.
| ID | 기능 | 상세 조건 | 우선순위 |
|---|---|---|---|
| F-01 | 별점 평균 노출 | 소수점 1자리 / 리뷰 10개 미만이면 미표시 | 필수 |
| F-02 | 리뷰 수 노출 | "리뷰 N개" / 1,000개 이상은 "1,000개+" | 필수 |
| F-03 | 구매 만족도 노출 | "구매 고객 N%가 만족했어요" / 별점 4점 이상 비율 계산 | 필수 |
| F-04 | 리뷰 없을 시 비노출 | 리뷰 0개 / API 실패 시 영역 전체 미노출 | 필수 |
| F-05 | 리뷰 섹션 앵커 링크 | 클릭 시 하단 리뷰 섹션으로 smooth scroll | 선택 |
- 예외 처리 — 데이터가 없거나 API가 실패하면 어떻게 할 것인가 (F-04)
- 엣지 케이스 조건 — "1,000개 이상이면 어떻게 표시할 것인가" (F-02)
- 필수 vs 선택 구분 — 1차 릴리즈에 반드시 포함해야 하는 것과 이후에 추가해도 되는 것
6️⃣ A/B 테스트 계획 — 통계 설계까지 포함하는 이유
"A/B 테스트를 하겠다"는 말만으로는 충분하지 않다.
PM은 언제 어떻게 결과를 판단할 것인가까지 사전에 정의해야 한다.
| 항목 | 설정값 | 의미 |
|---|---|---|
| 유의수준 (α) | 0.05 | 95% 신뢰도 — 우연에 의한 오류 5% 이하 |
| 검정력 (1-β) | 0.80 | 실제 효과가 있을 때 80%는 감지 가능 |
| 최소 감지 효과 (MDE) | +5%p | 이 정도 개선이 있어야 비즈니스 의미가 있음 |
| 그룹당 필요 샘플 | 약 1,500명 | 위 조건 충족을 위한 최소 모수 |
| 총 필요 샘플 | 약 3,000명 | A + B 합산 |
- 성공 기준 — 어떤 수치를 달성해야 "성공"으로 보는가 (p < 0.05)
- 실패 기준 — B그룹이 A보다 낮으면 어떻게 할 것인가 (가설 재수립)
- 가드레일 지표 — 전환율이 오르더라도 반품률이 급증하면 중단한다
이 기준을 사전에 정하지 않으면 결과가 나온 후 유리한 쪽으로 해석할 위험이 있다.
7️⃣ 향후 로드맵 — 지금 기능이 성공하면 다음 단계는?
PRD는 현재 기능만 정의하는 것이 아니다.
"이 기능이 성공하면 그 다음은 무엇을 할 것인가"를 단계적으로 정의해두면, 팀이 더 큰 그림 안에서 지금 작업의 의미를 이해할 수 있다.
| 단계 | 기능 | 핵심 개념 | 조건 |
|---|---|---|---|
| 레벨 1 (현재) | 버튼 상단 UX Writing 추가 (별점·리뷰 수·만족도) |
리뷰 신뢰 정보 노출 | 즉시 실행 |
| 레벨 2 | 구매량 기반 Social Proof 추가 ("한 달간 N개 구매했어요") |
군중 심리 (Social Proof) | 레벨 1 성공 후 |
퀸잇·무신사는 상품명 아래에 별점·리뷰 수를 텍스트로 노출하고 있다.
오아시스마켓은 "한 달간 N개 이상 구매했어요" 방식으로 구매량 기반 사회적 증거를 노출한다.
레퍼런스를 찾는 이유는 "따라 하기" 위해서가 아니라, 어떤 방향이 실제로 구현 가능한지 검증하고, 우리 서비스에 맞게 변형하는 근거로 쓰기 위해서다.
✍️ 오늘 배운 것 한 줄 정리
데이터 분석은 인사이트를 발견하는 과정이고, PRD는 그 인사이트를 실행 가능한 계획으로 바꾸는 과정이다.
"왜 이 문제인가 → 어떻게 해결할 것인가 → 어떻게 검증할 것인가"가 하나의 논리로 이어질 때 비로소 기획서가 완성된다.