Writing acceptance criteria from customer calls
The edge cases you need are already on the recordings. They rarely sound like requirements.
Acceptance criteria written from a specification tend to test the happy path, because that is what the specification describes. Criteria written from customer conversations test reality, because customers only volunteer detail when something went wrong.
Listen for environment, not requests
A customer saying 'I need it to be faster' is a request and is nearly useless. The same customer saying 'I usually do this on the train' is an environment, and it is a specification: intermittent connectivity, small screen, one hand, interruptions.
Convert the anecdote, not the ask
- Find the moment they describe something failing
- Write the state they were in when it failed
- Write what they expected to happen
- That is a Given / When / Then, almost verbatim
Keep the citation attached
A criterion that carries the sentence it came from survives review. When someone challenges it in refinement, you are not defending your judgement — you are replaying a customer. Those two conversations go very differently.
Stop writing PRDs without understanding the product.
Anchor reads your interviews, tickets and docs first — then writes, citing every line.



