A Latticework of Mental Models
— Part 3 of Modeling in Problem Solving —
This article will make much more sense if you read installment one and two first!
Innovating with Frameworks and Problem statements
Archeologists researching early medieval Britain have for centuries interpreted skeletons, material remains and artistic production as evidence for a mighty Anglo-Saxon invasion from the Jutland peninsula, following the description of 7th century historian the Bede.
More recent scholarship questions not only the idea of an invasion, but even of a significant increase in immigration, from continental Europe. Data from the ground has improved, thanks to more excavations and new techniques like carbon dating and ancient DNA; but even more importantly, once one questions Bede’s invasion narrative, one can wonder whether a corpse buried with a Jutland-style brooch actually reflects a Saxon invader, or rather a local Briton who was in contact with Jute trends, or even simply increased imports of Jute brooches in 5th Century Britain. So while the data is the same, the way we contextualize it has changed — our framework has changed.
Even more deeply: the questions we ask of the findings have changed. Once upon a time the core research question of British archeology may have been “can we find the remains of King Arthur”. In time, the questions have evolved to “What made the Anglo Saxons superior to the local Britons” (with racial undertones, early XX Century), and then “Did the life of common peasants change at all as a result of the dissolution of the Roman Empire?” (the so called Longue durée approach, mid-XX Century). More recently, the questions asked by archeology have moved to topics that are felt as very relevant today, such as “What did people living in the British Isles in the 5th and 6th century identify as?” and “How did climate change affect population movement in medieval Europe?”
As disciplines in which arguably new facts come to light slower than new interpretations, history and archeology are perfect to illustrate the importance of frameworks and problem statements in problem solving. But as we shall see in depth in this article, this applies to all disciplines, and particularly in problem-solving.
In the first article of this series we introduced the Problem Solving Map (PSM) and discussed the hermeneutic loop of problem solving, illustrating how knowledge in projects is created in a dialectic between wholes and parts by iteratively using a-priori frameworks to contextualize a-posteriori data, and integrating the latter into the former.
In the second installment, we discussed in depth what models are, and delved in detail into two of their key components: data (and variables) and reason. We also briefly introduced the Problem-Solving Canvas, which operationalizes the Hermeneutic loop into a handy project prop.
In this installment, we’ll explore the last component of models, frameworks, and learn about the block on the left of the Problem Solving Canvas: problem statements. We will also present the Mental Model Navigator, a searchable database of mental models curated for this project, and run through an example of how the Problem Solving Canvas can be used in a project.
An ontology of frameworks
Let’s start with frameworks.
As we can see from their placement in the Problem Solving Map, frameworks are characterized by being a-priori relatively to the project- that is, before starting the project, we already know them. Frameworks are not the only kind of a-priori knowledge we possess at the beginning of the project: in a sense, the entirety of our past experiences constitutes what in article 1 we called “the world of a-prioris”, tinged by any mood or bias we may have in approaching the project.
While all of this counts as a-priori knowledge, as the lenses through which we look at the project as we approach it, frameworks are a special kind of knowledge, one that is particularly useful to consultants:
Frameworks or mental models are reusable “templates” for thought, which, once learned, can be used to model multiple problems.
We distinguish frameworks from domain knowledge in that frameworks are widely applicable, either directly or metaphorically. For example, evolution by variation and selection is more than just knowledge that belongs to the biology domain: it a general rule that can be fruitfully applied to other fields, like economics or business.
At this point is it essential to clarify the relationship between frameworks and models. Frameworks are often known in the literature as mental models, which is quite confusing. In the example below, the framework and the model also look quite alike, as they often do. The clear and simple difference is that models contain (project) data, while frameworks don’t. Models apply one or more frameworks. Of course, sometimes we find models we create during projects have some degree of reusability: in that case, they may enter our portfolio of frameworks to be used in future projects.
Given the proliferation of frameworks in the management discipline, it’s no wonder some of the sharpest “model thinkers” have come from the world of business. Berkshire Hathaway co-founder Charlie Munger may be one of the best known:
To become wise you’ve got to have models in your head. And you’ve got to array your experience — both vicarious and direct — on this latticework of models. — Charlie Munger, quoted in Peter Bevelin’s Seeking Wisdom from Darwin to Munger
As evident form Munger’s statement, the key to using frameworks (which he calls “models”) is to know many and use them. University of Michigan professor Scott E. Page has come up with two mathematical demonstrations of why multiple models are better than one. Here is the simpler one based on the Condorcet jury theorem:
Each of an odd number of people (models) classifies an unknown state of the world as either true or false. Each person (model) classifies correctly with a probability p > 1/2, and the probability that any person (model) classifies correctly is statistically independent of the correctness of any other person (model).
Condorcet jury theorem: A majority vote classifies correctly with higher probability than any person (model), and as the number of people (models) becomes large, the accuracy of the majority vote approaches 100%[…]
“ Hence our truth is the intersection of independent lies.” (quoting Richard Levins)
Scott E Page, The Model Thinker: What You Need to Know to Make Data Work for You¹
This translates very directly into problem solving. For example, our friend Priscilla the Professional Problem Solver may be acquainted with different ways to look at waste in a production process, so she may be able to classify it as muda, muri or mura and use the principles of lean manufacturing to reduce it.
But different a-priori lenses will yield radically different views of the same landscape. Priscilla could use a simple heuristic like reduce, reuse, recycle to describe a normative framework for dealing with waste; she could think about the circular economy and circular design principles to design waste out of production; she could want to assess the factory’s impact within the framework of ESGs; or she could create a systems map to identify the systemic impact of the production process and find leverage points.
But all these are still “obvious” lenses. What about using her knowledge of ancient history to reflect on how ancient civilizations processed waste, and her knowledge of literature to create opportunity spaces titled “A psychohistory of waste” and “Something is rotten in the stators production line”? What about taking inspiration from convergent evolutionary theories to inspire a modular product that reduces waste? What about using game theory to model the incentives of different players to create more or less waste? All of these are legitimate tools of problem solving, “independent lies” that together help us come up with novel ways to look at the problem and devise possible solutions.
But — Ken Chick, Priscilla’s hesitant colleague objects- we are paid to do an operations project… Do we really need all of these additional frameworks? What will the client say?
And this is the crux of the consultant’s dilemma.
We typically sell solutions using specific methodologies, but the truth is that the problem space is not compartmentalized. It is one large continuum of knowledge that can be sliced and diced in many different ways by using different frameworks.
And until we hit diminishing returns, a huge amount of value is added to any problem by analyzing it through several different frameworks.
Categorizing frameworks
In the example we saw above, we mentioned several widely different types of frameworks.
Some of them are very obvious problem-solving tools: systems mapping mentioned above, for example; design thinking, Scrum, the BCG matrix; these are all methods, the most “explicit” kind of framework. Methods give us a step-by-step way to achieve a result given certain variables. But there are also more implicit ones.
Other frameworks are not quite as precise. Rather than being series of steps, they are more like heuristics or principles that give us a rough direction for thought. Examples include such as “reduce, reuse, recycle”, the Occam razor, the ESG principles or the Pareto principle.
Simple concepts from all disciplines can work as frameworks in that they can inspire our selection of variables or their relationship. An example among those mentioned above could be the scientific concept of convergent evolution, or the science-fictional one of psychohistory.
Finally the “widest” type of framework is a theory, which is itself in a sense a collection of frameworks. In many cases, however, it can function as an inspiration framework itself. Examples could include natural selection, emergence, game theory, etc.
This very loose classification gives us a sense of the variety of frameworks in terms of “width” or “size”.
Another way to classify frameworks is around what they help us model.
As we mentioned in the first article, there’s a sense in which anything can be a model of anything. However, some frameworks work better than others with different kinds of datasets. This is due to the fundamentally emergent nature of reality.
Just like the intellectual tools we use to think of the motion of individual particles are different from the ones we use to think about a gas moving in a room or the movement of hurricanes, so different frameworks can be useful to model the world at different levels of analysis.
One way to break down levels of analysis could be as follows:
- Thing frameworks tell us something about what inanimate things are and how they change in time. These include a huge range of frameworks from the world of mathematics, physics, biology, etc.
- By adding consciousness, we get agent frameworks, among which we find behavioral and cognitive models, games from game theory, agent-based decision models, etc.
- System frameworks model groups of interrelated agents, adding feedback loops into the mix. These include system maps and system archetypes, system dynamics and networks.
- Finally, Meaning frameworks include an element of meaning. This can feel a bit intangible, but it basically has to do with the impact the model should have on the modeler. This includes ethical theories, normative frameworks and
So how do we make it a practice to get acquainted with and use multiple frameworks?
There are several possible approaches. One would be to establish a limited number of essential framework or mental models that everyone should know, learn them and then repeatedly use them. For example, a few years ago McKinsey advocated leveraging a set or five lenses, which they called “flexons”, to look at business problems through. New insights, they argued can come from looking at problem through the lens of networks, evolution, decision-agents, system dynamics and information processing.
Another approach is to have a more extensive list of concepts, learn as many of them as possible in advance and keep adding more, and letting them surface consciously or unconsciously during our problem solving activities. People advocating this approach have developed extensive lists of frameworks that can be useful in many situation. One of the earliest and most influential is certainly Gabriel Weinberg’s Mental models I found repeatedly useful. Others have their own lists (a great one is Gurwinder Bohgal’s).
For years now, I have curated my own list, counting now more than 500 frameworks and concepts — which for this project I turned into a tool- the Mental Model Navigator, built on Airtable. Unlike other collections, I have been very wide in my understanding of what can be considered a mental model. So beyond obvious tools (like the BJ Fogg behavioral model) and concepts like cognitive biases and business frameworks, I have tried to purposefully incorporate concepts coming from the arts and humanities (eg. the idea of sublime, Koan, cubism). These are usually not directly translatable into a “solution”, but the idea is that they enrich the problem solver knowledge of different aspects of the world and, at the appropriate time, they may surface into consciousness and provide useful inspiration and novel metaphorical interpretations of reality.
The Mental Model Navigator is built on Airtable, and due to Airtable restrictions, it can only be shared via email (and you need an Airtable account to access it).
If you are interested in gaining access to the Navigator, you can leave your email in this Google form.
Problem statements
Having explored frameworks, let’s examine problem statements. We are tackling this last, but obviously they are the starting point in problem solving. It goes without saying that a good formulation of the problem statement is critical to the project’s success. A good problem statement can either put us on track to an amazing solution or lead us astray.
Interestingly, studies show that for companies often don’t spend enough time figuring out exactly which problem they are solving. A study byOhio State University found that more than half of 350 surveyed executived failed to achieve desired results, often because perceived time pressure caused people to pay insufficient attention to examining problems from all angles and exploring their complexities. [Feb 2024 edit]
As hinted at earlier, the problem statement is not the brief. It typically takes a few good days of work to get from the brief to the problem statement. This is because in order to actually start working on a problem, we need to figure out at least a few things:
- What are the boundaries of the problem? What, in the PSM, are the boundaries of the “actual world” area that we consider of interest?
- Why is this a problem at all? What is standing in the way?
- What is the level of ambition for the solution? Are we looking at completely redefining the as-is or for quick wins?
All of the questions above can be summarized with “what is the level of analysis at which we are looking at the problem?”. Just like, as we have seen in the previous article, our thought can move inductively “up” or deductively “down” between frameworks and data, so we can move “up” or “down” levels of analysis when thinking of how to formulate a problem.
To better understand this, let’s use a variation of the challenge mapping framework, an excellent exercise devised as far as I know by Min Basadur.
We start with the problem as originally formulated in the brief, for example, how might we create a better online banking system for our clients. The “How might we” formulation, very common in design thinking and going back to P&G and IDEO in the ’70, is useful to give some consistency to our statement and keep them fairly open, and is equally applicable to non-design related business problems.
What are the constituent elements of our problem? What sub-problems do we need to solve if we want to solve our main problem?
We can identify them by asking the question “what is stopping us”, or “what are the constraints”, focusing in turns on the different words of the original statement. For example, to unpack how might we create a better online banking system for our client, we may:
- Unpack the word “better”: we may have more precise constraints in terms of KPIs for what we are building, eg. having faster processing time, higher NPS, lower maintenance costs, making our client’s life easier, etc.
- Unpack “online banking system”: here we can look at the different parts of the system, for example creating an easy onboarding, simple client transactions etc.
- Unpack “our client”: we can break it down into sub-segments: millennial urban dog-owners in the UK, snowboarder moms, etc.
This way we are starting to capture the problem in all of its aspects and components. One level down from the main problem statement, constraints will usually be a part of the brief. The idea with this exercise, however, is to do it iteratively. As we start descending further, we may realize that the problem involves novel elements that we have’t thought about.
As we do these breakdowns, we’ll realize that sometimes we can be MECE (mutually exclusive, collectively exhaustive) — for example in breaking down the client segments, and sometimes it’s harder to do so.
For example, it may be hard to be fully “mutually exclusive” when describing different parts of a large scale software because different parts rely on each other and overlap; and it may be hard to be “collectively exhaustive” when tackling a goal like “improving the life of the customer”.
Ultimately, the MECE-ness of a level of analysis in a problem is a measure of its complexity. If we can’t do a MECE breakdown of a problem, it likely means that between two levels we have emergent effects, that the whole is more than the sum of its parts.
Higher complexity calls for slightly different approaches in problem-solving, such as more iterations around the hermeneutic loop and faster prototyping and deployment. What this exercise helps us highlight, however, is that some aspects of a problem may be more complex than others.
Besides breaking down problem, we can also “go up” in level of analysis. We do that by asking “why”, “what for”. Why create a better banking system? In order to increase customer retention. Why increase customer retention? In order to increase our revenues. This exercise is very useful as it helps us highlight alternative patterns to the ultimate — usually unstated- goal of the client, broadening our attention spotlight and highlighting alternative paths. This type of questioning is the very essence of strategic thinking.
Interestingly, the overwhelming majority of business problems have the property, when properly questioned with “why”, to boil down to increasing growth, increasing efficiency, and possibly reducing risk. That’s it². This is reassuring, because while every problem we’ll be solving has its own flavor, ultimately we are, in a sense, always solving the same problems.
One final thing of note is that emergence effects between levels are such that different disciplines have developed to solve problems at different levels. Just like for frameworks, a good problem solver will be able to “play” with the problem at different levels and reflect on the meta-aspects of the problem, while domain experts will be called upon to solve specific issues at a given level.
This is Part 3 of a series on Modeling in Problem Solving. Check out part 4.
Notes
¹ Scott Page’s book is a highly recommended resource. To avoid confusion, it’s worth noting that his ontology does not make the distinction made here between models and frameworks.
² Or rather: one level up from here we’ll get into issues of “business purpose”; two levels up and we’ll be raising questions relating to the meaning of life which should perhaps be left unasked.
