Getting Things Done: The Art of Stress-Free Productivity
Allen's book is the source of GTD — a personal productivity system built around a handful of simple disciplines: capture everything, clarify what it is, organise by context, review regularly, do the next action.
Stripped of the mystique that later accreted around it, GTD is a clean protocol for the basic problem of having too much to do and no system for managing it.
For product direction the book is useful not as personal productivity advice but as a clear example of a simple operational protocol that survives contact with reality.
Most teams that have adopted parts of GTD (task lists with contexts, weekly reviews) did it without reading the original.
Reading the original is still worth it.
Central argument
Allen argues that stress and reduced effectiveness come not from having too much to do but from lacking a trusted system to track commitments — the mind wastes energy holding open loops instead of doing work. The solution is a strict protocol: capture every commitment into an external system, clarify each item into a concrete next action, organise by context, and review the whole system weekly. The key thesis is that trusted capture plus defined next actions eliminates the cognitive load that makes people feel overwhelmed, restoring the capacity to focus.
Critique
GTD is designed around the knowledge worker as a largely autonomous individual managing a personal inbox, which means it has almost nothing to say about coordination overhead, dependencies, or the kinds of interruptions that come from being embedded in an organization rather than managing one. For anyone whose work is defined more by negotiation, alignment, and emergent priorities than by processing a discrete task list, the system's discipline of closure can become a liability — optimising the capture and clearance of tasks while leaving unexamined whether those tasks are the right ones to be doing at all.
Why it matters for product
The curator's framing is the right one: GTD matters here less as personal productivity advice and more as a case study in designing a simple operational protocol that holds under real-world conditions — the same design problem faced when building team rituals like discovery cadences, sprint reviews, or backlog triage. The protocol's core insight — that a system only works if people trust it enough to stop holding things in their heads — applies directly to how product teams design shared tracking and decision-making structures: a roadmap or discovery board that isn't reviewed consistently provides no cognitive relief and gets abandoned.