Having read several versions of what a problem is and how they are supposed to be solved, problem-solving is still a zig-saw puzzle with varying domain expertise insights and frameworks at hand; problem-solving, per se, is still a zig-saw puzzle. I don’t want to point out specific literature and quote what it signifies, but I would rather prefer to throw light on what I feel a problem and problem-solving must look like. This could be another article shitting on the shelf biting dust over time, but a first perspective is better than no perspective.
Here is a list of things you might want to consider before calling something a problem and before going ahead to solve it. I would do that. And please know this is all even before you start solving a problem or even before you design a methodology to solve that problem.
First, one that you want to call a problem is it really a problem? Or is it only a task to solve? Does it need a domain-specific solution or a global solution? Is it a problem only for you? Or is there an environment where this is defined as a problem, and somewhere else, is it a normal flow of events? Try understanding if you want to call it a task or a problem. Does it have a cultural significance?
Second, can you write metadata for your problem? A short, vivid, crisp, one or two-sentence description of it. Show it to people and ask what they think. It’s always good to have intriguing perspectives on a problem. Research says people usually carry cognitive thoughts from their past experiences, and when you provide a not-so-detailed thought to people, they naturally add their viewpoints to it. You don’t give them the entire problem, but you give them a bird’s-eye view. That is exactly when a new worldview opens up. Do this to experts and to novices, and see what they add to it.
Third, know the theories. A problem solved with no underlying principles is solved mindlessly/uselessly or has given birth to a new theory that must be extracted. Even a brute force would have a pattern to it. A brute force must have a pattern because that is where evolution begins. Well, if you feel the problem being solved doesn’t have an underlying theory, then probably that calls for more reading – reading between the lines and reading thoroughly.
Fourth, a problem always has a twin in another domain. A similar problem would have occurred in a completely different domain. What did they do? This would need expertise, and there is no harm in aiming to be one and explore a new related world. There is no meaning in restricting and solving a problem, just like anyone else did. What does sociology say about this problem? What theories do they have? Read. Lots. There is nothing more efficient way of knowing things than that.
Fifth, when you solve a problem, what business cases do you see? What is the abstraction you see? Where else does it get applied? If the above four steps are done with a purpose, this has to be a by-product without extra effort.