A big problem rarely stalls because you lack effort. It stalls because nothing in it is small enough to start on. If you want to know how to break a big problem into smaller problems, the method is plain. Write the whole thing down in one line. Split it into pieces you could act on this week. Put the pieces in order. Then record what you tried on each one and what happened. Paper works for this. So does a journal of problems and the solutions tried on them, drawn as a graph that can stay private, go to people you choose or go public. The splitting and the record matter more than the tool.
Why a Big Problem Stalls Until It Is Broken into Smaller Problems
Take a sentence such as "money is always tight." It is true, and it gives you nothing to do. Any single action feels too small to matter, so you take none. Your mind keeps returning to the whole problem, and the whole problem has no handle.
This is an old observation. The second rule in Descartes' Discourse on the Method is to divide each difficulty into as many parts as possible and as needed to resolve it. George Pólya's How to Solve It lists two related questions: can you find a subproblem whose solution will help you solve your problem, and can you decompose the problem and recombine its elements in a new way? The advice points the same way in both. A part you can solve is more useful than a whole you can only worry about.
Writing the Big Problem Down Before Breaking It Apart
You can only split what you can see. Before you break anything apart, write the big problem in one sentence. Make it describe the situation, not a fix.
Here is a worked example that runs through every step that follows. A self-employed designer writes: "My income does not cover monthly costs, even in months with plenty of work." That line is specific. It says the problem persists in good months, which rules out "find more clients" as the whole answer. A weaker version, "I need more money," already contains a solution and hides the real shape of the trouble.
If the sentence is hard to write, that is useful information. A guide on how to write a problem statement for a personal problem goes through this step in more depth.
How to Break a Big Problem into Smaller Problems by Cause, Part and Step
There are three common ways to split a problem. Each one shows something the others miss, so it helps to try all three on the same sentence.
Split by cause
Ask why the problem happens, then ask why again. The five whys technique repeats the question to trace cause and effect back to a root cause, something you can change. For the designer: income is short in good months. Why? Clients settle their bills weeks after the work is done. Why? Invoices go out late and nobody chases them. That gives a smaller problem: "Invoices are settled late." For a fuller method, see how to do a root cause analysis on a personal problem.
Split by part
List the parts the problem is made of. Project managers do this with a work breakdown structure, which splits a big deliverable into smaller pieces until each one can be assigned and finished. For money, the parts are money in, money out and money set aside. The designer finds a piece hiding in "money set aside": a quarterly tax bill arrives with nothing saved for it.
Split by step
Trace the sequence from start to finish and look for where it breaks. Quote, agree, do the work, invoice, collect the money. The designer sees that quotes are often given without a written scope, so projects grow and the fee does not. Another smaller problem appears: "Projects grow past the quoted fee."
After all three passes, the designer has a short list:
- Invoices are settled late.
- Nothing is saved for the quarterly tax bill.
- Projects grow past the quoted fee.
- Two software accounts renew every month and go unused.
None of these is "money is always tight." Each one has an obvious first move.
Checking Whether Each Smaller Problem Is Small Enough to Act On
A piece is small enough when it passes a few plain checks. Go over each one on your list:
- Can you name a next action? If you cannot say what you would do tomorrow morning, split it again.
- Can you tell whether a fix worked? "Invoices are settled late" can be checked against dates. "Money stress" cannot.
- Is it mostly in your hands? If the piece depends entirely on someone else changing, look for the part you control.
- Could you try a solution within a few weeks? If the first attempt would take months, the piece is still big.
Be careful with time. People reliably underestimate how long tasks take, a pattern known as the planning fallacy. The bias holds even when you know similar tasks ran late before. If a piece looks like one afternoon of work, plan for more, and split it again if the longer estimate no longer fits a few weeks.
Ordering the Smaller Problems So the First Step Is Clear
A list of six pieces can stall you as badly as one big problem. Order removes the choice. Three questions settle most of it.
First, does one piece block another? If you cannot save for tax until cash arrives on time, late invoices come first. Second, which piece is cheapest to try? Cancelling two unused software accounts takes ten minutes and gives a small, real result. Third, which piece relieves the most pressure? For the designer, money arriving sooner eases everything else.
The designer's order: cancel the unused accounts today, fix late invoices this month, write scopes into every new quote, then start a tax savings habit once cash is steadier. The first step is now obvious, and it is small.
Recording What Was Tried on Each Smaller Problem
Once the pieces exist, the record is what keeps you from repeating yourself. In Problem Graph, each smaller problem goes down in one line. Each solution is added as an idea, marked when you start trying it, and later given an outcome: worked, partly or failed.
For "late invoices," the designer might attach three ideas: automatic reminders, a deposit upfront and late fees. The journal's home page uses the same case as its example: a main node "Late invoices" with those three solutions, and automatic reminders marked as settling invoices 9 days sooner. A solution that failed stays on the map as a failed solution. That matters. A failed attempt tells you something about the problem, and a record without failures invites you to try the same thing twice. More on keeping that record well is in how to track what you tried to solve a problem.
Smaller problems that belong together can be linked on the graph, even across its four lanes: personal, work, expert and scientific. If "projects grow past the quoted fee" sits in work and "I avoid hard conversations" sits in personal, a link between them shows a pattern a list would hide. The reasoning behind that is in how to link related problems to find a pattern. Everything is private by default, so a messy first breakdown is seen by no one but you.
Learning from How Other People Broke Down the Same Big Problem
Other people have already split problems close to yours. Their breakdown can show you a piece you missed. The designer might never have thought of "no written scope" without seeing that another self-employed designer listed it.
The same journal shows similar problems that other people chose to share, along with which of their solutions worked. You can borrow one into your own graph, and it keeps a link back to where it came from. An AI also proposes new solutions grounded in what worked for others on similar problems. The public network can be browsed with no account, on a phone.
Read borrowed solutions for what they are: a record of what happened for someone else, under their conditions. A deposit upfront that worked for one person may fail for a client base that refuses deposits. Borrow the idea, mark it as being tried, and let your own outcome decide.
Breaking a Stuck Smaller Problem Down Again
Sometimes a piece you were sure was small refuses to move. You try two or three ideas and each one ends in "partly" or "failed." That is usually a sign of one of two things.
The piece may still be too big. "Late invoices" can split into "invoices go out late" and "clients settle late after receiving them." These need different fixes. Reminders do nothing if the invoice was sent three weeks after the work ended.
Or the cause may be wrong. If every fix for late payment fails, ask why again. Perhaps one large client accounts for most of the delay, and the real smaller problem is "one client sets the pace of my cash." Breaking a problem down is not done once. You split, try, record, and split again where the record shows you are stuck.
Frequently asked questions
How small should a smaller problem be?
Small enough that you can name the next action and try a solution within a few weeks. You should also be able to tell afterward whether it worked.
What is the difference between splitting by cause and splitting by part?
Splitting by cause asks why the problem happens and follows the chain back. Splitting by part lists what the problem is made of, such as money in, money out and money set aside. Using both often reveals pieces that one method alone would miss.
How many smaller problems should one big problem have?
There is no fixed number. If the list is so long that choosing a first step feels hard, group related pieces or put them in order and work only on the first two or three.
What if several smaller problems keep pointing to the same cause?
That shared cause may be the real problem. Write it down as its own problem and link the smaller ones to it, so the pattern stays visible while you work on it.
Problem Graph
Every problem you carry, on one map. Solved together. Visit problemgraph.vlvd.net
