prd-quality-gate

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] increases from [baseline] to [target] within [timeframe], measured by [data source].

Rules:

• One primary metric, maximum two secondary metrics
• Baseline must be measurable now (if it isn't, instrument it before building)
• Target must be specific (not "improved" or "more")
• Timeframe must be fixed (not "eventually")

What does NOT count:

• "Better user experience"
• "Increased engagement" (no baseline, no target)
• "Users will like it more"

3 — Scope Boundary

What is explicitly included and what is explicitly excluded.