Acceptance criteria

Engineers implement what is testable. Turn P0 requirements into acceptance criteria — conditions that must hold for the work to be "done." Prefer Given / When / Then or equivalent.

Given a verified user on the billing page
When they click "Download invoice" for invoice INV-1042
Then a PDF matching the amounts shown on screen downloads within 5 seconds
And an audit event invoice_downloaded is recorded

That is a requirement made checkable. "The download should feel reliable" is not.

Edge cases that belong in the doc

Not discovered in prod:

• Empty states, permissions denied, rate limits
• Timezones, currencies, partial failures
• Idempotency on retries; double-submit
• What happens if a dependency is down
• Migration for existing data / existing customers

How reviews should work

A good PRD review is not a slide meeting. Send the doc at least a day ahead. Reviewers leave comments asynchronously; the sync meeting (if any) resolves disagreements, not first-time reading.

Invite: PM, eng lead, designer, someone from support or success, and optionally sales if the feature is customer-facing for deals. Ask each role a different question:

• Eng: what is ambiguous or expensive? what edge cases are missing?
• Design: does the problem match what we heard in research?
• Support: what will users break or misunderstand on day one?
• Sales: which deals does this actually unblock — and which are still blocked?

Silence from a required reviewer is not approval. Set a deadline; escalate.

When asked to design a product, narrate problem → users → goals → non-goals → requirements → risks. That is a verbal PRD. Mention acceptance criteria for one tricky edge case to show you think like someone who has shipped.

Common mistakes

• Happy path only. Invites, seats, SSO and forwarded links disagree in production.
• Adjectives instead of Given/When/Then. Not testable.
• Silence as approval. Set a deadline.

Check yourself

PRD for team invites lists only "user can invite a teammate by email." What's missing? Existing accounts, maxed seats, revoke-after-accept, SSO workspaces, forwarded links.

The eng lead has not commented and the meeting is tomorrow. Approved? No. Silence is not approval. Deadline, then escalate.

Key takeaways

• Acceptance criteria make P0 behavior testable. Given / When / Then beats adjectives.
• Put edge cases in the doc: empty, permissions, retries, dependency down, migration.
• Review async first. Each role answers a different question. Silence is not approval.

Further learning

Next: keep the doc alive in living PRDs.