PRD Writing Workflow

경쟁사 분석(Competitor Analysis)

당신은 경쟁 시장 리서치를 수행하는 **시니어 프로덕트 스트래티지스트**입니다. **[Insert industry or problem area]**에서 사용자가 **[Insert core feature or benefit]**을 할 수 있도록 돕는 스타트업을 위한 종합 경쟁사 분석을 수행해주세요.

---

## 분석 입력

| 항목 | 상세 |
|---|---|
| **우리 제품 콘셉트** | {{product_concept}} |
| **타깃 시장** | {{target_market}} |
| **알려진 경쟁사** | {{known_competitors}} (발견하는 곳을 추가) |

---

## 산출물

### 1. 경쟁사 프로필 (Top 5)
각 경쟁사에 대해 다음 프로필 작성:

| 차원 | 상세 |
|---|---|
| **회사 & 제품** | 이름, 창업 연도, 펀딩 단계, 직원 수 |
| **고유 가치 제안(UVP)** | 한 문장 핵심 피치 |
| **가격 모델** | Free / freemium / 유료 티어와 구체적 가격 |
| **타깃 청중** | 주요 ICP와 시장 세그먼트 |
| **핵심 강점** | 진짜 경쟁 우위 2~3개 |
| **핵심 약점** | 우리가 공략할 수 있는 취약점 2~3개 |
| **유통 전략** | 사용자 획득 방법 (PLG, 세일즈 주도, 파트너십, 콘텐츠) |
| **최근 행보** | 지난 6개월: 제품 런칭, 피벗, 펀딩 라운드, 핵심 채용 |

### 2. 기능 비교 매트릭스
각 역량을 4점 척도로 평가:

| 기능 / 역량 | 우리 제품 | 경쟁사 A | 경쟁사 B | 경쟁사 C | 경쟁사 D | 경쟁사 E |
|---|---|---|---|---|---|---|
| [Core feature 1] | -- | strong / adequate / weak / missing | | | | |
| [Core feature 2] | -- | | | | | |
| [Differentiator 1] | -- | | | | | |
| 가격 유연성 | -- | | | | | |
| 개발자 경험 / API | -- | | | | | |
| 고객 지원 품질 | -- | | | | | |

### 3. 경쟁 포지셔닝 맵
우리 시장에서 가장 전략적으로 관련된 두 차원을 사용해 2x2 매트릭스를 만들기. 흔한 축 페어:
- 가격 vs 기능 깊이
- SMB vs 엔터프라이즈 초점
- 셀프서브(self-serve) vs 세일즈 주도
- 수평적 vs 수직적 특화

모든 경쟁사를 배치하고, 우리 제품이 이길 수 있는 **화이트 스페이스를 명시적으로 식별**하세요.

### 4. 위협 평가

| 경쟁사 | 위협 수준(High/Med/Low) | 1차 위협 벡터 | 우리의 방어 우위 |
|---|---|---|---|
| 경쟁사 A | | | |
| 경쟁사 B | | | |
| 경쟁사 C | | | |

### 5. 전략적 권고

#### 시장 트렌드 (향후 12~18개월)
- 경쟁 구도를 재편할 핵심 트렌드 3개

#### 모트(Moat) 분석
- **복제하기 가장 어려운** 어떤 경쟁 모트를 만들 수 있는가?
- 우리 시장에 맞게 모트 유형 순위: 네트워크 효과 > 데이터 > 전환 비용 > 브랜드 > IP

#### 차별화 액션 Top 3
각 권고에 대해:
1. **무엇:** 취할 구체적 행동
2. **왜:** 어떤 경쟁 격차를 공략하는지
3. **타임라인:** 언제 실행 (지금 / 다음 분기 / 6개월 이상)
4. **예상 임팩트:** 우리 포지셔닝을 어떻게 이동시키는가

---

**형식:** 발견을 임원이 바로 읽을 수 있는 형식으로 제시하되, 상단에 경영진 요약(최대 5개 불릿)을 두세요.

문제 발견을 위한 고객 인터뷰 가이드 설계하기(Design a customer interview guide for problem discovery)

당신은 {{problem_area}}에 대한 45분짜리 customer interview guide를 설계하도록 돕는 research coach입니다. 타깃 페르소나는 {{persona}}입니다.

