Working through a problem
This is the framework I use for working through research problems and I think it applies more broadly too. It's inspired by Monte Carlo Tree Search which is a search strategy based on iterative exploration and exploitation. I find it to be an incredibly powerful heuristic for life in general. You learn about a problem space through cycles of random exploration and learned exploitation driven by a reward function. Exploration refers to the random sampling of the data and exploitation here refers to pursing a direction based on the evidence from the explorative phase.
The guiding principle for the entire process is to find the next step that would reduce the overall uncertainty of the problem space. That is, what can be done next to improve your understanding of the problem. I've tried to distill the process into 3 barebone essentials, this might come off as an oversimplification but it captures the spirit of working through a problem.
(1) Building intuition. The exploratory phase.
A practical way, I've found, to build an intuition is to study analogous problems and their solutions, and then construct a smaller version of the problem at hand. This smaller problem must have two properties: i) tractable enough to make failures easier to investigate ii) representative enough that the learnings can be transferred to the original problem. I work through this representative problem to build a mental model and to get a sense of the complexity involved and also as a means to test any assumptions. It essentially serves to provide a roadmap for directing my subsequent efforts.
(2) Knowledge exploitation
This phase draws from the mental model to divide the original problem into a set of subtasks and identify their dependency. As I work through these tasks, I revise the model and if I get stuck, I reflect on the priors - Is an assumption failing? Is my methodology problematic? Am I missing the knowledge to tackle this task? If I'm not making much of a headway, I write a brief note and switch to another subtask. The note is usually no longer than a page and covers: the problem, my approach, results, analysis, thoughts and ideas on what to try when I revisit.
(3) Reasoning and Testing
As possible solutions emerge from different pieces of the problem, I examine if they hold up together. Does the union of the parts address the whole? If I change any underlying assumption would the solution hold up? What would make it fail? What are the edge cases and the boundary conditions? Devise a stress-testing strategy.
If the solution doesn't survive this step, you go back to (1) and update the model. And if it does, then congrats you've found a viable path. Time for benchmarking!
In practise, there is some overlap and interleaving between the steps and you adjust the exploration-exploitation ratio as you see fit. Since it's not possible to see the lay of the land upfront when you pick a problem, uncertainty reduction is a useful heuristic to get you to the next step.
Commit to the problem but don't get attached to the solution.