Problem Solving
Turning one big knot into a sequence of moves you can actually make.
The behaviour, in one line: I take messy problems and break them into clearly defined, solvable steps before diving in.
Pulling harder on a tangled cable tightens the tangle. You find the loop with slack in it, work that one loose, and the rest gets easier. Most hard problems are that shape: not one hard thing, but several ordinary things knotted together.
A problem feels impossible when it is one object. It usually is not one object — it is several ordinary problems tangled together, and the tangle is most of what makes it feel hard. The work is defining what is actually being asked, separating the parts, and finding the one that will come loose first. This matters more now, not less, because the pieces are what a machine can help with. Once a problem is split into well-defined parts, most of them can be handed off. The definition and the split are the part that cannot, and they are the part most people skip.
| What it is | What it isn’t |
|---|---|
| One exact question | A general sense of the problem |
| Pieces solvable on their own | One object you must solve whole |
| A concrete example to reason on | Reasoning in the abstract |
| Redrawing it when you stall | Pushing harder on the same view |
What it looks like. Two hours in and getting nowhere, you stop and write the problem on one line. The line is wrong. The fourth version is right, and it turns out to be three separate problems, two of which you already know how to do.
- The problem nobody can describe. If three people give three different accounts of what is wrong, no amount of solving helps until that is settled.
- Estimating and scoping. You cannot size what you have not decomposed. Most bad estimates are undecomposed ones.
- Working with a model. A vague prompt gets a vague answer, confidently. Defining the problem is the same step it always was, and now it has a second use.
- Write the problem as a single question, and keep rewriting it until it is exact. A vague question cannot be answered by anything.
- Break it into pieces you could hand to different people and still get usable answers back.
- Make it concrete — an example, a sketch, a version with smaller numbers. Abstract problems resist thinking; concrete ones do not.
- When you stall, change how it is drawn. Invert it, shrink it, or solve a smaller cousin first. Stalling is usually the representation rather than the problem.
- Break it into parts
Four parts: defining the real question, decomposing into independently solvable pieces, making it concrete, and changing representation when stuck.
- The part that carries it
Defining the problem before solving it. An hour spent here returns more than any amount of clever solving downstream.
- The order to learn it in
- Write the problem as one question, and rewrite it until it is exact.
- Decompose it into pieces you could hand to different people and still get an answer.
- Then build the habit of switching representation — draw it, shrink it, invert it — the moment you stall.
- Put something at stake
On your next messy problem, send someone your one-sentence problem statement before you start solving, and let them push back on it.
- Compress it
A clear question, cut into independent pieces, made concrete, and redrawn whenever you stall.
- The smallest useful dose
One problem a week that you refuse to touch until it is written as a single question.
- Anchor it to something you know
Untangling a headphone cable. You do not pull harder. You find the one loop with slack in it and work that loose first.
“A problem well stated is a problem half solved.”
— Charles Kettering
The interactive version is in the course. The diagram, the simulation and the four-question check for Problem Solving run in the free course, where your progress across all 24 skills is kept.
Open Problem Solving in the course →
Not sure where you stand? Take the twelve-minute self-assessment, or see the 30-day course that turns these skills into a roadmap.