## Rules
- 제안한 solution에 대한 의견 질문 금지 (그건 fake data입니다)
- 모든 질문은 구체적인 과거 행동과 명확한 timeframe에 anchored되어야 함
- "보통 어떻게 하나요"보다 먼저 "마지막으로 언제 그 일을 했나요"를 물을 것

## Section 1 (5 min): warm-up
- 역할에 대해 말씀해주세요
- 전형적인 화요일은 어떤 모습인가요?

## Section 2 (15 min): problem recall
- 마지막으로 {{problem_area}}를 해야 했던 때가 언제였나요?
- 그날을 처음부터 끝까지 설명해주세요. 무슨 일이 있었고, 누가 involved되었고, 어떤 tool을 썼나요?
- 원래 어떤 일이 일어나길 기대했나요? 실제로는 무엇이 일어났나요?
- 해결을 거의 포기하게 만들었던 순간은 무엇이었나요?

## Section 3 (15 min): alternatives explored
- 현재 접근으로 정착하기 전에 무엇을 시도해봤나요?
- 왜 그것들을 버렸나요?
- 그 이후에 다른 도구나 접근을 찾아본 적이 있나요?

## Section 4 (8 min): forces
- 왜 6개월 전이 아니라 지금 해결책을 찾게 되었나요?
- 이전 방식의 어떤 점이 계속 머뭇거리게 했나요?
- 바꾸는 것에 어떤 불안이 있었나요?

## Section 5 (2 min): close
- 제가 묻지 않았지만 중요한 것이 있을까요?
- 제가 더 이야기해봐야 할 다른 사람은 누구일까요?

## Output
1. 전체 질문 가이드
2. fake data를 만들 가능성이 가장 높은 질문 3개와 그 behavioral rewrite
3. 답변을 정리하기 위한 1페이지 synthesis template

문제 정의 워크숍(Problem Statement Workshop)

당신은 문제 정의 워크숍을 진행하는 design thinking facilitator입니다. 날카로운 problem statement를 정의할 수 있도록 안내해주세요.

## Initial Problem Area
- **Domain:** {{product_area}}
- **영향을 받는 사람:** {{user_segment}}
- **우리가 관찰한 것:** {{symptoms_or_complaints}}
- **현재 가설:** {{what_we_think_the_problem_is}}

## Workshop Steps

### Step 1: 가정 드러내기(Surface Assumptions)
이 문제에 대해 우리가 하고 있는 모든 가정을 나열하세요.
| # | Assumption | Confidence | How to Validate |
|---|-----------|------------|-----------------|
| 1 | | High/Med/Low | |

### Step 2: 5 Whys Deep Dive
표면 문제에서 시작해 아래로 파고드세요.
1. **왜(Why)** [symptom]이 일어나나요? → [cause 1] 때문입니다.
2. **왜(Why)** [cause 1]이 일어나나요? → [cause 2] 때문입니다.
3. **왜(Why)** [cause 2]가 일어나나요? → [cause 3] 때문입니다.
4. **왜(Why)** [cause 3]이 일어나나요? → [cause 4] 때문입니다.
5. **왜(Why)** [cause 4]가 일어나나요? → [root cause] 때문입니다.

### Step 3: Problem Statement Formats

**User-centered format:**
"[User persona] needs a way to [user need] because [insight from research], but currently [barrier/pain point]."

**Jobs-to-be-Done format:**
"When [situation], I want to [motivation], so I can [expected outcome]."

**Business-impact format:**
"[User segment] is experiencing [problem], which is causing [business impact]. We believe that [proposed direction] will [expected outcome], which we'll measure by [metric]."

### Step 4: "How Might We" Questions
해결 공간을 탐색하기 위한 HMW 질문을 5-10개 생성하세요.
1. How might we [make the problem disappear]?
2. How might we [turn the problem into an opportunity]?
3. How might we [challenge an assumption]?

### Step 5: 다듬어진 Problem Statement
[Final, refined problem statement that is specific, measurable, and actionable]

### Validation Plan
| What to Validate | Method | Timeline |
|-----------------|--------|----------|
| [Is this the real problem?] | | |

PRD 작성기(PRD Generator)

Head of Product 입장에서, 세계 최고 수준의 PRD를 만든다는 마음가짐으로 이 작업에 접근해주세요. 제가 컨텍스트와 인사이트를 제공할 테니, 명확하고 실행 가능하며 전략적인 PRD를 만들 수 있도록 안내해주세요.

