Real Life is Full of Edge Cases - ProductFTW #87

I’ve often been concerned about chasing edge cases. We’ve all worked with product managers or engineering leads who become obsessed with every unhappy path, leading to endless rework and delayed shipping. As the saying goes, “strategy is about what you say no to,” which is even more critical for product managers trying to define scope.

I will admit to some fascination with edge cases. They are fun to think about. My personal blog was once called Cornercase for this very reason (you know, where two edges meet; it’s even rarer, like the Four Corners in the U.S.).

While PMs are often cautioned not to chase edge cases, the reality is that life is full of them. In payments and fintech especially, edge cases are unavoidable because regulatory requirements mean you have to serve everyone, not just the average customer.

For example, imagine you develop a mobile phone app. You have a bug that causes the app to crash on launch in iOS 18.4, but not in any other version. As of today, only 0.31% of all U.S. iPhones run this version (StatCounter). Should you fix it? Maybe not. If it’s a game or social app, you might decide that supporting a tiny percentage of users isn’t worth delaying the release. Given the rapid pace of iOS upgrades, that version will eventually disappear.

Now imagine you’re building a fintech app and iOS 18.4 is the only version supported by a visually impaired customer who relies on accessibility features that changed in later releases. Or imagine it’s the only device they own. Suddenly, that 0.31% isn’t just a statistic. It’s a customer who may no longer be able to access their money. Banks and regulators tend to care a lot more about those situations than game developers do.

Edge cases exist everywhere, from the technology you support to the data you collect. One of my favorite examples in fintech is addresses. They seem simple enough:

1. Everyone has one
2. You can look them up at the USPS or a mapping tool
3. Regulators require you to have a real physical address, not a PO Box

Except:

1. Some people have weird addresses, like folks in Carmel-by-the-Sea (ok, they are getting addresses)
2. Some people in rural areas have rural route numbers
3. Minnesota has a law allowing people to use a PO Box as their official address in its anti-stalking statutes
4. Some people can’t accept physical mail to their home address (condos, rural areas)

These situations seem rare, but within your first few thousand customers you’ll almost certainly encounter them. With limited data, it’s difficult to know which ones are worth investing in upfront and which ones can wait.

The same pattern appears throughout fintech. Once you start looking, almost every piece of customer information has its own collection of edge cases. 

Identity

• Someone legally has only one name.
• A customer’s name is longer than your database allows.
• They recently changed their name, but not every system has been updated.
• Their legal name contains accented or non-Latin characters.

Phone Numbers

• The customer doesn’t have a mobile phone.
• They recently changed numbers.
• Multiple family members share the same phone number.
• They can’t receive one-time passcodes.

Email

• The customer no longer has access to the email address they registered with.
• Verification emails end up in spam.
• Your validation rejects a perfectly legitimate email address.

Dates

• Leap-day birthdays.
• A customer turns 18 today for KYC purposes.
• Time zones affect payment cutoffs.
• Daylight Saving Time changes when scheduled payments execute.

Cards & Payments

• Gas station authorization holds.
• Hotel and rental car incidental holds.
• Restaurants adjusting transactions after tips.
• Partial reversals and duplicate authorizations.
• Merchants taking days to reverse an authorization.

None of these situations is common on its own. Collectively, they are inevitable. If you build products for enough customers, especially in a regulated industry, you’ll eventually encounter all of them.

Some of the most interesting edge cases aren’t even software problems. They’re ecosystem problems.

Take gas stations. When you pay at the pump, the merchant estimates your purchase amount and places an authorization hold before you begin fueling. Some issuers add their own padding on top of that. The result can create several frustrating experiences:

• The hold is too small, so you can’t fill your tank.
• The hold is too large, so you don’t have enough available funds for other purchases.
• The authorization takes days to clear, leaving your money unavailable long after you’ve finished pumping gas.

This is why so many debit cards recommend paying inside. The cashier enters a fixed purchase amount, avoiding the uncertainty of a variable authorization hold. It’s a problem I’ve been thinking about for nearly twenty years. Gas prices have changed dramatically over that time, but the underlying customer experience hasn’t improved much.

How to Handle Required Edge Cases

Not every edge case deserves engineering effort. Part of being a product manager is deciding which problems are worth solving and which ones aren’t.

Legal and regulatory requirements are different. They are still edge cases, but they aren’t optional. You have to support them, and you have to do so efficiently.

One approach is to build software that handles every scenario automatically. Another is to provide operations or customer support teams with administrative tools that enable them to resolve uncommon situations manually. While this introduces some operational overhead, it often allows you to ship sooner without compromising compliance or customer outcomes.

The goal isn’t to eliminate every edge case before launch. It’s to understand which ones are simply rare, and which ones are guaranteed to happen eventually.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.