prd-07-data-acceptance

PRD Data & Acceptance

Purpose

Make the PRD measurable and testable. This skill defines what “done” means for product, engineering, QA, and operations.

Inputs

• Business boundary.
• Rule model.
• Flow model.
• Page spec.
• Admin config spec, if any.

Process

1. Define success metrics tied to the business goal.
2. Define guardrail metrics tied to cost, abuse, failure, or operations burden.
3. Define event tracking only where decisions need data.
4. Define acceptance scenarios for happy path, branch paths, and exceptions.
5. Resolve metric and acceptance gaps before handoff; keep only non-blocking data confirmations.

Metrics rules

• Do not list metrics for decoration.
• Every metric must answer a product or operations question.
• If a metric does not affect a decision, remove it.
• Define denominator and time window where relevant.
• Separate product outcome metrics from system health and risk metrics.
• Do not use vague alert triggers such as "significant decline", "above baseline", or "business limit" unless the baseline, threshold, owner, and observation window are defined.
• If the threshold is unknown, choose a conservative initial threshold when evidence supports it and mark it as a recommended default needing sign-off. If no responsible default can be chosen, loop back or ask the user before handoff.

Acceptance rules

• Write cases from user-visible behavior and product rules.
• Include edge cases from the rule and flow models.
• Each case must have precondition, action, and expected result.
• Do not write implementation-specific test steps unless the user provided implementation constraints.
• Expected results must be directly observable through UI state, product state, logs, events, or admin state.
• Avoid soft outcomes such as "may show", "possibly", "improves", "works normally", or "does not affect users" unless they are converted into observable criteria.
• If a valid outcome is probabilistic because ranking, recommendation, or experimentation is involved, split the case into observable checkpoints such as candidate generated, candidate admitted to ranking, constraint rejected, exposure logged, or fallback used.
• If QA cannot execute a case without a missing rule or threshold, send the gap back to the rule, boundary, or data stage instead of hiding it in acceptance. P0 cases must be executable in the final handoff.