Universal Heuristic Problem Solving method — v 1.0

The mission: creating a near-universal heuristic for problem solving.

12 min readJan 8, 2022

There is no lack of very wide problem solving frameworks, which I love and use. Much of the inspiration for this project comes from a basis laid down by frameworks and approaches such as:

All of these systems, at least in my understanding of them, fall short in some ways.

Some of them are vague: they may be great ways to categorize and think about problems, but they don’t tell you much about how to go from A to B (Cynefin, systems thinking).
Some of them fall prey to the opposite problem: they are too specific in their prescriptions, ending up being a straightjacket for creativity (Triz)
Some are flawed in that they are empiricist, in the sense that they assume that one comes to a problem-solving project with an empty, clear mind, and start by empathizing with the research subjects. As I will argue, this is not how a project really works, as we all start out with a set of mental models and biases that affect the way we look at a problem (Design thinking falls here).
Finally, some seem to deal with one type of problem much better than with others (eg. theory of constraints, perfect for an operations problem, less so for innovation)

Additionally, two key components of problem-solving seem to have been left a bit under-theorized by most approaches¹: one is the already mentioned a priori “lenses” through which we first approach a problem. The other is model-building, not in the sense that there are no good model templates to work with (there are plenty and they are great — from the BCG matrix to systems mapping), but in the sense that there is a lack of universal meta-models, or models on how to build models.

What I propose here is a work-in-progress methodology to work around some of these problems. The methodology is broadly composed of a set of interconnected frameworks that illustrate the problem solving “project system” and each step of an ideal, effective problem-solving process; and of a toolkit, the mental models repository, which includes 500+ mental models that can be used either directly or metaphorically as a part of the problem solving process.

The problem-solving framework

The three systems of problem solving

Imagine you’re in the countryside on a sunny day, looking at a beautiful flower in the middle of a lawn. You see the flower and its colors, you can touch it, you can smell it. It’s not a problem yet, it’s just a thing out there in the world. Reality per se is unproblematic. The problem emerges when realty is met by human consciousness.

What humans tend to do when facing reality is to try to explain it, unpack its functioning and causes, and to change it, usually to adapt it to some goal that is functional to humans. These two core human activities are the key of problem, and they encompass most of what people do.

Problem solving has two components: knowledge creation and action.

The acquisition of knowledge is always a prerequisite for action. Some problems only require the acquisition of knowledge, some require acquiring knowledge and acting upon the world. The former tend to be the focus of scientific domains, the latter involve are what we call creative problem solving (which includes engineering and many applied sciences).

So how do problems emerge? They emerge when one or more people look at reality through the lenses of their a-priori knowledge and experience with some explanatory or poietic intent². Whenever we look at reality through a-priori³ knowledge (practically always) and with explanatory or poietic intent, three systems emerge in our cognition:

A problem system, whose boundaries are defined by our knowledge and intent, containing all the relevant entities and relationships of the problem.
A project system, which contains the problem solver and any other element that will help construct the solution — raw materials, compute, people, etc.
A solution system, which can also be called problem 2 system, in which a solution is created and iterated upon.

In the vast majority of non-trivial cases, these will be open complex adaptive systems, subject to all the properties thereof. Each system includes:

Entities and actors that are part of the system
Relationships between said entities -eg. causation, co-variance, etc. as well as reinforcing and balancing loops
Emergence: most system are more than the sum of their parts
Dynamics: a system as a whole usually evolves in time

So how does the process of problem-solving work? The act of problem-solving transfers entropy from a problem system to a project system to create a lower-entropy solution system. The process of transferring entropy requires energy, and energy is expended by the problem solver (in the project system) in the form of physical energy, compute, human thought and other resources.

Two types of entropy are transferred:

Informational entropy is transferred from the problem system to the project system by research and analysis, by the act of observing reality through lenses that collapse the infinity of possible meanings of the world into a set of interesting meanings, and then to a handful of useful meanings. More on this below.
Physical entropy is transferred from the problem system to the project system by the creation of a physical solution.