## PRD 템플릿

### 1. 개요(Overview)
- **제품명:** {{product_name}}
- **작성자:** {{author}}
- **최종 수정일:** {{date}}
- **상태:** 초안(Draft) / 검토 중(In Review) / 승인됨(Approved)

### 2. 문제 정의(Problem Statement)
- 우리가 어떤 문제를 해결하려고 하는가? 왜 지금 중요한가?
- 누가 이 문제를 겪는가? 얼마나 자주, 얼마나 심각하게?
- 해결하지 않을 때의 비용은?

### 3. 목표와 성공 지표(Goals & Success Metrics)
- **핵심 목표(Primary objective):** 원하는 결과를 한 문장으로
- **핵심 결과(Key results):** 측정 가능한 성공 기준 3~5개, 목표치와 일정 포함
- **Non-goals:** 이 PRD가 명시적으로 다루지 **않는** 범위

### 4. 사용자 스토리와 요구사항(User Stories & Requirements)
각 핵심 사용자 플로우(user flow)마다:
- **사용자 스토리(User story):** 으로서, 을 하고 싶다, 을 위해
- **수락 기준(Acceptance criteria):** Given/When/Then 형식
- **우선순위(Priority):** P0 (필수) / P1 (있으면 좋음) / P2 (있으면 더 좋음)

### 5. 솔루션 설계(Solution Design)
- 큰 그림에서의 접근 방식과 주요 설계 결정
- 사용자 플로우 다이어그램 (핵심 경로 설명)
- 처리해야 할 엣지 케이스(edge case)와 에러 상태

### 6. 기술 고려사항(Technical Considerations)
- 아키텍처 의존성(dependency) 또는 제약사항
- API 요구사항과 데이터 모델 변경사항
- 성능, 보안, 확장성(scalability) 요구사항

### 7. 출시 계획(Launch Plan)
- **롤아웃 전략(Rollout strategy):** Big bang / 단계적(phased) / 피처 플래그(feature flag)
- **의존성:** 크로스 팀(cross-team), 벤더, 또는 인프라
- **타임라인:** 주요 마일스톤(milestone)과 일정

### 8. 리스크와 완화 전략(Risks & Mitigations)
| 리스크 | 발생 가능성 | 영향도 | 완화 방안 |
|---|---|---|---|

### 9. 미해결 질문(Open Questions)
- 이해관계자(stakeholder) 의견을 기다리는 결정사항
- 검증이 필요한 가정

## 추가 섹션 (선택)
[Add sections from your own preferred template, e.g., Success Metrics, Timeline, Risks, etc.]

## 입력 내용
[Feel free to input key objectives, hypotheses, ideas, and other elements related to product development.]

RICE 점수화 프레임워크(RICE Scoring Framework)

당신은 Intercom이 만든 RICE scoring framework를 사용하는 제품 우선순위화 전문가입니다. 제 제품 아이디어를 점수화하고 순위를 매길 수 있게 도와주세요.

## Ideas to Score
{{list_your_ideas_or_features}}

## RICE Scoring Guide

### Reach (per quarter)
다음 분기 동안 몇 명의 사용자/고객에게 영향을 줄까요?
- 구체적인 숫자를 추정하세요. (예: 500 users/quarter)
- 감이 아니라 analytics data를 사용하세요.

### Impact (1-3 scale)
이것이 사용자당 target metric을 얼마나 움직일까요?
- 3 = Massive impact
- 2 = High impact
- 1 = Medium impact
- 0.5 = Low impact
- 0.25 = Minimal impact

### Confidence (percentage)
Reach와 Impact 추정에 대해 얼마나 확신하나요?
- 100% = High confidence (data로 뒷받침됨)
- 80% = Medium confidence (일부 data + intuition)
- 50% = Low confidence (대부분 intuition)

### Effort (person-months)
모든 팀원의 총 effort입니다.
- person-month 단위로 추정하세요. (예: 2 = 두 사람이 한 달 투입)

## Scoring Table
| Idea | Reach | Impact | Confidence | Effort | RICE Score |
|------|-------|--------|------------|--------|------------|
| | | | | | = (R × I × C) / E |

## Ranked Results
[Sort by RICE score, highest first]

## Calibration Notes
- [Flag any scores where Confidence