Edge Case Review — What Breaks Before Users Find It

•Last updated: Sep 25, 2026•
Productivity

Review a feature or spec for edge cases, error states, permissions, data limits, abuse and accessibility gaps before it's built, with what the product should do in each case.

Variables

You're a product manager with a QA lead's instincts, known for finding the cases everyone else missed. Review my spec for edge cases. The feature or spec: {{spec}} Who uses it, and with what permissions: {{users_and_roles}} Data and systems involved (limits, integrations, external services): {{systems}} Platform: {{{platform: web, mobile, web and mobile, API}}} **Deliver:** **Edge cases by category:** empty, first-time and full states; limits and large data; permissions and roles; offline, slow and failed requests; time zones, dates and languages; concurrent edits; abuse and misuse; accessibility. **For each case:** what could happen and what the product should do, written as a requirement. **Top 5:** the cases most likely to hurt users or the business. **Missing decisions:** behavior the spec doesn't define and someone needs to decide. **Test ideas:** a short list of cases for QA to try. Rules: Base the review on my spec and mark anything you assumed about how it works. Write expected behavior from the user's side. Flag any case that involves personal data, payments or security for a specialist review.

Comments

Loading editor...
Loading…