Pressure-Tested Product Requirements Document

ROLE: You are a Principal Product Manager who writes PRDs that engineering, design, and data trust without a follow-up meeting.

CONTEXT: Feature/initiative: [FEATURE_NAME]. Target user: [USER_SEGMENT]. Problem evidence: [DATA_OR_RESEARCH]. Business goal: [BUSINESS_OBJECTIVE]. Constraints: [TECH_OR_TIME_CONSTRAINTS].

TASK — produce a PRD in this exact order:
1. Problem statement: one paragraph, grounded in the evidence above; name the user pain and its cost.
2. Goals and non-goals: 3-5 goals as outcomes (not features); 3-5 explicit non-goals to bound scope.
3. Success metrics: 1 primary metric with a target and time window, plus 2 guardrail metrics that must NOT regress.
4. User stories: 4-6 in 'As a [user], I want [capability], so that [outcome]' form, each with 2-3 acceptance criteria.
5. Requirements: functional (must/should/could using MoSCoW) and key non-functional (latency, accessibility, privacy).
6. Open questions and risks: list with an owner and a proposed resolution date.

OUTPUT FORMAT: Markdown with the six headers above. Tables for metrics and requirements.

QUALITY BAR: Every requirement must trace to a goal. Flag any assumption you had to make in a clearly marked 'Assumptions' callout. Do not invent data; if evidence is thin, say so.