What Is Problem Formulation? How to Define and Structure Problems

Problem formulation is a structured analytical method used to analyze, define, and deconstruct a vague, complex problem before you implement a solution.

Why spend time formulating a problem? It turns a vague, overwhelming problem into a clear structure before you act. For a complicated problem, we can break a huge issue down into smaller, independent parts and solve the entire problem by solving those smaller pieces. For a complex problem, we can narrow down its context and variables to identify the true root cause. Either way, this saves massive amounts of time and effort.

Problem Statement vs Problem Formulation

Problem Statement and Problem Formulation are often used interchangeably within day-to-day work. However, these two are quite different. They are at different points of reasoning and have very different outputs:

Breakdown	Problem Statement	Problem Formulation
Logic	Works using the same logic as defining a concept.	A process that has occurred to deconstruct a problem and expand into a Logic Tree.
Purpose	Macro Definition: Defines what needs to be solved or improved. The gap between current state and goal.	Structural Deconstruction: Removing pre-requisites, limiting the context or breaking down causal branches to identify sub problems and root causes.
Output	A short written definition that sets boundaries.	A multi layer tree that shows dependency and causality.
Function	Defines the Target: Answers “What is the issue we are looking at?”	Helps Solve: Directly helps solving by breaking down the problem.

A Problem Statement is used to define the problem at a high level. Whereas Problem Formulation is used to help solve the problem.

A Walkthrough Example: The Two Core Steps of Problem Formulation

Let’s take the subject of this article and apply it to the example. Let’s say we have two similar questions:

1. How to formulate a problem?

2. What is problem formulation?

Now, analysing both questions we can see that we need to answer them in two very different ways:

Firstly, the first question begins with How to which indicates that we need to find a method to fix the problem.

Secondly, the second question begins with What is which means we will need to define an answer that differentiates this concept from all others (e.g. A method belonging to the research and analytical field that comes before the implementation of a solution).

There is also a strong dependency here. To answer the first question we must first answer the second question. How can someone provide a practical answer if they don’t even know what the concepts are? Methodology problems always require you to have some base knowledge or experience.

This shows us two core steps to problem formulation.

Categorising the problem within a category. We categorise How to formulate a problem into the category of method.

Vertical differentiation. Asking what we need to do to solve this problem. In our example we need to first have a clear definition of the problem. However, this is just one requirement that we need to meet. Not all of the sub-problems of question one will be solved by just meeting this one requirement.

Deconstructing the Problem: How to Isolate the True Root Cause

To move from an opaque system to a clear one, or to discover its underlying root cause, you’ll need to deconstruct the problem.

Before deconstructing any problem, you need to determine whether the problem you are facing is either a Complicated Problem, Complex Problem, or Wicked Problem. I’m not going to repeat the underlying scale and definitions here so if you haven’t already read this article then make sure to read our full breakdown here What Is A Complex Problem?.

This is important because, whilst each type of problem can be deconstructed to create a tree like logical diagram, how you approach deconstruction will differ depending on the type of problem you have.

1. Complicated Problems: Top-Down Decomposition into Sub-Problems

When faced with complicated problems, decomposing into sub-problems is actually perfectly valid. This is because the problem is composed of deterministic and independent causal sub-components.

For example:

Take a classic everyday example: “What do I do when my car won’t start?”

You do not need to consider the open ended environmental variables like “What architectural style of garage is the car parked in?""Did today’s cloudy weather affect the car’s mood?” etc. Instead we can take a look at the causal chain of the internal combustion engine and utilise a MECE tree decomposition.

We can immediately break down the problem into:

A - Starter motor does not turn at all (caused by power or starter control issues)

B - Starter motor turns strongly but engine will not start (caused by fuel, air, ignition or compression issues)

This is a perfect example of top-down decomposition. We have broken down the issue into Engine won't start → Does the starter crank? → Fuel / Electrical / Air / Compression. Each leaf within our tree can be tested independently. For example if your battery is low, you can simply use a multimeter to check the voltage. If your spark plugs are not firing then you can check that. If your fuel rail is not delivering enough pressure you can check that.

