How break down complex problems

June, 2021

In our effort to build great things, we often encounter complex problems. The best way to solve a complex problem is never to make a complex solution. By making complex solutions we often paint ourselves into a corner, and introduce new problems. It’s better to make simple solutions. And to do that, we have to overcome complexity. We are looking for simplicity on the other side of complexity, not naive, uninformed simplicity.

Why simple solutions?

Simple is faster
Simple is more profitable
Simple means less headache
Simple means fewer problems
Simple means easier problems
Simple let’s you change direction faster

Simply: simple systems are easy to change and easy to understand

Complex systems are braided together in a way that makes it hard to predict what a change in one part of may affect in another part.

Tools for making the complex simpler

These tools may help you to think about simplicity, and evaluate whether you are on your way to create something simple

Understand the problem

The first thing you have to do is understand the problem. Too often we design and build solutions without really articulating the problem. So write it down. If you cannot state the problem in one or two sentences, you don’t understand it.

**“If I had 1 hour to solve a problem, I would spend 55 minutes thinking about the problem and 5 minutes thinking about solution”

Albert Einstein**

Break things apart

Simple means untangled. Something that can stand alone, and that is about only one or a few things. It’s not interconnected with a lot of other stuff. So to make something complex simpler, we start by breaking it apart. Your mind can only keep track of a very few things at once, and everything that is interconnected has to be considered together. So we should try to untangle the problem by breaking it apart. Below are a few ways of breaking the problem apart:

Rich Hickey says (paraphrased): “Great design is taking things apart so you can put them back together. You can compose [the parts] to solve a problem”.

(See links to talks by Hickey at the bottom).

Break the problem into sub-problems or sub-systems

Often a problem is connected to other problems. There may be a chain or collection of problems that are resulting in the problem you are experiencing.

Break the problem into requirements

If you figured out who is experiencing the problem, break it into requirements. What does the one experiencing the problem need? What’s needed to solve the problem?

Figure out what is known and what is unknown

There are often parts of the problems that are known to us, and that we know how to handle. List them up, and figure out what parts of the problem that we don’t know, or don’t know how to fix.

Break it down into flows

Similar to the when exploration. When in the process/system is the problem happening? Is there different problems at different times, or is the same problem happening at different times? Think about workflows, processes, dataflows, etc..

Break it into different places

Is it happening everywhere or just somewhere? Some specific places, areas?

Break it into different people

The problem may be happening to some people, or some groups of people. Is it poor understanding, cultural differences, poor training, handicaps? Again knowing who is experiencing the problem gains clarity.

Break it into different solutions

You’ll probably have more ideas for solutions, which usually happens even before you have articulated the problem, or during the deconstruction. Write down the solutions and list the different benefits, tradeoffs, costs and, most importantly, how it fits the problem. If you have come up with a solution before articulating the problem, chances are you’ll have come up with a solution that doesn’t really fit the problem.

Find out when the problem is happening

What Clayton Christensen and Bob Moesta figured out in their Jobs-to-be-done theory is the importance of understanding when you have the problem. We’ve been thought to look for why it’s happening. When in the process is the problem happening? Is it happening at multiple points or is there different problems happening at different times? By understanding when and to whom, we may get a clearer picture.

Find the Root Cause

Finind the root cause means you find the underlying problem. It works by asking “Why” 5 times in a row to dig through the problems. It forces you to see beyond the immediate problem. See the next section for which questions to ask.

Ask stupid questions

Ask the obvious questions that no one is asking. It’s the questions where the answers are obvious, but you know there’s something wrong. If the “obvious” answers are: “it’s always been done this way”, “it’s just how we do it” or “it’s how it is”, these are not stupid questions. They are in fact very valuable questions. Examples of questions that will elicit “obvious answers”:

Why are we doing it that way?
Why is that there?
What’s the reason for this?
Why does this cost so much?
What really is the price of this?
What are we really selling?
Who knows a lot, but nodoby else know anyhing?

(Nick Kokonas, owner of Alinea, has some fantastic stories related to this point - links to podcasts at the bottom.)

Be irrational and illogical

When you have deconstructed and worked your way through the problem, you may still find it hard to find a simple solution. There are some tricks you can use, and Rory Sutherland (link his book Alchemy at the bottom) has some great methods:

Look for things that people really can’t articulate, or parts of the problem you really can’t articulate

Test counterintuitive things. As “some of the most valuable discoveries don’t make sense at first”. Test and figure out what’s working and what’s not.

“Solving problems using only rationality is like playing golf using only one club”. People are not logical and rational. And the problems we seek to solve usually involves people. So look for solutions through different lenses.

What does a good simple solution look like?

A good, simple, solution have some traits:

It solves the problem without introducing new problems.
It’s easy make changes without breaking other parts of the system.
It’s easy to comprehend.
It can stand alone and is not tangled with everything else.

PS: I made a little handbook for solving complex problems. You can find it here: https://pslabs.gumroad.com/l/solveit

Resources & References

If you want to explore this topic further, I’ve gathered a collection of some related resources and links:

Josh Waitzkin has this notion of “simplicity on the other side of complexity”. He is a master of breaking down the complex.

The Art of Learning - where he talks about breaking down the complex into simple parts you can learn, understand and train.

His podcasts with Tim Ferriss is a great way to get inside his mind:

Paul Graham is a master in breaking things down. Here are two of his essays that I found valuable in this research.

Rich Hickey is the person that really got me dragged into this whole simplicity theme. Below are some great talks.

Systemantics - The Systems Bible by John Gall. Great and funny book that explores the problem with complex systems, complex problems and complex solutions.

Nick Kokonas is the person that got me thinking more about the stupid questions. His stupid questions led to deposits and prepayments for restaurant bookings, self publishing books, getting 50% off meat for their restaurant and starting Tock. Get inside his mind on these podcasts:

Alchemy by Rory Sutherland explores counterintuitive solutions to problems

Gigerenzer’s simple rules. Gerd Gigerenzer has researched how simple rules of thumb, heuristics, outperform complex models. In investing a 1/N strategy outperforms any complex model

**Nassim Taleb **is a fan of simple rules to navigate an uncertain world. He has gathered some of his own here:

Thinking Fast and Slow by Daniel Kahneman. Since we cannot understand everything that is happening around us, we use simple rules of thump to navigate the world. This book is the one that made mental model and biases all the rage.