Not every problem deserves a solution

You see a problem. Your brain sparks up. You start sketching solutions before you even finish understanding what’s wrong. It’s human nature—especially for those whose entire job seems to revolve around fixing, optimising and reinventing. But some problems? Perhaps they don’t need solving.

Counterintuitive? Maybe. But think about it: how often have you spent weeks (or months) building a feature for your product, sketching the diagram of a new service that your company can offer, only to realise later that the problem it “solved” wasn’t really a problem in the first place? Or worse, that solving it actually created new, bigger problems?

Not everything inconvenient is a true problem. Some things are just the way they are, and that’s fine.

Take QR codes for example. For years, companies tried (and failed) to get people to use them. It wasn’t until COVID made contactless interactions a necessity that they truly took off. The problem wasn’t bad technology or bad UX. The problem was that there wasn’t a problem people cared enough about.

If you have to explain to users why they have a problem before pitching them your solution, there’s a good chance it’s not a real problem.

The impulse to fix everything comes from the belief that things can always be improved. It assumes that the current state of things is broken and that you, armed with your ideas and frameworks, can and should make it better. But sometimes, inefficiencies exist for a reason. Sometimes, the “problem” is actually an organic part of how people interact with a system.

Take email. Over the years, countless startups have tried to “fix” it—reinventing inboxes, changing workflows, replacing it with chat apps. Some fixes worked well (Slack or Teams replacing emails for internal communication in many organisations). And yet, email persists. Not because it’s perfect, but because it works well enough for most people, most of the time. Every attempt to “fix” it usually introduces a new layer of friction, which people resist.

And even when a problem is real, the cost of solving it might be higher than the value of the solution. You might introduce new complexities, dependencies, or unintended side effects that outweigh the benefits.

So how do you know if a problem is worth solving? A few sanity checks:

• Is it a real pain point? Would people pay to have it solved? Or at least be genuinely excited about the fix?
• Are people already hacking together their own solutions? If so, that’s a good sign.
• Does fixing it create new problems? If yes, are those problems worse than the original issue?
• Is it really a problem, or just an inconvenience? Minor annoyances often don’t justify massive overhauls.
• Is the timing right? Sometimes the world isn’t ready for your fix—and forcing it won’t work.

Solving problems, despite what it says on the tin, isn’t just about finding problems and solving them. It’s about knowing which problems matter. Sometimes, the best move isn’t to build another feature, disrupt another industry, or fix another inefficiency. Sometimes, the smartest thing you can do is step back and say, this doesn’t need solving.