The framework
State-Based Productivity
A task should be organised according to its real-world state, not merely whether it is done or unfinished.
Consider a simple task on a traditional to-do list. A phone call to a client. The client does not answer, and the caller leaves a voicemail.
The task is not done. But it is not something that can be acted on either. On most to-do lists it remains unticked alongside everything else unfinished, quietly implying failure each time the list is reviewed.
State-Based Productivity is a task-management framework built on a single principle:
A task should be organised according to its real-world state, not merely whether it is done or unfinished.
State-Based Productivity has its origins in watchmaking. A watch restoration is rarely simply done or not done: it may be awaiting a component, held until the client approves the work, paused mid-operation, or ready for the bench today. David Margolis, a professional watch restorer, built the first version as a FileMaker database in 2004, and it became Nyblit over the following twenty years.
Dispositions: where a task belongs now
Every task has a disposition: the broad condition that determines where it belongs.
- Today: A task that can be actioned now and is intended to receive attention today.
- Blocked: A task that cannot progress because it depends on an external person, event, item or decision.
- Later: A task intentionally postponed by the user until a future time.
- Done: A task that has been closed, whether completed, cancelled, permanently delegated or no longer required.
There is also Not Started, which sits outside this scheme by design. Each of the four dispositions above records a decision the user has taken about a task. Not Started records the absence of one: the task has been captured, but no decision has yet been made about when or whether it will be actioned. In practice it functions as an inbox.
Blocked and Later
The distinction that does the most work is between Blocked and Later.
A blocked task is delayed by something outside the user’s control. A car repair awaiting a replacement part, or a proposal awaiting a client’s approval, is blocked.
A later task is delayed by choice. A task scheduled to begin tomorrow, next week or next year is later.
Both are removed from Today. The difference is agency: am I waiting on the world, or have I chosen to wait?
That difference matters because it determines what happens next. Blocked tasks require chasing. Later tasks require only that they return at the right time.
Keeping Today actionable
Today is designed to contain only work that can genuinely be actioned.
A blocked task retains the reason it is blocked, so that on review the user knows precisely who or what is being waited on. A later task can be given a start time, from ten minutes away to next year, and returns to Today automatically when that time arrives.
The result is three separate lists rather than one undifferentiated one:
- work that needs attention now
- work that needs chasing
- work that is safely scheduled to return at the appropriate time
Workflows: laying the track
A workflow describes the repeatable process behind a type of task. A task may be assigned a workflow such as Phone Call, Purchase or Car Repair.
A train on tracks does not choose a route at every junction. The route is laid in advance, so the only live question is how far along it has travelled. Workflows serve the same purpose. The process is decided once, and thereafter the user is never deciding the process again, only recording a position within it.
Each workflow contains statuses. A status describes the task’s precise condition and determines which disposition it belongs in.
A Phone Call workflow might look like this:
| Disposition | Example statuses |
|---|---|
| Today | Prepare for call; Make call; Record notes |
| Blocked | Left voicemail; Awaiting information |
| Later | Try again later; Call at scheduled time |
| Done | Called; Call cancelled |
Returning to the voicemail. The user selects Left voicemail, and the task moves itself to Blocked, because the next action now belongs to somebody else.
Nothing has been lost. The task has left Today, it is recorded as waiting, and the reason is attached to it.
Progressive States
Statuses within Today can also act as Progressive States: ordered steps that carry a task towards completion.
A phone call might progress through prepare for call, then make call, then record notes. Each step can carry an optional time estimate.
If the task becomes blocked or needs postponing at any point, it moves to Blocked or Later with its progress preserved. A single task therefore holds both its overall purpose and its exact position in a process.
An alternative to Kanban
Kanban systems generally give each process its own board. State-Based Productivity does the opposite. It applies a workflow to an individual task, and keeps every task in the same shared set of dispositions.
With Kanban, a task is added to a workflow. With State-Based Productivity, a workflow is applied to a task.
A phone call, an online order and a car repair therefore appear together in the same Today view, even though each is following a different process.
Where a single-process view is wanted, filtering provides it. Nyblit can restrict the view to one workflow, showing every car repair currently in progress and the status of each. The focused view remains available; it is simply not the default.
The underlying difference is one of framing. Kanban makes the shape of a single process the permanent frame, and a task’s position within that process is the primary fact about it. State-Based Productivity makes actionability the frame, and treats the per-process view as one filter among several.
Designed with ADHD in mind
ADHD can make it harder to sustain attention, manage time, organise information, prioritise tasks, and follow work through to completion. A long, undifferentiated to-do list works against all of these. It presents every unfinished item as equally urgent, even when most of them cannot be actioned today.
This can lead to avoidance, and the avoidance is often misread. A task may remain untouched not because it has been ignored, but because it is waiting on somebody else, is intended for a future date, or is too vague to begin.
State-Based Productivity was developed in part from David Margolis’s experience of ADHD and dyslexia. It addresses these problems in three ways.
It separates what can be done from what cannot. Today contains only genuinely actionable work. In place of a mixed list of obligations, reminders, waiting items and future plans, the user sees the next available action.
It makes vague tasks concrete. “Call the client” becomes prepare, call, record. Each completed step registers as visible progress rather than an unchanged tick box.
It treats a delay as an outcome. When a task stalls, it does not remain frozen and unticked. It moves, with a reason attached, and Today becomes shorter. Filing a stalled task correctly is an action taken, not a failure recorded.
That last point is the hypothesis behind the framework:
For some people with ADHD, a system that shows only immediately actionable work, and that treats the re-filing of a stalled task as a completed action rather than an unfinished one, may make it easier to begin work, to sustain momentum, and to experience progress as rewarding.
This has not yet been formally studied. Nyblit invites researchers, clinicians and people with lived experience of ADHD to examine whether State-Based Productivity makes a measurable difference to perceived task clarity, task initiation, follow-through, or the sense of reward that comes from completing work.
Enquiries: david.margolis@mac.com