If you’ve ever been part of a product team, you know the feeling—everyone thinks they’re aligned on what needs to be built, until the feature is delivered and the feedback starts pouring in: “This isn’t what I asked for,” or “It doesn’t handle this case.” That gap? It often comes down to unclear or missing Acceptance Criteria.
Acceptance criteria are one of the most underrated tools in a product manager’s toolkit. When done right, they prevent endless rounds of “this isn’t right” and create clarity between product, design, and engineering.
Let’s break down what they are, why they matter, and how to write them well.
What Are Acceptance Criteria?
Acceptance criteria (AC) are the conditions that a product, feature, or user story must meet for it to be considered complete and successful.
Think of them as the definition of done—but from the user’s perspective. They answer questions like:
- What exactly needs to happen for this feature to work?
- How will the user know it’s working as intended?
- What edge cases need to be covered?
They’re not design specs or technical tasks. Instead, they bridge business intent with implementation detail in a way that’s testable.
Why Are Acceptance Criteria Important?
- Alignment across teams – Designers know what edge cases to plan for, engineers know what to build, and testers know what to validate.
- Reduce rework – Clear criteria minimize “this isn’t what I wanted” moments late in the cycle.
- User-focused delivery – They ensure the end experience is exactly what the customer needs, not just what was easy to code.
- Improved testability – QA teams rely heavily on AC to write test cases and confirm completeness.
Without acceptance criteria, you’re leaving too much to interpretation. And interpretations vary—wildly.
Two Common Formats for Writing Acceptance Criteria
1. Scenario-Oriented (Gherkin Style)
This format follows the Given–When–Then structure:
- Given: The context or precondition.
- When: The action the user takes.
- Then: The expected outcome.
Example:
- Given a user has entered a valid email and password
- When they click “Login”
- Then they should be redirected to their dashboard
This is great for precise, testable scenarios that QA can automate.
2. Rule-Oriented
This is more straightforward, often as bullet points or a checklist.
Example for a password reset flow:
- Users must enter a registered email address.
- If the email is invalid, display an error message.
- Send a reset link valid for 24 hours.
Rule-based AC works well when you’re listing functional boundaries without needing step-by-step interaction details.
How to Write Effective Acceptance Criteria
- Keep it user-focused
Phrase it from the perspective of the user outcome, not the system process. For example:- The system stores session tokens.
- Users remain logged in until they manually log out.
- Be clear and testable
Ambiguous criteria like “The page should load quickly” will spark debates. Instead, quantify:- The page should load within 2 seconds on a 4G network.
- Cover edge cases
Acceptance criteria should account for the common “what if” questions. Example:- What if the user enters an invalid email?
- What if the payment fails?
- Stay concise
Long paragraphs defeat the purpose. Keep each criterion short and focused. - Collaborate
Don’t write AC in isolation. Involve engineers, QA, and designers to ensure feasibility and coverage.
A Real Example: Online Checkout
Imagine you’re writing AC for a simple “Add to Cart” button.
- Users can add a product to the cart from the product details page.
- If the product is out of stock, the button should be disabled.
- Clicking the button updates the cart count instantly.
- Added product appears in the cart summary with correct name, price, and quantity.
This leaves little room for confusion. Everyone—from devs to testers—knows what “done” looks like.
Common Mistakes to Avoid
- Being too vague: “The login should work smoothly.” (What does that mean?)
- Mixing tasks with criteria: AC should describe outcomes, not “build APIs” or “create DB schema.”
- Overloading with details: Don’t turn AC into a requirements doc. Stick to what’s essential for validation.
Closing Thoughts
Acceptance criteria aren’t just a checkbox in your Jira ticket. They’re the contract between vision and delivery, ensuring what gets built is what users actually need.
As product managers, our job is to reduce ambiguity, align teams, and keep the user at the center. Well-crafted acceptance criteria do exactly that.
So next time you’re writing a user story, pause before you hit “save” and ask yourself: Have I clearly defined what “done” looks like?
That’s where the magic happens.