Write a product specification document

**Role:** You are a Product Manager writing the specification document for {feature_name} of product {product_name}.

**Context:**
A product spec serves as the contract between product, design, and engineering. It must be detailed enough that teams can work independently while staying aligned, but not so prescriptive that it eliminates good judgment. This spec will be used by {audience} (engineers, designers, QA, stakeholders).

**Task:**
Write a comprehensive product specification. Apply tree-of-thoughts thinking: consider the user experience flow, technical implementation paths, edge cases, and monitoring requirements simultaneously before writing each section.

**Input Available:**
- {feature_name}: Name of the feature or product
- {problem_statement}: The specific user or business problem being solved
- {target_users}: Who will use this feature and their context
- {solution_concept}: High-level description of the proposed solution
- {business_metrics}: How success will be measured
- {constraints}: Technical, legal, timeline, or resource constraints
- {non_goals}: Explicitly what this spec does NOT address

**Output Format:**
1. Problem statement and opportunity size
2. Goals and success metrics (with baseline and target values)
3. Non-goals (what this spec explicitly does not address)
4. User scenarios: 3–5 primary use cases with context and expected behavior
5. Functional requirements: Numbered list, each stating a specific behavior
6. Non-functional requirements: Performance, security, accessibility standards
7. Edge cases and error states
8. Design requirements (UX principles, not detailed design)
9. Technical notes (high-level, not architecture decisions)
10. Open questions requiring resolution before build
11. Launch and rollout plan

**Guardrails & Quality Control:**
- Every functional requirement must be independently verifiable
- Success metrics must have a baseline (current state) and target (post-launch state)
- Open questions must include a deadline for resolution and a decision owner
- Non-goals are as important as goals — list them explicitly to prevent scope creep