prd-quality-gatelisted

# PRD Quality Gate ## The Law ``` A PRD WITHOUT A DEFINED SUCCESS METRIC IS A SCOPE DOCUMENT, NOT A PRODUCT DECISION. "We'll know success when we see it" ships a feature with no definition of done and no way to decide whether to keep, kill, or iterate it. User problem + success metric + scope boundary + anti-goals + estimate IS a PRD. ``` ## When to Use Trigger before: - Committing engineering time to any feature - Writing a sprint plan that includes new functionality - Requesting design or backend effort for a new capability - Presenting a feature to stakeholders for approval ## When NOT to Use - Bug fixes with no scope ambiguity and a clear definition of done - Infrastructure changes with no user-visible behaviour change - Spikes or time-boxed explorations (label them as such — they are not PRDs) ## The Five Required Elements ### 1 — User Problem The problem must be real and specific — not a capability gap or a product roadmap goal. **Required form:** > [User type] cannot [do thing] because [specific constraint]. This causes [measurable consequence]. **What does NOT count:** - "We don't have this feature yet" - "Competitors have it" - "The team thinks it would be useful" If the problem statement doesn't name a user type, a specific constraint, and a consequence, it is not a user problem — it is a feature idea. ### 2 — Success Metric One primary metric that definitively answers "did this work?" at a specific threshold. **Required form:** > [Metric name] increa