Building for the edge cases.
The strange, overlooked problems that mainstream products ignore can reveal the most interesting opportunities.
Edge cases are worth building for when the “narrow” problem is actually a common behavior nobody has bothered to name yet. Mainstream problems attract attention because they’re easy to recognize. Edge cases are interesting for the opposite reason — fewer products are designed around them, which means the people living with them have had very little competition for their attention.
Where overlooked opportunities hide
An unusual workflow, an awkward manual process, or a fragmented piece of information can create real space for a focused product. The people living with it have usually just learned to tolerate it, often for years, because building or finding a proper solution never felt worth the effort relative to the size of the annoyance on any single day.
That tolerance is exactly what makes edge cases easy to miss and valuable to find. A problem people have already organized their workaround around doesn’t look like an opportunity from the outside — it looks like a solved problem, because someone found a way to live with it. The opportunity is in the gap between “solved” and “solved well.”
The real skill: telling the two apart
The trick is distinguishing an edge case nobody actually needs solved from one that represents a much larger pattern hiding in plain sight. Not every overlooked problem is a hidden opportunity — some things are ignored because they genuinely don’t matter enough to enough people. The skill is telling the difference before you spend months finding out the hard way.
One useful test: does the workaround people use today cost them something real — time, money, error, stress — or is it merely inconvenient in a way they’ve stopped noticing? Genuine cost sustained over time is a much stronger signal than mild annoyance.
Small communities as a signal
Small, specific communities are often useful here. Their problems can look narrow from the outside, but the underlying behavior is frequently more common than it first appears once you look past the specific label the community uses for it. A problem that seems unique to one profession or one hobby is often a specific instance of a much more general pattern that just hasn’t been named that way anywhere else yet.
This is part of why talking directly to a small, specific group of people who live with a problem daily is usually more useful than surveying a broad, general population about the same topic in the abstract. Depth of understanding with a narrow group reveals the shape of the pattern faster than breadth across a shallow one.
Common questions
How do you find edge cases worth investigating? Look for workarounds — spreadsheets, sticky notes, manual double-entry, third-party tools bent to do something they weren’t designed for. A workaround is evidence that a real cost exists, even if nobody has framed it as a “problem” out loud.
Is it risky to build a product for a very small, specific audience first? Less risky than it looks, if the underlying pattern generalizes. Building for a small, well-understood group first is often how you discover whether the pattern is actually larger — you learn that from depth, not from guessing at breadth up front.
How do you avoid wasting time on an edge case that turns out not to matter? Talk to the people living with it before building anything. If the cost they describe is vague or they seem indifferent to a proposed fix, that’s a strong early signal to move on.
Takeaway: sometimes the next product is hiding inside the thing everyone around you has already learned to tolerate.