How To Tell If A Software Problem Is Worth Solving

Every software project has a list of problems. Bugs that need fixing. Features that need building. Optimizations that would make things faster. Refactors that would make the code cleaner. The list grows faster than anyone can work through it, which means someone has to decide what gets attention and what gets ignored. That decision—what to solve and what to leave alone—is often more consequential than the solution itself.

The trap is that not all problems are equal, and the ones that feel most urgent are often the ones that matter least. A technically fascinating bug can consume days of investigation while users are struggling with something far more basic. A feature that would be impressive in a demo can take priority over the unglamorous work of making the existing product more usable. The problems that feel important are not always the problems that are worth solving.

I’ve seen this play out in my own work. Building a video editor, I found myself drawn to effects and transitions—the visually interesting features that would make the product look more impressive. But the core editing experience was still rough. The timeline was awkward to navigate, and that awkwardness affected every user, every session, every project. The effects were a distraction. The timeline was the problem that mattered.

That experience taught me something that took a long time to internalize: a problem being technically interesting has nothing to do with whether it’s worth solving. The interesting problems are often the wrong ones. The right ones are usually boring.

The Questions That Separate Real Problems from Distractions

When you’re staring at a list of problems—and there’s always a list—how do you know which ones deserve your time? There’s no formula, but there are questions that help cut through the noise.

The first question is about frequency. How often does this problem actually occur? A bug that only appears when a user does something unusual—a specific sequence of actions, an edge case that requires five steps to reproduce—is a real bug, but it’s not urgent. The problems that matter are the ones users hit constantly. Not occasionally. Every day. Every session. The problems that are so woven into the experience that users have stopped noticing them because they’ve built their workflows around them.

The second question is about severity. When the problem does occur, how bad is it? A cosmetic issue that makes the UI look slightly off is low severity. A crash that loses an hour of work is high severity. But there’s a middle ground that’s easy to overlook: the problem that doesn’t crash anything but makes the product feel bad to use. The friction that adds a second here, a hesitation there. That kind of severity doesn’t generate bug reports, but it does generate churn.

The third question is about blocking. Does this problem prevent users from achieving their goal, or is it merely an inconvenience on the way? A user who can’t save their work is blocked. A user who has to click twice instead of once is mildly annoyed. The distinction matters because blocked users leave. Mildly annoyed users complain but stay. And the threshold between the two is not always obvious from inside the codebase.

The fourth question is about the user’s actual behavior. Not what they say when you ask them what they want—that generates a wish list. But what they do when they’re actually using the product. Where they hesitate. Where they get confused. Where they work around the tool instead of with it. Those moments of friction are the real problems, and they’re often invisible to users themselves, because users adapt. They develop workarounds and forget the friction was ever there. But the friction is still there, slowing them down.

The False Positive of Technical Interest

The hardest problems to ignore are the ones that are intellectually stimulating. A concurrency bug that only appears under load. A rendering issue that involves subtle timing. An architectural puzzle that would be satisfying to untangle. These problems pull at the mind. They offer the promise of a challenge overcome, a clever solution, a story to tell.

But the user doesn’t care about your intellectual satisfaction. They care about whether the product helps them do their job. And the problems that are most intellectually interesting are often the ones that affect the fewest users or the least important workflows. They’re puzzles, not progress. Solving them feels productive, but the product hasn’t actually gotten better for the people who matter.

This is especially true for developers working alone or in small teams. When you’re the one writing the code, the distinction between “interesting problem” and “worthwhile problem” blurs. You’re drawn to the interesting one because it’s your brain that gets the stimulation. But the worthwhile one—the one that removes friction for users—is often boring to implement. It’s a UI tweak. A performance optimization. A small change that makes a big difference in daily use.

The discipline is to care about the user’s experience more than your own entertainment. To recognize that the unglamorous work of making the product feel smooth and responsive is worth more than the flashy work of adding new capabilities. The user notices the first. They might not notice the second at all.

The Cost of Solving the Wrong Problem

Every hour spent solving a problem that doesn’t matter is an hour not spent solving one that does. That’s the opportunity cost, and it’s invisible. You feel productive because you’re writing code, fixing bugs, making progress. But the progress is in the wrong direction.

There’s a deeper cost too: solving the wrong problem gives false feedback. You fix the interesting bug, and it feels like an accomplishment. The code works. The test passes. But the user experience hasn’t changed. The product isn’t better in any way that matters. That false sense of momentum can keep you building the wrong things for a long time before you realize the product still doesn’t work for the people who need it.

This is why so many software projects accumulate features without becoming more useful. The team is solving real problems—technically real, practically real—but they’re the wrong problems. They’re building solutions for issues that don’t block users, don’t happen often, and don’t cause significant pain. Meanwhile, the core experience rots.

How to Actually Find the Problems Worth Solving

The most reliable way to find the problems worth solving is to watch someone use the product. Not a colleague. Not someone who already knows how it works. A real user, or someone who represents the target user, trying to accomplish a real task. Watch where they get stuck. Where they pause. Where they click the wrong thing, or don’t click at all, or open a different tool to work around the limitation.

Those moments are the signal. They’re often not things users will articulate, because users adapt. They develop habits and workarounds and stop noticing the friction. But the friction is still there, and it’s costing them time and attention every time they use the product. That’s the problem worth solving.

Another approach is to use the product yourself, not as a developer testing features, but as a user trying to get something done. The friction you feel personally is often the same friction your users feel. If the product annoys you, it probably annoys them too. And the things that annoy you in daily use are probably the things that annoy them in daily use. That’s not a coincidence. It’s signal.

The problems that emerge from observation and personal use are usually the boring ones. The slow load time. The awkward navigation. The confusing workflow. The missing affordance. These are not the problems that win engineering awards. But they’re the problems that determine whether users stay or leave, whether the product becomes part of someone’s daily routine or gets abandoned after the first try.

The Most Important Problem Is the One in Front of You

There will always be more problems than you can solve. The list never shrinks. The discipline is not to solve everything—that’s impossible—but to solve the right things in the right order. And the right things are almost always the ones that are already in front of you, already causing friction, already making the product worse for the people who are trying to use it.

The effects and transitions I wanted to build for my video editor were real features. They would have made the product more capable. But they weren’t the problem in front of me. The timeline was. And until the timeline worked smoothly, the effects didn’t matter.

That’s the test. Not “Is this problem interesting?” Not “Is this problem valuable in the abstract?” But “Is this problem in the way right now, for a real user, in a real workflow?” If the answer is yes, solve it. Everything else can wait.