Breaking down a project
Projects rarely stall because they're hard. They stall because the next action is unclear, so opening the file feels like work and checking your phone doesn't. Decomposition is how you fix that — but only if you decompose into the right things.
Why "write the report" never gets done
A task like "write the report" is not a task. It's a project wearing a task's clothes. When you sit down to do it, you first have to decide what it even means to start — and that decision is the actual work you keep avoiding.
Compare it with "list the three questions the report has to answer." You can do that in ten minutes, on a train, with no preparation. The difference isn't effort, it's clarity about the first move.
A tree structure is a natural fit here, because decomposition is inherently recursive: a goal contains outcomes, outcomes contain deliverables, deliverables contain actions.
Start from outcomes, not activities
The most common mistake is to break a project into things you'll be doing rather than things that will be true when you're done.
| Activity (weak) | Outcome (strong) |
|---|---|
| Research competitors | A one-page summary of how 3 competitors price |
| Work on the API | The endpoint returns real data to the client |
| Talk to users | 5 interviews done, patterns written down |
Outcomes have a finish line. Activities can absorb infinite time, which is why "research competitors" can eat a week and still not be done.
So the first level of your map should be outcomes:
The two-hour rule
Keep splitting a branch until every leaf is something you could finish in about two hours or less.
The number isn't magic, but the threshold does two useful things. First, anything longer usually hides a decision you haven't made — and that hidden decision is what will stall you. Second, a two-hour task fits in a real calendar gap, so it actually gets scheduled.
When a task resists being split, that's diagnostic. "Design the database schema" won't break down cleanly if you don't yet know what the app must store. The real next task is "list the 5 things a user record must contain" — and you've just found the thing that was actually blocking you.
Stop splitting when it stops helping. Decomposing "send the email" into "open laptop, click compose" is procrastination with extra steps. The goal is a clear first move, not a complete simulation of the work.
Find the risky unknown first
Most plans are ordered by what's comfortable: the parts you know how to do come first, and the uncertain part sits at the end where it quietly grows.
Invert that. Go through your map and mark the branch you're least sure about — the thing that, if it turns out badly, changes everything else. Then schedule a small piece of it immediately.
You don't have to solve it. You just need to convert "unknown" into "known" as cheaply as possible: a spike, a test, a phone call, an hour reading the API docs. A plan built on an unexamined assumption is a plan that will be rewritten.
In practice: reorder that branch to the top of the map (⌘/Ctrl + ↑) so it's the first thing you see. Order in the map should reflect order of attack, not the order you happened to think of things.
Turning the map into a week
A map shows structure but not sequence. To get a plan out of it:
- Mark dependencies. For each leaf, ask "can I start this today?" If not, what has to finish first? Note it in the node text — "after schema is fixed".
- Pick this week's outcome. One outcome branch, not five. Everything else gets collapsed so it stops competing for attention.
- Order the leaves in that branch by dependency, risky-first among the ones that are free to start.
- Take the top three into your calendar with actual times. A task without a slot is a wish.
Collapsing is doing real work in step 2. A map with sixty visible nodes creates a low-level anxiety that makes you avoid it. Collapsed to one open branch, it's a to-do list with the rest of the plan safely stored behind it.
Keeping the map alive
A plan written once and never revisited is a document. A plan you update is a tool. Two habits keep it useful:
- When a task turns out bigger than you thought, split it in the map rather than pushing through. The moment you discover the complexity is exactly when you understand it well enough to decompose it properly.
- When you finish something, mark it and look up one level. Ask whether the parent outcome is closer or whether you learned something that changes it. Projects go wrong slowly, and this is where you catch it.
Share the map, not a status update. A read-only link shows the whole shape of the work — what's done, what's next, and what you're unsure about — in less time than it takes to read a paragraph of prose. It also invites better questions, because people can see the parts you'd have left out of a summary.
A worked example
Goal: "Ship a beta by the end of the month." As stated, unstartable. Decomposed:
- Outcome: 20 testers signed up. Leaves: list 40 candidates (1h), draft invite email (45m), send first 10 (30m).
- Outcome: signup flow works end to end. Leaves: fix the email verification bug (2h), test on a real phone (1h), handle the duplicate-account case (unknown — this is the risky one).
- Outcome: feedback loop running. Leaves: add a feedback link in-app (1h), set up a shared doc for notes (20m).
The duplicate-account case has no estimate, which means it's the thing to look at first. An hour spent understanding it on Monday is worth more than three comfortable tasks, because it's the only item that can quietly consume the whole month.
Notice also that the plan is now nine concrete items, most under two hours. None of them require deciding what to do — only doing it. That's the entire point of the exercise.
Break down the thing you've been avoiding
Free, no install. Put the goal in the middle and split it.
Open MindMap →