Knowledge acquisition reduces informational entropy in the project system. For example, I could be looking at a flower in a field. In an undetermined project system, the flower could be “trying to tell me” anything and everything, therefore there’s a high level of information entropy to my observation. If I’m an entomologist, however, I may be looking at the flower and see a lilac at a particular stage of its blooming cycle. If I’m a biologist, I’ll be thinking about the flower’s photosynthetic cycle, if I’m an artist about the beauty of the light reflected in the droplets of water on the flower’s leaves, and of the way it can be represented in two and three dimensions. If I’m an agronomist I may be observing that it is growing in a highly oxidized solid, and if I am a businessman I may be thinking estimating that these types of flowers can be grown for under 20 cents a unit and are sold for more than 20$.

Each lens I apply when looking at the flower adds a layer to the information that reaches me about it. So from a very confused, general, high potential message, I move to receiving a very clear, specific set of messages.

Not every message, however, will work for every problem. So while being able to look at an object from multiple lenses at a time is an incredibly enriching, intellectually stimulating experience, multiple lenses still make for a relatively high-information entropy observation. For problem solving purposes, we need to collapse a real world object into one specific, problem-relevant messages, and to do that we need to be using the RIGHT lens.

How are the boundaries of the three systems defined?

In a sense, problem solving intent defines the boundaries of the problem system, which contains entities and relationships that may be known or unknown with some, even very indirect, relationship to my problem statement. The project system will span a theoretical component, defined by the set of my a-priori available lenses, and an empirical one, which will include all the data of the problem system which I deem to be relevant. Additionally, it will include other “infrastructural” elements that are not a part of the problem but which constitute a mental or physical scaffolding used for problem solving. For example, in UX design the project system will include a design software like Figma and the designer themselves, which are not a part of the problem nor of the solution. Finally, the solution system will include the output of the project whether it be intended or unintended.

The six problem-solving stages

From the layout described above, a four-way breakdown of the project system emerges:

General knowledge is the non-empirical part of the project space
Context knowledge consists of empirical data from the problem space that has been included in the project space.
Models that synthesize a priori knowledge and empirical data are the core part of the project, not yet of the solution
Experiments or prototypes created on the basis of models are the building blocks of the solution, but still a part of the project system

Here is the same content, visualized in a simpler chart focusing on the project system:

As we have seen, a project always involves using general knowledge to interpret context knowledge and build a model of reality. In projects that involve an “action” phase we move on to prototype a solution and error-correct through experiments.

Thus a project unfolds in six stages:

Interpretation and problem definition: becoming aware of the a-priori lenses we use in diving into a problem, and defining the problem statement.
Researching, Projection, abstraction, representation: diving into the empirical, collecting data, selecting the relevant data points and discarding the irrelevant ones, projecting a multi-dimensional reality into knowledge we can handle.
Model building: creating a model that maps the problem based on general knowledge and empirical data, that involves an implicit or explicit hypothesis, which can be descriptive, predictive or prescriptive in nature.
Prototyping: building the first version of a solution or an experiment
Error correction: testing our solution or running the experiment, getting empirical feedback and iterating thereupon.

Project types

Projects can range widely. From explaining a physical or biological phenomenon to building a bridge to increasing efficiency at a factory, they may seem to have nothing in common. And yet they do. Almost all project can be boiled down to one of these categories:

Explain: explaining why thing are the way they are, appear the way they do, and how they got there. Most scientific projects fall in this bucket.
Grow/scale: understanding how an existing system can scale given certain constraints
Optimize/fix: working on the constraints themselves.

Growth and optimization projects both require some kind of explanation, often left implicit.

Note that, while all projects boil down to one of the three project categories, this may not immediately be apparent from the problem statement. In order to identify the category under which a problem should fall, we can use this slightly modified version of the well known challenge mapping framework (which as far as I’m able to figure is due to Dr. Sid Parnes).

Projects can also be grouped by scope, i.e. by which of the six core phases they focus on. This is done based on the extent of existing knowledge of the three systems:

The Mental Model Navigator

In parallel to this framework, I have worked for years on collecting interesting mental models, starting with those listed by great people such as Gabriel Weinberg and Guruwinder Bhogal, whose models and descriptions I sometimes directly lifted (and credited). Additional sources of inspiration are the Farnam Street blog and RibbonFarm. Compared to these sources, I created a much more extensive list of mental models (500+) by extending the very understanding of what constitutes one, and tagged most of them with keyword that can speed up their identification and application in specific problems.

