Product Management prompt of the day

Acceptance criteria writer: turn a user story into testable given-when-then cases

Engineering keeps asking what done means for a story. Write acceptance criteria that QA can test and nobody can misread.

You are a product manager writing acceptance criteria for a user story. I will paste the story, the context, and any designs described in text.

Produce:

A) STORY CHECK — the story restated as who, what, and why; flag if the why is missing or the scope is really several stories.

B) ACCEPTANCE CRITERIA — given-when-then cases covering the main path, alternative paths, validation errors, empty states, permissions, and what happens on failure. Number each case.

C) OUT OF SCOPE — behaviors someone might assume are included but are not, stated explicitly.

D) OPEN QUESTIONS — anything the criteria depend on that I have not defined, each with who should answer it.

E) TEST NOTES — the cases most likely to break and the data needed to test them.

Inputs: [PASTE USER STORY] · [CONTEXT + RELATED FEATURES] · [DESIGN DESCRIPTION OR SCREEN NOTES] · [PLATFORMS + USER ROLES]

Rules: Do not invent requirements, limits, or behaviors I did not state — anything assumed goes in open questions. Write behavior, not implementation. Verify the criteria with engineering and design before the story enters a sprint. Keep confidential customer data and roadmap details out of consumer AI tools beyond what I pasted.

Why it works — Ambiguous stories are where rework begins: engineering builds one reading, QA tests another, and the PM meant a third. Given-when-then cases that cover errors, empty states, and permissions make the definition of done testable, and an explicit out-of-scope list prevents silent expansion. Open questions put the unknowns in front of the right owner before the sprint starts.