Why should edge cases be caught during requirements rather than QA?

Because most of them are not edge cases. The empty state is the first thing every new user sees, and calling it an edge case is what licenses leaving it out of the spec. An unplanned case found in sprint review is a planning failure, and it costs a design decision made under time pressure by whoever noticed.

Which cases should be in every spec?

The empty state, the slow or failed connection, invalid input, concurrent actions, and the permission or expiry boundary. None are rare. Users mistype emails, lose signal on the bus, paste emoji into number fields, click submit twice, and edit the same document simultaneously, in normal use rather than in unusual use.

What should an empty-state requirement say?

What the user sees when they have no projects, messages or results, whether there is a call to action, and how the interface changes once the first item exists. This is the new user experience rather than an exception to it, which makes it one of the highest-traffic screens in the product.

Who should write the error messages?

Whoever writes the requirements, not the developer at the moment of implementation. Leaving error copy to be invented on the fly is how a product ends up with five tones of voice for the same class of problem. Specify what is accepted, what is rejected, and the message that appears.

Are PMs expected to predict every edge case?

No, and the argument does not depend on that. Nobody catches everything. The common ones, the five above, are known in advance and recur in every product, so there is no excuse for meeting them for the first time in sprint review.

Edge Cases Are Not Edge Cases. They Are the Product.

The thing your spec didn’t cover

A developer raises their hand during sprint review. “What should happen when the user has no data?”

Silence. Nobody thought about that.

It’s called an “edge case,” and that label is part of the problem. Calling it an edge case implies it’s rare, unlikely, someone else’s problem. But the empty state isn’t rare. Every single new user hits it. It’s literally the first thing they see.

This isn’t an edge case. It’s the product. And it should have been in the spec.

Why “edge cases” keep showing up in development

When PMs write requirements, they tend to describe the happy path. The user has data. The connection is fast. The input is valid. Everything works as expected. That’s the easiest scenario to think about and the one that matches the demo in your head.

But your users don’t live on the happy path. They live in a messy world where they mistype emails, lose WiFi on the bus, use your product in ways you never imagined, and hit back when they shouldn’t.

Every “edge case” discovered during development is a planning failure. Not because PMs should predict everything. They can’t. But the common ones? Those should be in the spec before the first line of code.

5 “edge cases” that should be in every spec

1. The empty state

What does the user see when they have no data? No projects, no messages, no results. This isn’t an edge case. It’s the new user experience.

A good spec defines: what message does the user see? Is there a call to action? Does the UI change once they add their first item?

2. The slow connection

Your product works great on your office WiFi. What about on a 3G connection in a train tunnel? What about when the API takes 8 seconds instead of 200 milliseconds?

Specify: what happens during loading? Is there a timeout? What does the user see if the request fails? Can they retry?

3. The invalid input

Users will paste emoji into number fields. They’ll submit forms with spaces where you expect URLs. They’ll upload a 200MB file when you expected 2MB.

Specify the validation rules. What’s accepted, what’s rejected, and what error message appears. Don’t leave it to the developer to make up error copy on the fly.

4. The concurrent action

Two people edit the same document. A user clicks “submit” twice. Someone deletes an item while another person is viewing it.

These aren’t obscure scenarios. In any collaborative or multi-device product, they’re daily occurrences. Define the behaviour: last write wins? Conflict resolution? Optimistic locking?

5. The permission boundary

What happens when a user tries to access something they don’t have permission to view? Do they see a 404 (pretend it doesn’t exist) or a 403 (you can’t access this)? What about when their permissions change while they’re in the middle of a session?

These decisions affect security and user experience. They deserve deliberate choices, not whatever the developer implements at 5pm on a Friday.

How to think about edge cases during requirements

You don’t need to anticipate every possible scenario. That’s not realistic. But you can build a habit of asking three questions for every feature:

What if there’s nothing? Empty states, zero results, no data, new user with no history.

What if something goes wrong? Network failure, server error, validation failure, timeout.

What if the user does something unexpected? Double submission, back button, browser refresh, unusual input, concurrent access.

These three questions catch 80% of the “edge cases” that show up during development. They take 10 minutes to think through per feature and save hours of back-and-forth later.

The cost of not thinking about it

When edge cases aren’t in the spec, one of two things happens.

The developer makes a decision. Sometimes it’s a good one. Sometimes they hard-code an error message that says “Something went wrong” and move on, because they have a sprint to finish and the PM didn’t specify what should happen.

Or the developer raises it, the PM thinks about it, a conversation happens, maybe a designer gets involved, and a decision gets made mid-sprint. That’s rework. It’s unplanned work that disrupts the flow and extends the timeline.

Neither outcome is good. Both are avoidable.

Reframing the language

I’d encourage every product team to stop using the phrase “edge case.” Call them “alternate paths” or “failure states” or just “requirements we haven’t written yet.”

The language matters because it changes how seriously people take them. An “edge case” sounds optional. A “requirement we haven’t written yet” sounds like a gap that needs filling.

Your product isn’t just the happy path. It’s every path. And the paths you don’t plan for are the ones that frustrate your users the most.

Write them down. Before the sprint starts.