Why does this work so well?

Because the causal components are static, unidirectional and reversible. Once you have replaced the old dead battery with a new one, it will not cause any issues with the alternator or cause the ignition coils to act in an unexpected way. As long as you replace the faulty component on the faulty branch then the input-output relationship of the whole system will return to how it was intended. There will never be a situation where pressing button A will cause a cascade failure in dimension B.

2. Complex Problems: Enriching Context and System Variables

When we’re faced with a complex problem, we shouldn’t try to reduce the problem into loosely connected sub problems. Instead we need to look at the problem in more detail from the inside out.

Let’s take a common example:

Consider a common example: “What should I do if my plant’s leaves are turning yellow?”

In this example, we only have the words plant and leaves, which are far too vague. So we’ll need to start looking at the variables involved and enrich them.

Which plant is it? Is it an outdoor tree, desert succulent or indoor potted plant?

Are they the oldest leaves at the bottom of the plant? Are they new leaves at the top of the plant? Are they on the outside?

What does the plant naturally grow in? Does it prefer indirect light, or direct sunlight? Does it want lots of moisture but hate sitting in water?

Now we’ve got some specifics on the tightly connected variables we can create a rich context.

“In a relatively enclosed indoor pot environment, this Golden Pothos—which likes indirect light and moisture but hates waterlogging and stuffy air—is starting to develop yellow, dropping leaves right along the oldest bottom layer closest to the soil surface.”

As you can see we’ve narrowed the problem down by specifying which plant (Golden Pothos), location (contained indoor pot) and issue (oldest bottom leaves turning yellow and falling off).

Why wouldn’t we use the Complicated Problem approach?

This is because there are many tightly linked variables. Once you start to enrich the scenario, let’s say you intuitively come up with a potential root cause of the issue (“The soil has been waterlogged and unventilated for too long, so I overwatered it”) and then try to solve it by doing the obvious solution (“Water less, loosen the soil frequently, and ventilate more.”). You could easily make the issue worse. This is because in a low airflow, high humidity environment, constantly disturbing the soil will not help it evaporate quicker. It would actually cause damage to the sensitive root zone and cause the porous soil to soak up more of the moist air.

Next Step: Using Logic Trees to Structure Your Formulated Problem

The key thing to remember is that a Logic Tree is a tool that can be used proactively (when you know nothing about the actual problem you have) to help understand if you need to increase the internal context or break up the physical components. Or it can be used to help structure your ideas once you have explored the problem. The key purpose of understanding the problem is so you can use it to determine how you will solve it. We have detailed the full walk-through of creating a diagnostic and solution tree (and cutting back on branches based on real world experience) in Logic Tree: How to Break Down Complex Problems and Find the True Root Cause.

Frequently Asked Questions (FAQ)

When should I use Problem Formulation?

You should always use Problem Formulation before trying to implement a solution. By breaking down the problem into smaller sub problems or finding the root cause of the issue you avoid wasting time solving an issue that isn’t the one you need to be solving.

What is the difference between a Problem Statement and Problem Formulation?

A Problem Statement is a conceptual macro view of a problem. It details what the gap is between the current situation and the goal. A Problem Formulation is the process of breaking down the problem into a structured Logic Tree.

Why do complicated and complex problems need to be broken down differently?

Complicated problems (e.g. Car won’t start) are made up of deterministic and independent components. This means that you can easily break them down into components from the top down. Complex problems (e.g. Indoor plant has yellowing leaves) are made up of highly dependent variables. Any changes to a single variable can cause further damage so it is important to look internally first and add more context to the scenario. This will narrow down the highly correlated environmental variables.

---

References

• Harvard Graduate School of Education: How to Focus Your Problem Statement (PDF)
• Wikipedia: Problem Statement
• Wikipedia: Venn Diagram
• ScienceDirect: Problem Formulation