So what are mental models (not to be confused with simply models from the modeling stage of projects)? In a sense, they are all a-priori lenses through which we understand problems. Yet they don’t all apply to the interpretations stage of the problem-solving process. Many of them are relevant for abstraction and representation (eg. statistical distributions), model building (eg. games from game theory), or error correction (eg. cognitive biases). Many are relevant for multiple stages.

Not only do mental models enable us to better understand concepts and relationships: they augment our vision of reality with additional layers of beauty and complexity, thus truly enriching every experience in our life.

Mental model navigator v1.0 — second version to be released based on Airtable’s backlog

Diving into each problem stage

Interpretation and problem definition

Before we even start a project there are the concepts, ideas, heuristics and biases, in other words interpretation lenses, we already have in our minds. The emphasis on this a-priori aspect of problem solving comes from a fallibilist, non-empiricist interpretation of the scientific method, which I think can be applied also to problem-solving. As summarized by David Deutsch in The Beginning of Infinity, “We never know any data before interpreting it through theories. All observations are, as Popper put it, theory-laden, and hence fallible, as all our theories are.”

We always see the world through lenses, assumptions and biases, and problems only emerge through these lenses. The world out there is a real thing, but it’s only our lenses that make it problematic (and interesting, for that matter). A good problem solver is aware of these lenses, leverages the useful ones, discards the harmful ones in any given context, and uses them to formulate hypotheses, or tentative theories, that are validated or discarded based on testing and observation.

What are these lenses then? Some of them are universal (laws of nature), some are domain specific (domain knowledge from related or unrelated domains), some are person-specific (psychology of the problem-solver).

Find them on the Mental Model Navigator under the “interpretation lenses” project stage.

2. Researching, projection, abstraction, representation

This phase involves diving into the empirical, collecting data, selecting the relevant data points and discarding the irrelevant ones, projecting a multi-dimensional reality into knowledge we can handle.

In qualitative processes, the researching part can be extensive, but projection, abstraction and representation typically happen subconsciously based on our lenses and filters.

In quantitative projects, part is unconscious (bias), but the problem-solver typically tries to “engineer the features”, to pick the elements of reality that will be more useful for building a model.

3. Model building

In this phase, the problem-solver builds a model of the world that encompasses the problem and possibly the solution system. The model is the synthetic way in which we express the current state of our knowledge on a topic in scope, a map for our problem territory.

A model should be a good map. Not a bad map, not the territory.

Models can be descriptive, predictive or prescriptive. Predictive models require the creation of descriptive ones, prescriptive models require description (and usually prediction).

A descriptive model can focus on different aspects of the problem system: form, purpose/meaning, structure/architecture, behavior/functioning, cause/origin. The output of these models will typically be a hypothesis, an argument or an explanation .
Predictive models will usually add a dynamics, i.e. how the system as a whole (not just its components) will evolve in the future. The output of these models will logically be a prediction.
A prescriptive model will specify interventions that will be performed on the system, at different possible levels (from sub-component to systemic). The output of these models will be a prototype or experiment.

How do we know if a model is good? For a descriptive model, which is ultimately an argument or an explanation, we look at soundness or persuasiveness. For others generalizability will be very important. For predictions, we’ll be looking at accuracy, precision and recall. And for prescriptive models, we’ll need to define ad hoc KPIs to evaluate the results of our actions.

Additionally, every model is a theory, so we need to evaluate them as such. A good theory explains a wide range of phenomena in a non trivial, hard to change way. Ideally, it should also be falsifiable, parsimonious and elegant.

Additionally, not all models need to be as good. In the business world, we are typically happy if we have an ok model that explains 80% of the situation. A scientific-grade model needs to perform much better, and typically takes longer to develop.

Here is a further breakdown of model types:

4. Prototyping

WIP

5. Error correction

WIP

Notes

¹ I don’t mean under-theorized in academic contexts, I am sure there is a great deal of academic theories that have been formulated on these topics. I mean in practical applications, especially in the business sector. These concepts are usually not taught in business schools nor they are a part of a consultant’s trainings, as I think they should be.

² By poietic I mean the intent of bringing something new into the world that didn’t exist before.

³ By a-priori I don’t mean necessarily a-priori from any kind of experience, like Kant’s categories. I mean concepts that precede our experience of the specific reality which will become the problem system.