Goals
A Goal is a 1–2 year direction you want to move toward. It lives independently — not inside an Area, not inside a Project.
What a Goal is
A Goal answers the question: what do you want to have achieved in the next year or two?
Goals are not tasks. They don't surface Actions in Today. They don't contain Flows. They exist separately, reviewed quarterly, and their purpose is to inform which Projects you activate.
Examples of Goals:
- "Make the transition to senior engineer by end of 2026"
- "Build a financially sustainable side income"
- "Run a half marathon"
- "Ship the first public version of my app"
How Goals differ from Projects
This is the most important distinction in OTD.
| Goal | Project | |
|---|---|---|
| Timeframe | 1–2 years | Weeks to months |
| Nature | Direction | Active work |
| Contains | Nothing (structurally) | Multiple Flows |
| Review | Quarterly | Weekly |
| Action source | No | Yes (via Flows) |
A Goal like "make the transition to senior engineer" doesn't directly generate Actions. But it informs which Projects you activate: "Build portfolio," "Get AWS certification," "Lead a major initiative at work." Those Projects contain the Flows and Actions that do the actual work.
The Goal is the why behind the Project. The Project is the how.
Goals are independent
Goals don't belong to a specific Area. A Goal can draw on multiple Areas at once.
"Build a financially sustainable side income" involves:
- Area: Side Projects (building the product)
- Area: Finance (understanding the numbers)
- Area: Career (positioning and networking)
This is why Goals aren't attached to Areas. They're a separate layer that cuts across the structure.
That said, most Goals do have a primary Area. It's fine to think of them that way mentally — just don't let that prevent Goals that span areas.
How many Goals
Aim for 3–7 active Goals. More than that and you'll have more active Projects than you can realistically advance. Fewer than 3 and you're probably not thinking far enough ahead.
If a Goal is no longer relevant — circumstances changed, priorities shifted — move it to Someday or delete it. Goals age. Review them.
Writing good Goals
A good Goal is:
- Specific enough to judge — "Be healthier" is not a Goal. "Run a half marathon by May" is.
- Achievable in 1–2 years — If it takes a decade, it's a Vision. If it takes a month, it's probably just a Project.
- Outcome, not activity — "Work on my app" is activity. "Ship the first public version" is an outcome.
You don't need elaborate SMART formatting. A clear sentence is enough.
Goals in Review
Goals are reviewed at two cadences.
Weekly Review — a brief check: Look at your active Goals. For each one: are there Projects currently advancing toward it? Is anything blocked or missing?
This doesn't need to be deep. Two minutes scanning the list: "Goal 1 — yes, Portfolio project is moving. Goal 2 — nothing active yet, should I start something?"
Quarterly Review — a proper audit:
- Review each Goal: is it still relevant? Update or retire as needed.
- For each Goal, map which Projects are currently serving it.
- Are there Goals with no active Projects? Activate one.
- Are there Projects that don't serve any Goal? Consider moving to Someday.
- Add any new Goals that have emerged.
The Goal ↔ Project mapping is always done in Review — never as a fixed structural connection. Projects come and go; Goals are more stable. Keeping the connection dynamic rather than structural makes the system easier to maintain.
Goals vs. Vision and Purpose
| Goal | Vision | Purpose | |
|---|---|---|---|
| Timeframe | 1–2 years | 3–5 years | Indefinite |
| Review | Quarterly | Annual | Annual or less |
| Connects to | Projects | Goals | Goals / Areas |
Vision and Purpose are not Goals. They're a longer-range backdrop that informs whether your Goals are pointing in the right direction. They live in Reference and are reviewed annually.
The cascade: Purpose informs Vision, Vision informs Goals, Goals inform Projects, Projects contain Flows, Flows surface Actions in Today.