Most people fix a productivity problem by improving the list. Better app, better tags, better weekly review. The list gets cleaner and the finish rate stays flat, because a list governs what you intend to do and nothing at all governs what you start. The two-task rule governs starting. That is the whole idea, and it is why a work in progress limit outperforms personal productivity systems built on capture alone.
What is the two-task rule, and how does a work in progress limit help personal productivity?
The two-task rule is a work in progress limit for personal productivity: ideas stay unlimited, but only two items per project may be started at once. A third cannot begin until one of the two closes or is formally discarded. The list holds intent; the cap governs starts. That single constraint does the work.
It borrows from manufacturing, where limiting work in progress is old, boring, well-evidenced practice. The novelty is applying it to a single person’s projects, where nobody is watching the queue.
Why do to-do lists fail at the exact point a WIP limit holds?
A to-do list prices adding at zero and starting at zero. Nothing in the system resists a new item, so intake always outruns completion. The pile that results is not a list of tasks — it is a list of half-finished states, each one holding open memory, context, and a small ongoing debt of attention.
- Starting feels like progress. Opening a project produces the same satisfaction as advancing one, without the cost.
- Nothing stalls loudly. An item can sit untouched for months and look identical to an item in flight.
- Priority is re-decided constantly. With twelve things open, every session begins with a re-ranking instead of work.
| Dimension | To-do list alone | Two-task WIP limit |
|---|---|---|
| What it controls | What you intend to do | What you are allowed to start |
| Cost of adding an item | Zero | Zero (ideas stay unlimited) |
| Cost of starting an item | Zero | You must close or discard something first |
| How work ends | Silently, by neglect | Explicitly: closed or discarded, on the record |
| Daily decision load | Re-rank everything | Choose between two |
| Failure mode | Invisible accumulation | Visible queue pressure |
What does the evidence say about limiting work in progress?
Queueing math and attention research point the same direction. Little’s Law (John Little, Operations Research, 1961) relates work in progress, throughput and cycle time; in its familiar rearrangement, average cycle time equals average work in progress divided by throughput. So in a stable system, hold throughput steady and double what is open, and on average everything in the queue takes about twice as long to finish.
- Switching is expensive. The American Psychological Association, summarising Rubinstein, Meyer and Evans (Journal of Experimental Psychology: Human Perception and Performance, 2001), reports that shifting between tasks can cost as much as 40% of someone’s productive time — an estimate extrapolated from controlled switching experiments, not a stopwatch on a working week.
- The last task follows you. Sophie Leroy’s work on “attention residue” (Organizational Behavior and Human Decision Processes, 2009) found that people perform worse on a new task when the previous one was left unfinished.
- Unfinished goals intrude — until you plan them. Masicampo and Baumeister (Journal of Personality and Social Psychology, 2011), building on Zeigarnik’s 1927 finding, showed that unmet goals disrupt attention, and that writing a specific plan to complete them removes much of the disruption.
- Poor project performance is costly at scale too. The Project Management Institute’s Pulse of the Profession research put waste from poor project performance at close to a tenth of every dollar invested in its late-2010s editions; the exact figure moves year to year, so treat it as an order of magnitude, not a constant.
Read together: open work does not sit still and wait. It charges rent.
What changed when I capped my own projects at two?
I left a 26-year career inside one institution and had to rebuild, from nothing, the structure that institution had quietly supplied — deadlines, review, and someone who noticed when a task stalled. On my own, nothing noticed. Everything I started stayed technically alive.
How bad it was only became visible during a backup scan of my own drives, which turned up 41 tasks abandoned mid-flight. Not rejected, not deprioritised — started and dropped. That count is my own, from my own files, and it is the reason the cap exists.
| Finish behaviour | Before the cap | After the cap |
|---|---|---|
| Limit on started items | None | Two per project |
| What accumulated | 41 mid-flight tasks found in one backup scan | Open items bounded at two per project, not open-ended |
| How an item ended | Neglect — no record, no decision | Closed or discarded, with a date |
| Where stalls lived | Scattered across folders and drafts | One open-items ledger, tagged by blocker |
| New ideas | Started immediately | Logged immediately, started later |
An honest caveat: I do not publish a before-and-after finish-rate percentage, because before the cap I was not measuring one — that was the failure. What is countable is the ceiling. Two open items per project means the number of things that can quietly rot is set by how many projects you run, not by how much discipline you have on a given Tuesday.
What exactly do you ask when a new idea arrives and the cap is full?
This is where most WIP limits collapse — a good idea shows up, the cap is full, and the cap loses. So the moment gets a script instead of a judgement call. One question, asked out loud, every time:
“Which of my two open items does this replace — and if the answer is neither, what is the trigger that lets it start?”
Only three answers are permitted:
- It replaces item A or B. The displaced item is written back to the queue as not-started, with one line on where it stopped.
- It replaces neither. The idea is logged in full and given a start trigger — “when the launch closes” — not a vague someday.
- It is not a project. It is a ten-minute task; do it now and stop calling it an idea.
Notice what the question does not do: it never asks whether the idea is good. Good ideas are abundant and cheap. Capacity is the scarce thing, so capacity is what gets rationed.
How do you set up the two-task rule in one sitting?
It took me somewhere around ninety minutes, once; yours will depend on how much is buried. The steps are in the how-to list below, but the shape is simple: find everything already open, admit which of it you will never finish, keep two per project, and give every stalled item a named blocker.
Do the inventory from your file system, not your memory. Memory is a highlight reel; a folder scan sorted by last-modified date is a confession. That is exactly how the 41 came to light.
How do you handle items that stall instead of finish?
Stalled work needs a different treatment from active work, so I keep an open-items ledger as the single source of truth and tag every entry by what it is blocked on: a decision, another person, an external reply, or me. The tag decides the response.
- Blocked on a decision — the cheapest progress available. One line of thinking unblocks it, so these get cleared first, before any real work starts.
- Blocked on a person or an external reply — not mine to push; it needs a nudge and a date, not attention.
- Blocked on me — the only category that counts against the two-task cap.
Then the maintenance rule that makes the whole thing survivable: anything untouched for 30 days is surfaced weekly as a discard candidate, and most candidates get discarded. Abandonment is not failure — unrecorded abandonment is. Deleting a dead item is housekeeping, and it costs nothing but the ego bruise of admitting the idea outlived its moment.
One related habit worth stealing: when you write something down for later, make the index line describe the symptom, not the topic. “Build failed after dependency update” is findable at 11pm; “Notes on tooling” is not. I only learned this because I shipped working software without being able to read code, by writing down every point of failure as it happened — and the notes were only worth anything when they were named the way I would search for them.
How do you know the cap is working?
Two signals, both uncomfortable in a good way. First, you feel queue pressure — a genuinely exciting idea has to wait, and that friction is the system doing its job. Second, things finish. Not more things; the same things, faster, because they are no longer competing for the same attention.
My working formula for anything worth doing is Belief × Thinking × Action, and it is a product, not a sum — a zero anywhere zeroes the result. Unlimited starts attack the middle term. You cannot think clearly about twelve open projects, so belief and action have nothing to multiply into. Cap the starts and the other two terms have somewhere to land.
If you want the cap to survive contact with a normal week, it helps to have the daily side handled somewhere other than willpower — that is the job the VisionDream app does, turning goals into daily habits so the two open items actually get touched. And the longer version of this story — rebuilding structure from nothing after the institution that supplied it was gone — is the book Why Do I Fail While Others Succeed?
Start with the inventory. Whatever number your folders hand back, that is your real to-do list, and it has been running without a limit for years.