Writing Useful Acceptance Criteria
Could a real customer finish one valuable job with this first version, and what would prove it? Write criteria around user-visible outcomes, important rules, and failure behaviour rather than implementation steps.
What You Will Be Able to Decide
- Explain writing useful acceptance criteria in product and business terms.
- Apply this decision: Write criteria around user-visible outcomes, important rules, and failure behaviour rather than implementation steps.
- Recognise this material risk: the founder and builder declare the same feature complete using different standards.
- Use this review: Trace one booking from the customer's first request to a confirmed appointment, then test what happens when the slot is unavailable.
A founder is turning an idea into a brief that a consultant can estimate and build. This lesson gives you a concrete question to take into a build brief, proposal review, or product decision.
Could a real customer finish one valuable job with this first version, and what would prove it? The course example is A founder's appointment-booking service for local businesses; use it to decide what evidence would justify the choice before a builder implements it.
What Does Writing Useful Acceptance Criteria Mean for Your Product?
A founder is turning an idea into a brief that a consultant can estimate and build.
Use the illustrative service for this course (A founder's appointment-booking service for local businesses) to make the choice concrete. Could a real customer finish one valuable job with this first version, and what would prove it?
Technical term
Writing Useful Acceptance Criteria
Acceptance criteria are observable conditions used to decide whether a workflow or requirement has been completed correctly.
How Should a Founder Use Writing Useful Acceptance Criteria?
For a founder's appointment-booking service for local businesses, ask what would happen if the founder and builder declare the same feature complete using different standards.
For this decision, the useful standard is that a real user can complete the intended outcome and the result tests the stated assumption.
- Decision: Write criteria around user-visible outcomes, important rules, and failure behaviour rather than implementation steps.
- Evidence to request: show that a real user can complete the intended outcome and the result tests the stated assumption.
- Owner: name who will respond if the founder and builder declare the same feature complete using different standards.
- Record the result in the MVP brief and acceptance criteria.
- Practical review: Trace one booking from the customer's first request to a confirmed appointment, then test what happens when the slot is unavailable.
How Do You Choose an Approach to Writing Useful Acceptance Criteria?
Could a real customer finish one valuable job with this first version, and what would prove it? Write criteria around user-visible outcomes, important rules, and failure behaviour rather than implementation steps.
The risk is that the founder and builder declare the same feature complete using different standards. Compare a simpler option with the proposed one, including who will operate either choice.
- Describe the user or business outcome that must be protected.
- Identify the most credible failure and its consequence.
- Compare the simplest adequate approach with one realistic alternative.
- Set a review point for when the decision may need to change.
What Evidence Should You Accept for Writing Useful Acceptance Criteria?
What Warning Signs Should You Look For?
- The proposal does not address this risk: the founder and builder declare the same feature complete using different standards.
- Nobody can show whether a real user can complete the intended outcome and the result tests the stated assumption.
- The decision has no named owner or review point.
What Should You Ask a Consultant?
- What changes for the user if we choose this approach to writing useful acceptance criteria?
- How have we reduced or accepted this risk: the founder and builder declare the same feature complete using different standards.
- Can you demonstrate that a real user can complete the intended outcome and the result tests the stated assumption?
- Who owns the result, and when will we reconsider it?
Key takeaway
Key Takeaway
Write criteria around user-visible outcomes, important rules, and failure behaviour rather than implementation steps. Ask for evidence against the specific risk: the founder and builder declare the same feature complete using different standards.