“Fix onboarding” has been on your list for three weeks. Each time you see it, you have to work out what it means before you can do anything. Tomorrow’s list will ask you to make the same decision again.
A useful list preserves a decision. It tells you what you have committed to, what progress looks like, and where to begin. David Allen’s Getting Things Done gives that process a repeatable structure. This is a practical starting point, with examples you can use on your own work.
01 Name the commitment
Start with the thing that has your attention. Write it down somewhere you will revisit. You do not need to solve it while capturing it; a short, recognizable reminder is enough.
When you return to it, decide whether you intend to act. You can discard it, keep it as reference, or save it as a possibility. If you are committing to it, describe the result you want. A result requiring several actions belongs on a project list.
- Captured
- “Onboarding is confusing.”
- Committed outcome
- A new teammate can set up the app and run its tests using the guide.
- Evidence of done
- A teammate completes a clean setup; the guide covers the steps where they got stuck.
Make the boundary explicit. Are you correcting the setup guide, redesigning the product’s first-run experience, or both? A small sentence can hide months of work. Naming the result exposes the decision.
02 Find the next action
Ask what you could physically do to move the outcome forward. Write enough detail that you can recognize the action later without reopening the whole problem.
For the onboarding example: “Follow the setup guide on a clean checkout and record the first failing step.” You know where to start and what to produce. You do not need to predict every fix before beginning.
“Improve performance”
Run the saved checkout load test and identify the slowest request.
“Plan the offsite”
Email the team two possible dates and ask for conflicts by Friday.
“Choose a vendor”
Draft the three requirements a vendor must meet for us to consider it.
Thinking is real work. Give it a question and an output: “Sketch two migration approaches and their failure modes” is actionable. A verb alone does not make an item clear; “handle migration” still leaves the hard decision untouched.
If someone else has the next move, record what you are waiting for and when you will check it. You do not have to invent a follow-up task every day. If a decision is blocked by missing information, gathering that information may be your next action.
03 Give it a place
Separate items that ask different things of you. A project reminds you of an outcome. A next action tells you how to move it. A calendar commitment tells you when something must happen. Mixing them makes every scan of your list harder.
- Projects
- The outcomes you have agreed to deliver, such as “Setup guide verified by a new teammate.”
- Next actions
- Available moves you can choose from. Include the document, person, or tool when it helps you start.
- Waiting for
- The person, expected result, and a sensible check-in date: “Maya — fresh-install notes; check Thursday.”
- Calendar
- Meetings, real deadlines, and work that genuinely belongs on a particular day.
- Someday / maybe
- Possibilities you want to revisit without treating them as current promises.
These can be headings in a notebook. Choose a structure you can maintain. Elaborate tags will not rescue a list full of undefined commitments.
04 Keep it trustworthy
When choosing work, consider what you can do with the place, tools, time, and energy available. Then weigh its importance. A clearly written action can still be the wrong priority; clarity helps you make that judgment.
Set aside a regular review. Empty your capture places, check upcoming dates, and walk through your commitments. Close finished work. Update dependencies. Give each active project an available next action or an explicit waiting state. Renegotiate work that no longer fits.