The Curious Case of Edge Cases: A Keyboard Taught Me Better Product Design
The curious case of edge cases.
I bought a keyboard with a number pad sometime back. At that time, it felt like the right decision. Having the numpad is convenient whenever I enter numbers. Spreadsheets, invoices, calculations. Makes sense, right?
But I realized I use the number pad extensively only once a month. And the shifted layout (keyboard pushed left because of the numpad) makes my day-to-day typing experience worse. Every single day.
I optimized for the rare case and degraded the daily experience.
TL;DR: In product design, it's tempting to add features for the one user in the one situation. But doing so can compromise the experience for everyone else, every single day. Good design makes daily interactions smoother. Great design knows what not to build. Edge cases should inform decisions, not dominate them.
The product design parallel
This keyboard problem is exactly what happens in product design when we chase edge cases.
Someone reports a rare scenario. A customer describes a specific situation where the product doesn't work. A stakeholder imagines a hypothetical use case. And the team builds for it.
The feature ships. It handles the rare case. But it adds:
- A new option in the settings (more cognitive load)
- A new path in the code (more bugs, more maintenance)
- A new element in the UI (more visual noise)
- A new thing to explain in onboarding (more friction)
The rare case is served. The daily experience is slightly worse. And "slightly worse" across every user, every day, compounds into a meaningfully degraded product over time.
How edge case features accumulate
One edge case feature is fine. Two is manageable. But products accumulate them over years:
- The toggle that 3% of users need
- The advanced setting that one enterprise customer requested
- The extra confirmation dialog that prevents a mistake that happens 0.1% of the time
- The menu item that serves a quarterly workflow
Each one is justified in isolation. But together, they create a product that feels bloated. Complicated. Confusing.
This is how simple, elegant products become cluttered messes over time. Not through one bad decision. Through a hundred individually reasonable decisions that each added a little complexity for a rare case.
The questions to ask
When considering whether to build for an edge case:
"Is this use case solving a real and frequent problem?"
"Real" means it actually happens (not hypothetical). "Frequent" means it happens enough to justify adding complexity for everyone else. If a scenario happens to 2% of users once a quarter, the math rarely justifies building for it.
"Are we prioritizing convenience for the few over efficiency for the many?"
Every feature has a cost. Not just engineering time, but attention cost for all users who don't need it. That menu item, that toggle, that extra option: every user has to mentally process it even if they never use it.
"What's the cost of NOT building this?"
Sometimes the answer is "nothing." The user works around it. They do the task a slightly different way. And that's completely fine.
Other times the answer is "they churn" or "they lose data" or "they can't use the product at all." Those edge cases deserve attention. The distinguishing factor is: what happens if we don't solve this?
"Can we solve this without adding permanent complexity?"
Sometimes an edge case can be solved through documentation, a workaround, or a one-time configuration, without adding a permanent feature that everyone sees.
When edge cases DO matter
Not all edge cases should be ignored. Some are critical:
Data loss scenarios. If an edge case can cause users to lose work, build for it. Even if it's rare. The cost of occurrence is too high.
Security vulnerabilities. Rare attack vectors still need defense. You don't get to say "that only happens 0.01% of the time" about security.
Compliance requirements. If an edge case is legally required (accessibility, data privacy, financial reporting), frequency doesn't matter.
High-value user workflows. If the 2% of users who hit this edge case are your highest-paying accounts, the math changes.
The principle: edge cases should inform decisions, not dominate them. Consider them. Evaluate their impact. Then make a conscious choice about whether the complexity trade-off is worth it.
Good design vs. great design
Good design makes daily interactions smoother. It optimizes for the 90% use case. It removes friction from the paths people walk every day.
Great design knows what not to build. It recognizes that every addition has a cost. It's willing to leave the edge case unserved if serving it degrades the daily experience for everyone else.
The keyboard with the numpad is "good design" in isolation (it serves a use case). A compact keyboard without the numpad is "great design" in practice (it optimizes for what I actually do every day).
The bottom line
Before building for an edge case, ask:
- How often does this actually happen?
- What's the cost to everyone else of adding this?
- What happens if we don't build it?
- Is there a simpler way to handle it?
Edge cases should inform your thinking. They should be documented. They should be understood. But they should not dominate your roadmap or clutter your product.
The best products are the ones that do the common thing exceptionally well, not the ones that handle every possible scenario adequately.
How ProductResume helps
Knowing what not to build is a PM skill that signals maturity. Your resume bullets should show evidence of strategic scoping and saying no, not just shipping features. Score your PM resume to see whether your experience communicates product judgment.