prd-development

name	prd-development
effort	high
description	Use when turning scattered discovery notes, Slack threads, or stakeholder requests into a structured PRD that engineers can act on. Triggers on: "PRD 작성", "기획서", 제품 요구사항 문서", "write a PRD", "product requirements document", "engineering handoff", "I
intent	Guide product managers through structured PRD creation by orchestrating problem framing, user research synthesis, solution definition, and success criteria into a cohesive document — moving from scattered notes to a clear source of truth.
type	workflow
theme	pm-artifacts
best_for	["Writing a complete PRD from scratch","Structuring product requirements for an engineering handoff","Documenting a major new feature before development begins"]
scenarios	["I need a PRD for a new AI-powered recommendation feature in our e-commerce platform.","I've completed a discovery sprint and need to turn the findings into a PRD my engineers can act on.","PRD 템플릿에 맞춰 새 기능을 문서화해줘.","Help me write the problem statement and success metrics for this initiative.","기획서를 엔지니어가 바로 개발에 들어갈 수 있게 정리해줘.","We have user research findings — help me turn them into a PRD."]
estimated_time	60-120 min
compatibility	{"recommended":["think-tool"],"optional":["sequential-thinking","mcp-reasoner"],"remote_mcp_note":"think-tool이 있으면 문제 정의와 성공 지표 간 일관성, 스코프 경계의 논리를 검증하는 데 도움이 됩니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요."}

Standing Mandates

• ALWAYS state the problem and user persona before writing any requirements.
• ALWAYS define success metrics before listing solution requirements.
• NEVER write requirements without a clear user scenario that motivates them.
• NEVER conflate 'what we are building' with 'why we are building it' — keep problem and solution sections separate.

Key Concepts

What is a PRD?

A PRD (Product Requirements Document) is a structured document that answers:

1. What problem are we solving? (Problem statement)
2. For whom? (Target users/personas)
3. Why now? (Strategic context, business case)
4. What are we building? (Solution overview)
5. How will we measure success? (Metrics, success criteria)
6. What are the requirements? (User stories, acceptance criteria, constraints)
7. What are we NOT building? (Out of scope)

Use template.md for the full fill-in PRD structure.

Anti-Patterns (What This Is NOT)

• Not a detailed spec: PRDs frame the problem and solution; they don't specify UI pixel-by-pixel
• Not waterfall: PRDs evolve as you learn; they're not frozen contracts
• Not a substitute for collaboration: PRDs complement conversation, not replace it

When to Use This

• Starting a major feature or product initiative
• Aligning cross-functional teams on scope and requirements
• Documenting decisions for future reference
• Onboarding new team members to a project

When NOT to Use This

• For small bug fixes or trivial features (overkill)
• When problem and solution are already clear and aligned (just write user stories)
• For continuous discovery experiments (use Lean UX Canvas instead)

---

Facilitation Source of Truth

When running this workflow as a guided conversation, use workshop-facilitation as the interaction protocol.

It defines:

• session heads-up + entry mode (Guided, Context dump, Best guess)
• one-question turns with plain-language prompts
• progress labels (for example, Context Qx/8 and Scoring Qx/5)