GTD Projects: Stop Losing Track of Multi-Step Work

“Redesign the checkout flow.” It’s been on your list for two weeks. Every time you look at it, your brain does a quick cost-benefit analysis and decides that answering a Slack message is a better use of the next thirty seconds. So the item stays, gathering guilt like dust.

Here’s the thing: you’re not procrastinating. You’re staring at something your brain literally cannot execute, because “redesign the checkout flow” isn’t a task. It’s a project – a collection of tasks pretending to be a single item. And as long as it sits on your list looking like one thing, you’ll keep skipping it.

GTD handles this with a deceptively simple rule: any desired result that can be accomplished within a year and requires more than one action step is a project. For the full methodology and how projects fit into the five-step workflow, see our Getting Things Done Guide. This article zooms in on that one rule and shows you how to apply it practically – especially if you write code for a living.

The GTD Definition of a Project

David Allen’s definition is deliberately broad: a project is any desired result that requires more than one action step and can be accomplished within a year. No milestones, no Gantt charts. If it takes two steps and isn’t a multi-year life goal, it’s a project.

This definition catches things you’d never put on a project tracker:

• “Get a haircut” (find a barber, book an appointment, show up)
• “Fix the flaky CI test” (reproduce the failure, identify the root cause, write the fix, verify in CI)
• “Plan the team offsite” (pick dates, find a venue, send invitations, plan the agenda)

Most people carry 30-100 active projects at any given time. If that number sounds absurd, it’s because you’ve been thinking of projects as big, formal things. GTD projects include everything from “replace the kitchen faucet” to “launch the new API.”

Why This Matters

When you don’t recognize a project as a project, two things happen:

1. It sits on your next-action list pretending to be doable. Your brain resists it because it senses the hidden complexity.
2. You lose track of the outcome. Without a defined project, the individual steps have no home, and the bigger goal drifts.

Recognizing projects is the first step to managing them.

Extracting Projects From Your Task List

The fastest way to find hidden projects is to audit your existing task list. For each item, ask:

• Can I finish this in one sitting, with one action? If yes, it’s a genuine next action.
• Does this require multiple steps across multiple sessions? If yes, it’s a project.

Common Disguises

Projects love to masquerade as tasks. Watch for these patterns:

The tell is verbs like “improve,” “handle,” “work on,” “deal with,” or “figure out.” These are outcome verbs, not action verbs. They describe where you want to end up, not what you’d physically do next.

The Two Things Every GTD Project Needs

Once you’ve identified a project, GTD asks for exactly two things:

1. A Clear Outcome

Write a one-sentence description of what “done” looks like. Be specific enough that you’d recognize it if you saw it.

• Vague: “Improve the API”
• Clear: “API returns paginated responses with cursor-based navigation and updated docs”

The outcome doesn’t need to be perfect. It needs to be clear enough to guide your next actions. You can refine it during your weekly review as your understanding evolves.

2. A Next Action

Every active project must have at least one next action on your action list. This is the rule that makes GTD projects different from wish lists: if there’s no next action, the project is stalled, and you won’t notice until your next weekly review.

The next action should be physical and visible – what Allen calls “the next physical, visible activity that needs to be engaged in, in order to move the current reality toward completion.” Not “work on the API” but “open the Swagger editor and add the cursor parameter to the /users endpoint.”

Organizing Projects in Practice

GTD doesn’t prescribe a specific tool, but it does require that your project list be a single, complete inventory you can review regularly. Here’s what works:

The Project List

This is a plain list of outcomes. No sub-tasks, no details – just the finish lines:

• Ship v2.1 with dark mode
• Migrate database to PostgreSQL 16
• Hire a frontend developer
• Fix the flaky payment integration test
• Plan Q2 team goals

Each item is a promise to yourself. The list answers one question: “What am I committed to completing?”

Project Support Material

Notes, reference docs, design sketches, research links – this is support material. It lives separately from your action lists and project list. In Super Productivity, you can attach notes directly to a project or use the project description field to store context. The key is keeping it accessible but out of your way.

Linking Projects to Next Actions

Every project on your list should have at least one corresponding next action on your context-based action lists. When you complete that action, immediately ask: “What’s the next action for this project?” and add the new one.

This creates a chain reaction: finish an action → define the next action → the project keeps moving. Break the chain, and the project stalls silently.

Projects for Developers: Practical Patterns

Software work naturally generates projects. Here’s how to apply GTD project thinking to common developer scenarios:

Feature Development

Project: “Add user export functionality”

Next actions chain:

