prd

name	prd
description	사용자의 아이디어를 분석하여 PRD(Product Requirements Document)를 생성합니다. "PRD", "요구사항", "기획" 키워드에 활성화.

PRD 생성

사용자의 아이디어를 인사이트 중심으로 분석하여 PRD를 생성합니다. 기술 상세는 후속 $spec에서 다룹니다.

핵심 철학

"사용자가 말한 것이 아니라, 말하지 못한 것을 찾아라."

• 요구사항 수집이 아니라 인사이트 발굴이 목표다
• "왜?"를 5번 물어서 표면 아래의 진짜 동기를 찾아라
• 경쟁사가 공통으로 놓치는 것이 최고의 기회다
• 사용자가 원한다고 말하는 것 vs 실제로 쓰는 것은 다르다
• 가장 위험한 가정을 먼저 검증하라

실행 프로세스

Step 1: 시장 리서치 (서브에이전트 3개 병렬)

다음 3개 리서치를 반드시 병렬 서브에이전트로 동시에 실행:

서브에이전트 A: 경쟁사 & 유사 제품

• 유사 제품/서비스 5-10개 검색
• 각 제품의 핵심 강점, 약점, 가격, 타겟 정리
• 핵심: 모든 경쟁사가 공통으로 놓치는 것 식별

서브에이전트 B: 오픈소스 & 기술 생태계

• GitHub 유사 프로젝트 검색
• 스타 수, 기술 스택, 미해결 Issue(사용자 니즈) 분석
• 핵심: 오픈소스의 한계점 = 우리의 기회 도출

서브에이전트 C: 사용자 페인포인트 & 시장 동향

• Reddit, HN, 개발자 커뮤니티 불만/니즈 검색
• "사용자가 말하는 것 vs 실제로 원하는 것" 구분
• 핵심: 반복되는 불만 패턴 및 아직 해결 안 된 니즈 추출

Step 2: 리서치 브리핑 + 1차 질문

서브에이전트 결과를 핵심만 요약하여 사용자에게 보여주고, 라운드 1: 진짜 문제 파기 시작.

질문할 때 반드시:

• 리서치에서 발견한 구체적 사례/데이터 인용
• "경쟁사 X는 이렇게 하는데, 어떻게 생각하세요?" 식으로 자극
• 선택지를 주되, 사용자가 생각하지 못한 옵션도 포함

Step 3: 인사이트 인터뷰 (4-5 라운드)

라운드 1: 진짜 문제 파기 — Why 5번, 직접 계기, 현재 대안의 한계 라운드 2: 숨겨진 가정 뒤집기 — 의외의 사용자, 반대 접근, 기능 하나만 고르기 라운드 3: 사용자 행동의 진실 — 30초 가치 느끼기, 이탈 이유, 말 vs 행동 라운드 4: 기회와 경계 — 경쟁사 공백, 안티-기능, 실패 시나리오 라운드 5: 우선순위의 진실 — 모순 지적, 트레이드오프 강제, 6개월 후 회고

각 라운드에서:

• 이전 라운드 답변 핵심 요약 제시
• 모순된 답변 발견 시 정면으로 지적
• "잘 모르겠다"는 답변 = 가장 중요한 신호 → 검증 필요 항목으로 태깅

Step 4: 인사이트 합성

• 킬러 인사이트 3-5개 정리
• 가정 위험도 매트릭스 작성
• 차별화 포지셔닝 한 문장 정의
• 경쟁사 Feature Matrix + 공백 분석

Step 5: PRD 생성

아래 PRD 출력 형식에 따라 생성합니다.

저장: 프로젝트 디렉토리의 ./PRD.md에 저장.

Step 6: 자가 검증 + /spec 연결

생성된 PRD 검증:

• 모든 기능에 "뒷받침하는 인사이트"가 있는가?
• 가장 위험한 가정 Top 3가 명시되었는가?
• 안티-기능이 정의되었는가?
• 성공 지표가 "허영 지표"가 아닌 "실질 지표"인가?
• "$spec으로 넘길 항목" 목록이 있는가?

완료 후 안내: "PRD.md가 생성되었습니다. 기술 상세는 $spec PRD.md 기반으로 작성해줘로 이어가세요."

PRD 출력 형식

# PRD: [제품명]

> 생성일: [날짜] | 버전: 1.0
> 후속 단계: `$spec`으로 기술 상세 작성

## 1. 한 줄 정의
[이 제품은 ___ 하는 사람들이 ___ 할 수 있게 해준다. 기존 방식과 달리 ___ 하다.]

## 2. 핵심 인사이트
### 이 제품이 존재해야 하는 이유
| # | 인사이트 | 근거 | 제품에 미치는 영향 |
|---|---------|------|-------------------|

### 가장 위험한 가정 Top 3
| 가정 | 틀리면 어떻게 되는가 | 검증 방법 |
|------|---------------------|-----------|

## 3. 문제 정의
### 3.1 표면적 문제 vs 근본 문제
### 3.2 왜 지금인가

## 4. 시장 지형
### 4.1 경쟁사 분석
### 4.2 오픈소스 대안
### 4.3 경쟁사가 전부 놓치는 것

## 5. 사용자 이해
### 5.1 페르소나
### 5.2 사용자가 말하는 것 vs 실제 행동

## 6. 제품 전략
### 6.1 포지셔닝
### 6.2 차별화 요소
### 6.3 안티-기능 (절대 하지 않을 것)

## 7. 기능 요구사항
### 7.1 기능 우선순위
| 기능 | 사용자 가치 | 차별화 기여 | 복잡도 | MoSCoW |
### 7.2 상세 기능 명세
### 7.3 비기능 요구사항 (숫자로)

## 8. MVP & 로드맵
### 8.1 MVP 범위
### 8.2 Phase별 로드맵

## 9. 위험 & 완화
## 10. 성공 지표
## 11. $spec으로 넘길 항목
## 12. 부록

인터뷰 핵심 기법

• 반론 제시: "근데 경쟁사 X는 이렇게 해서 성공했는데요?" → 사용자의 확신 검증
• 모순 탐지: 라운드 간 답변이 다르면 즉시 지적 → 진짜 우선순위 도출
• 구체화 강제: "많은 사용자" → "몇 명?" / "빠르게" → "몇 초 이내?"
• 침묵 활용: 사용자가 "잘 모르겠다"면 → 그게 바로 검증이 필요한 가정
• 리서치 무기화: 모든 질문에 리서치에서 발견한 데이터/사례 첨부

중요 규칙

• 리서치는 반드시 서브에이전트 병렬 실행
• 절대 가정하지 않음 — 모호하면 반드시 질문
• 리서치 결과를 질문의 무기로 활용
• 모순을 발견하면 회피하지 말고 정면 지적
• 기술 상세(스택, 아키텍처, API 설계)는 PRD에 넣지 않음 → $spec의 영역