Writing PRDs Engineers Can Build: Scope, States and Acceptance Criteria

Start with the decision the product needs to support

A useful product requirements document helps a team decide what to build, why it matters and how to judge the result. It should reduce uncertainty before a team commits to implementation. Adding pages does not automatically make a requirement clearer.

My starting point is a short problem statement: who is struggling, what task they are trying to complete and what happens when the current process fails. For an illustrative service-booking product, “add a calendar” is a feature request. “Help an operations coordinator avoid assigning the same worker to overlapping visits” explains the problem a calendar might solve.

Keep observed evidence separate from assumptions. A customer interview, a support ticket and an analytics event tell different parts of the story. Record what each source can support, then list the questions that still need validation.

Define a small release boundary

Describe the first useful outcome, then separate the work into required behaviour, later improvements and explicit exclusions. If the initial release supports manual rescheduling, automatic route optimisation can remain outside its boundary. This prevents a reasonable suggestion from silently becoming a delivery commitment.

Write down constraints that affect the solution: supported devices, existing integrations, access permissions, network conditions and the operational owner. Agree on these with engineering rather than presenting an implementation design as a settled product requirement.

A concise decision log is especially helpful when the team rejects an alternative. Record the option, the reason and the condition that would make the team reconsider it.

Describe states before individual screens

Screens show the product at a moment in time. States explain what can happen next. For a booking, identify the valid transitions between requested, confirmed, completed and cancelled. Decide which actor can trigger each transition and what happens to related payment or allocation records.

Include the less comfortable situations. Can two people edit a booking at once? What happens if a payment succeeds after the browser loses its connection? Can an operator reverse a mistaken action? These questions often reveal requirements that a polished happy-path mockup misses.

A decision library can keep the reasoning beside the requirement instead of burying it in an old chat thread.

Make acceptance criteria observable

An acceptance criterion should give a reviewer a clear way to check behaviour. “The booking flow should be fast and reliable” leaves too much interpretation. A more useful criterion says that a coordinator cannot confirm an overlapping worker assignment and receives a message explaining which booking conflicts.

Describe the starting context, the action and the expected result. Add examples for invalid input, missing permissions, empty results and interrupted requests. Avoid inventing numerical targets without a measurement method or a baseline.

Connect each criterion to a product outcome. A well-worded criterion can still be irrelevant if it does not address the original user problem.

Review the requirement with the people who deliver it

Invite design, engineering, operations and testing to review the same document. Ask each group to identify ambiguity from its perspective. Engineering may find an integration dependency; operations may find an exception that the proposed workflow cannot handle.

Give unresolved questions an owner and a next action. Keep the document editable as discovery continues, and record material changes so the team can distinguish a clarification from a scope change.

Atlassian’s requirements guidance is a useful starting point for collaborative product documentation. The workflow above is a practical way to make that documentation concrete for a software team.

Finish with release and learning

Specify how the change will be introduced, what support information is needed and how the team will detect failure. Identify the smallest reversible release and agree on the boundary for a rollback.

After launch, compare actual behaviour with the original problem statement. Which assumptions held? Which questions remain? Feed those findings into the next decision rather than treating the document as finished once development starts.

Explore the PRD Center for related resources, or read more about my product-management work.