How to break a big problem into smaller problems

When a problem feels too big to start, the fix is rarely more willpower. It is to break a big problem into smaller problems, each one small enough that you can try something this week and see if it worked. This guide shows you a simple way to do that, with one worked example you can copy, and how to keep the pieces from getting lost.

Why big problems feel impossible to start

A big problem is usually several smaller problems tied together. "Money is tight", "the house is a mess" or "the project is behind" each hide four or five separate things going wrong. When you look at the whole knot, there is no obvious first move, so you put it off.

A smaller problem has a first move. "Nobody decides what to cook until 6 pm" suggests its own fix. You can try that fix on Monday and know by Friday whether it helped.

So the goal of breaking a problem down is not a neat diagram. It is to turn one problem you cannot act on into several you can.

Start by writing the gap

The Lean Enterprise Institute describes problem solving as "identifying and closing gaps between current and target conditions" (Lean Enterprise Institute, Problem Solving). That is a useful way to write your big problem down before you split it.

Write two lines:

• Now: what is actually happening, in one line. "We get takeaway four weeknights out of five."
• Target: what you want instead, in one line. "Home cooked dinner four weeknights out of five."

Two rules make this work. First, write facts you have checked, not a feeling. The same page says every part of the problem should rest on "verifiable facts, not assumptions and interpretations", and suggests asking "How do you know that?" Count the takeaway nights for a week before you write "four out of five". Second, make the target specific. "Eat better" cannot be split. "Four home cooked dinners a week" can.

How to break a big problem into smaller problems, step by step

With the gap written down, split it. Ask one question over and over: what is getting in the way of the target? Each honest answer is a smaller problem.

1. List the blockers. Write every answer as its own one line problem. Do not judge them yet. For the dinner example: nobody decides what to cook until 6 pm, the fridge is empty by Wednesday, recipes take an hour after work, and cooking is one person's job.
2. Merge the overlaps. If two lines describe the same thing, keep the clearer one.
3. Split anything still too big. Apply the size test below. If a piece fails it, ask the same question about that piece and split it again.
4. Stop when every piece passes. You do not need a perfect tree. You need pieces you can act on.

Splitting by blockers is different from digging for a root cause. Breaking down goes wide: it finds the several parts of one problem. The 5 whys goes deep: it follows one part down to its cause. You will often do both, breaking the problem down first, then asking why on the piece that matters most.

Know when a piece is small enough

A piece is small enough when it passes three checks:

• You can name a fix. If you cannot think of a single thing to try, the piece is still too vague. Split it again.
• You can try the fix within a week. Big fixes like "change jobs" are not tests. A small fix gives you an answer fast.
• You will know if it worked. Tie it back to the gap. If the fix works, the "now" line should move toward the target.

"Recipes take an hour after work" passes all three. You can try recipes under 30 minutes, start on Monday, and count the cooked dinners by Friday. "We are bad at cooking" fails the first check, so it needs splitting.

A worked example: weeknight dinners

Here is the whole example as a map. The four smaller problems hang under the big one, and each has the first fix tried and how it went.

Four pieces, four fixes, three outcomes. The failed one is kept on purpose.

Read it from left to right:

• Nobody decides what to cook until 6 pm. Fix: pick four dinners on Sunday. Worked.
• The fridge is empty by Wednesday. Fix: one shop on Sunday, from the list. Worked, and it only works because of the first fix. That link is worth recording.
• Recipes take an hour after work. Fix: only recipes under 30 minutes. Partly. Two nights went well, two still ran long.
• Cooking is one person's job. Fix: "whoever gets home first cooks". Failed. The same person got home first every day.

Look at what the breakdown gave this household. Two pieces are solved in a week. One needs a second fix. One needs a new idea, and they already know the obvious one does not work. None of that was visible when the problem was just "we eat takeaway too much".

Try one piece at a time, then check

Do not try fixes for every piece on the same day. If everything changes at once, you cannot tell which fix did the work.

The plan, do, check, act cycle from the Lean Enterprise Institute fits each piece well: plan the change, do it, check "the results", then act, which means you "standardize and stabilize the change or begin the cycle again, depending on the results" (Lean Enterprise Institute, PDCA). In plain words:

1. Pick the piece that is easiest to test, or the one that blocks others. In the example, planning came first, because shopping depended on it.
2. Write the fix and the day you will check it.
3. On that day, mark the fix as worked, partly or failed.
4. If it worked, keep doing it. If not, try the next idea on the same piece.

The Lean Enterprise Institute's problem solving page adds that problem solving begins, not ends, when you put a plan into action, because each plan is a theory about what will help. Expect to run the cycle more than once.

Keep the pieces linked on one map

The weak point of breaking a problem down on paper is that the pieces drift apart. The list gets lost, the failed fix gets forgotten, and three months later someone suggests "whoever gets home first cooks" again.

Problem Graph is built for keeping pieces together. Here is the dinner example in it:

1. Write the big problem in one line and put it in the personal lane. It lands on the graph as soon as you press Enter.
2. Write each smaller problem as its own line and link it to the big one. Links can cross lanes, so a work problem like "late meetings on Thursdays" can sit under a home problem.
3. Attach each fix as a solution. Mark the ones you are trying, then record worked, partly or failed when you check.
4. Switch to the List view in the app when you want the pieces in a column, and back to the map to see how they connect.

The three steps from Problem Graph's home page.

The home page says a solution that failed stays on the map as a failed solution. For a broken down problem, that matters: the failed fix tells you which piece still needs work. If you also keep a problem solving journal, the map becomes its index.

Everything is private by default. If the household should see the map, mark the big problem as a main node and share it into a private network with an invite code.

Frequently asked questions

How many smaller problems should I end up with?

There is no right number. Stop when every piece passes the size test, and if the list grows long, group the pieces under a few middle sized problems.

What if the smaller problems depend on each other?

Link them and start with the one the others depend on. In the example, planning dinners came before shopping.

Is breaking a problem down the same as finding the root cause?

No. Breaking down finds the several parts of a problem, and root cause analysis follows one part down to why it happens. They work well together.

What if a piece has no fix I can try?

Split it again, or write the question you need answered as its own problem. A piece with no possible fix is usually still too big or too vague.

Get started

Pick the problem you have been putting off. Write the gap in two lines, list what is in the way, and choose one piece to test this week.

Try Problem Graph: it is free, and you can look around the public network without an account. Write one problem down in a line and attach the first thing you will try.