1. “Read the export requirements in the product spec” → done
2. “Create ExportService class with empty exportUsers method” → done
3. “Write unit test for CSV generation with three user records” → done
4. “Implement CSV generation in exportUsers” → done
5. “Add API endpoint GET /api/users/export” → current next action

You don’t need to plan all steps upfront. Just keep the chain going by always knowing the next physical action.

Bug Fixes

Project: “Fix payment timeout errors in production”

Next actions chain:

1. “Check Datadog for timeout patterns in the last 7 days” → done
2. “Add retry logic to PaymentGateway.charge() with exponential backoff” → current next action

Some bugs are one-step fixes. Those aren’t projects. But if reproducing the bug, finding the root cause, implementing the fix, and verifying it are all separate sessions – that’s a project.

Tech Debt

Project: “Migrate auth from sessions to JWT”

This is the kind of project that sits on a list for months because it’s big and non-urgent. GTD’s answer: keep it on the project list, give it a next action, and review it weekly. If you keep choosing not to do the next action, that’s a signal to renegotiate the commitment – maybe defer it to a “Someday/Maybe” list.

Sprint Work

If you use Scrum or Kanban, your sprint board already organizes work into something project-like. GTD complements this by ensuring you also track the non-sprint projects: the conference talk you’re preparing, the internal tool you’re building on the side, the migration you need to plan before next quarter.

The Weekly Review: Where Projects Stay Alive

Projects don’t manage themselves. Without regular review, your project list becomes a graveyard of good intentions. The GTD weekly review is where you bring every project back to life:

1. Read each project outcome. Does it still matter? Is the outcome still clear?
2. Check the next action. Does every active project have one? Is it still the right one?
3. Identify stalled projects. If a project hasn’t moved in two weeks, something’s wrong – the next action is unclear, you’re waiting on someone, or the project should be moved to Someday/Maybe.

In Super Productivity, you can use the daily planner to pull in your next actions for the day, and the built-in review features help you scan your project list systematically. The combination of a visible project list and daily action selection keeps things from falling through the cracks.

When to Kill a Project

Not every project deserves to live. During your weekly review, ask:

• Has the outcome changed? Update or redefine it.
• Is this still a commitment? If not, move it to Someday/Maybe or delete it.
• Am I avoiding it? That’s often a signal that the project needs breaking down further, or that the next action isn’t clear.

Deleting a project isn’t failure. It’s honest prioritization.

Common Mistakes

Confusing Projects With Next Actions

The most common mistake: putting “Implement dark mode” on your next action list. When you see it, your brain freezes because it’s too big to start. The fix: create a project called “Implement dark mode” and identify the single next physical action: “Create a theme.ts file with light and dark color tokens.”

Over-Planning Projects

GTD is explicit about this: you don’t need a full plan for most projects. You need an outcome and a next action. Planning happens naturally as you complete actions and define new ones. Over-planning upfront wastes time on steps that might change once you start.

Maintaining Too Many Active Projects

If you have 80 active projects but only work on 15, the other 65 are creating noise. Move stalled projects to Someday/Maybe. You can retrieve them anytime, but they won’t clutter your weekly review.

No Defined Outcome

Without a clear “done,” you’ll either keep working past the finish line or never feel satisfied. “Improve performance” is a treadmill. “Reduce API response time to under 200ms for the /search endpoint” is a finish line.

Setting Up Projects in Super Productivity

Super Productivity supports GTD-style project management through its hierarchical task structure:

1. Create a project for each multi-step outcome. Use the project title as your outcome statement.
2. Add sub-tasks as you identify next actions. You don’t need all of them upfront – just the current next action.
3. Use tags to mark contexts on your next actions (@deep-work, @low-energy, @waiting).
4. Schedule the next action into your daily planner so it shows up when you’re choosing what to work on.
5. Review weekly using the backlog view to scan all projects and ensure each one has a clear next step.

The tool supports the methodology, but the methodology works with any tool – even a notebook. The critical behavior is the same: maintain a project list, ensure every project has a next action, and review weekly.

Next Moves

1. Audit your task list right now. Identify three items that are actually projects in disguise. Create proper project entries for them with clear outcomes and single next actions.

2. Start your project list. Write down every open commitment you can think of – work, personal, side projects. The list will probably be longer than you expect. That’s normal and healthy.

3. Set a weekly review reminder. Block 30 minutes this Friday. During the review, walk through each project: is the outcome clear? Is there a next action? Should this project still be active?

GTD project management isn’t about fancy tools or detailed plans. It’s about recognizing that multi-step work needs a different kind of attention than single actions – and giving it that attention consistently.

Ready to build the complete system? Read our Getting Things Done Guide to understand how projects connect to inboxes, next actions, contexts, and the weekly review.