Edge cases for the 5%

Recently, I listened to a podcast about self-driving cars.

"We're 95% of the way there!" the speaker claimed.

And that first 95% - it wasn't the challenging part. I don't mean to make it sound like the first 95% of the tech was easy... but building the initial 95% of any software product typically isn't the biggest challenge. 


It's the remaining 5% that:

  • Makes up 95% of the cost
  • Encompasses all of the edge cases, which are the most difficult issues to tackle with a new product or feature.

So the last 5% of a new product or feature typically takes up 95% of the cost!? That sounds insane. But it's a heuristic I've heard many times in my career. It's this last 5% that makes it so hard to bring a new technology to market. And this last 5% is also where product managers become increasingly important, since these remaining issues are usually not all technical ones.

A large portion of this last 5% is identifying - and finding solutions for - the product's edge cases.

Let's take self-driving cars as an example. Training a car to do the basics of driving - turn right, turn left, slow down if an object is within 3 feet in front of you - this is the easy part. The 'problem to solve' during this initial 95% is obvious and straight-forward. I do not mean to imply that it's easy from an engineering standpoint. The brightest minds at Stanford and beyond worked on the machine learning for years to make self-driving vehicles possible. But they accomplished it.  

So what's keeping self-driving cars from being pervasive already?

The remaining 5% - made up mostly edge cases.

Edge Case Examples:

  • What if there is a hail storm? Will the self-driving car know how to react during weird, inclement weather?
  • What about temporary construction? Will the car know about the reduced (temporary) speed limit? Will it be able to sense construction cones?
  • What if a group of hormonal teenage boys walk out into the middle of Main Street during rush hour and don't budge, knowing that the self-driving cars won't (can't) hit them?

These are all edge cases, and as a PM you're going to need to identify similar ones for your product.

Oftentimes, edge cases will creep up on you in the form of bugs or urgent customer complaints, so it's best to get ahead of them before your product or feature(s) go live. 

>> For more on how to write a good edge case, read my Lesson Kernel or How to Document an Edge Case. <<

You may be freaking out at this point, thinking of all the crazy ways in which an end-user could use your product. But the truth is, it's not really possible to identify ALL edge cases from the get-go. A list of edge cases is something a product manager accumulates over time. 

Tips for identifying and documenting edge cases:

  • Document edge cases from the user's standpoint, when possible. Some edge cases may be technical.
  • Prioritize edge cases - and focus on the most important ones first.
  • Keep an edge-cases backlog, where you track all identified use cases, along with solution (if scoped), and priority.
  • Do not get stuck in an edge case merry-go-round. Product managers - and developers - can get caught up in identifying an infinite number of edge cases, but the truth is, not all of them are important. Focus on the ones users will - or do - encounter most frequently.

It's your job as product manager to keep the team focused on the most important edge cases, and to pull out ideas for solutions from your engineering team. It's also your responsibility to document any possible solution(s), or the decided-upon solution, for those edge cases. 

Identifying edge cases is an on-going exercise. You can't always anticipate what crazy sh*t users will do with your product or feature. Seriously. I once worked on a DVR feature for a TV/ media app and customers complained that they couldn't set more than 15 recordings at a time. (I did have this documented as an edge case, but as a very low priority, since I made the assumption that no one in the world would want to record that many shows at a time. I was wrong.)


  • Start an edge-cases backlog
  • Keep it updated
  • Document which ones you've addressed, document the solution, and which are in the edge cases backlog