From strategy to decisions.
Most companies do not fail because of a bad strategy. They fail because the distance between a decision and the people executing it is never bridged. GPDT is the bridge — a four-level execution hierarchy: Goal → Priority → Deliverable → Task. It runs inside a fixed strategic context defined by a single North Star metric.
What GPDT is, and what it is not.
The same definitions you will see anchored to every level below. Read them once. Everything else hangs from this.
What this method does
Connects a company's strategic direction — anchored by a North Star metric — to the work being done on any given day, through a strict, four-level execution hierarchy.
Each level has a purpose, a metric type, and an explicit link to the level above. When applied, every contributor can answer: what am I working on, why does it matter now, and what does my work contribute to.
What this method does not
It does not prescribe a methodology — not Project Management, not Agile, not Scrum. It runs alongside whatever framework you already use.
It does not recommend specific tools. Tools should support the method — not define it.
Four levels. No shortcuts.
A Goal links only to Priorities. A Priority supports at least one Goal. Each level answers a question the level above cannot. The North Star sits above this hierarchy as a permanent strategic anchor — it does not cycle with Goals. Toggle the views to see one chain, then the same structure at scale.
Test the method on your own work.
Walk one chain — from North Star context through Goal, Priority, Deliverable, and Task — using your real work. The Builder opens with a North Star setup step (this is pre-method context, not a GPDT level), then runs the four GPDT levels with diagnostic prompts and flags common failure modes before you ship the chain to your team.
Test the method on your own work.
Start with your North Star (strategy context), then walk the four GPDT levels: Goal → Priority → Deliverable → Task. About 10 minutes. Your entries stay in this browser — nothing is sent or stored on a server.
Name your North Star.
The North Star is not part of GPDT — it is the permanent strategic context the method runs inside. Define it once. Every Goal you set should move the company toward it. If you already know yours, type it in and continue.
- If your business model were working perfectly, what would be moving — and in which direction?
- If you removed this metric, could you still tell whether your business model works?
- Is it a rate or a stock? Totals are not North Stars.
- Is the metric expressed as a rate? (e.g. "NRR growth rate", not "total NRR")
- Does the rationale capture both sides of the value exchange — what you give the customer and what they give back?
What each level is, what it isn't, and how to measure it.
Each level has a defined purpose, metric type, and link to the level above. The most common failure is naming a delivery as a Goal — the deep-dives below show where each level starts and stops.
A Goal defines a change in reality — a measurable shift in the world outside your team. It is not a delivery. It is the outcome that deliveries are intended to cause.
A Goal is not a Priority. Shipping a product, launching a dashboard, or completing a project is not a Goal — it is a Priority.
Metric type
Outcome metric. Lead when measured as a trend (e.g. NPS trending +5 over 4 weeks). Lag when measured as a confirmed result (e.g. churn reduced by 15%).
Elements
| WHAT | What has to change in reality?One measurable outcome — one metric, one threshold. States what will be different in the world, not what the team will deliver. |
| WHY | Why does this matter now?Business context plus the specific consequence of not achieving this outcome. Generic statements ("it supports growth") do not pass. |
| SUCCESS METRIC | How do we confirm it happened?The specific metric (Outcome, Lead or Lag) and the point at which it will be confirmed. |
| GUARDRAIL | What constraint must hold for the Goal to count?A metric that must stay within bounds for the Goal to count as achieved. Prevents hitting the primary number via a shortcut that damages long-term health. Optional — 0 to 3 maximum. |
| WHEN | Until when?The deadline by which the outcome must be confirmed. |
WHAT: Reduce churn by 15% within 6 months.
WHY: Retention drives NRR; NRR is the primary growth lever at our stage.
Owner
Defined by the executive leader. The executive reviews Priorities — they do not define them.
A Priority defines a concrete, scoped delivery whose output causes a Goal's outcome to move. It is not the Goal — it is the mechanism.
Not a Goal (Goals measure what changes in the world). Not a Deliverable (PRDs, code, databases are Deliverables that support a Priority).
Metric type
Output metric. Lag for milestone-based delivery (dashboard launched). Lead for progressive delivery (10 onboarding sessions delivered this week).
Elements
| WHAT | What do we deliver to move the Goal?One scoped output with a definition of done. Something the team builds, launches, or completes. Not what changes in the world — that is the Goal. |
| WHY | Why does this delivery move the Goal?The causal mechanism, stated explicitly. Completable as: "When this output is delivered, [Goal metric] will move because [mechanism]." |
| SUCCESS METRIC | How do we confirm the delivery happened?Output metric (Lag for milestone-based delivery; Lead for progressive delivery). |
| WHEN | Until when do we have to deliver?The delivery deadline. |
| GOAL SUPPORT | Which Goal does this Priority support?The explicit Goal this Priority causes to move. One Priority may support more than one Goal — each link must be documented separately. |
The causal-link test — the most important rule in the method
“When [Priority output] is delivered, [Goal outcome] will move because [mechanism].”
If the sentence cannot be completed, the work is an activity — not a Priority. Activities consume resources but do not move Goals.
Priority: Launch a proactive CS health-score dashboard.
Goal: Reduce churn by 15%.
Causal link: CS teams with better visibility intervene earlier with at-risk accounts → accounts are retained → churn drops.
Owner
Defined by the Priority owner — middle manager, senior, or delivery lead. C-level is accountable; the owner is responsible.
A Deliverable is the concrete, demonstrable output that a Priority is made of. Complete or not — there is no partial completion.
Not a Task. Cleaning data or reviewing existing architecture are Tasks that contribute to a Deliverable.
Metric type
Output, Lag. Confirmed at the point of demonstration, not tracked progressively.
Elements
| WHAT | What specifically gets produced?One demonstrable artifact — not a process, not an activity. Something that will exist and can be shown at completion. |
| WHY | Why is this needed for the Priority?Names the Priority this Deliverable belongs to and explains what gap it fills within that Priority's output. |
| DONE WHEN | How do we know it is complete?A verifiable condition specific enough that someone other than the owner can confirm it without asking for clarification. |
| WHEN | When is this needed?Due date or timeframe within the Priority. |
| OWNER | Who owns this?One named individual. Not a team. Not a function. One person, from definition to demonstration. |
Three rules
| Demonstrable | You can show it. A meeting held is not a Deliverable. A decision documented is. |
| Single owner | One person is responsible. Not a team. Not a function. One person. |
| Belongs to one Priority | If it serves two Priorities, document it explicitly as a dependency — it increases criticality. |
Deliverable: Aligned health-score criteria for CS accounts documented.
Done when: All 50 health-score criteria approved.
Owner: Head of Customer Success.
Owner
Owned by the expert closest to the work. Leadership defines WHAT and WHY; the owner defines HOW.
A Task is the unit of work that produces a Deliverable. Done or not done.
Not a Deliverable. Writing a one-page criteria doc is a Deliverable. Reviewing three reference frameworks to inform it is a Task.
Metric type
Output, Lag. Estimated in hours or minutes — never story points or t-shirt sizes.
Elements
| WHAT | What specifically needs to be done?A single, specific action. Concrete enough to estimate in hours. If you cannot estimate it, the task is still a Deliverable in disguise — break it down. |
| PARENT DELIVERABLE | Which Deliverable does this produce?The single Deliverable this Task belongs to. A Task without a Deliverable is an activity or a scoping error. |
| ESTIMATED EFFORT | How long will this take?Hours or minutes only. Not days. Not story points. Not t-shirt sizes. Time is a universal unit — comparable across teams. |
| DONE WHEN | When is it complete?The specific completion condition. Observable by someone other than the owner. |
| OWNER | Who owns this?One named individual. Same single-owner rule as the Deliverable level. |
Three rules
| Completable in 1–2 days | If longer, it is a Deliverable in disguise. Break it down. |
| Belongs to one Deliverable | Work without a Deliverable is an activity or a scoping error. |
| Single owner | Same rule as the Deliverable level. |
Task: Interview 5 CSMs to identify leading indicators of churn risk.
Estimated effort: 2 hours.
Done when: 5 CSMs interviewed, key indicators identified and ranked.
Owner
Owned by the expert or junior actually doing the work. Estimation is the owner's responsibility.
One owner per level. Always.
The method works only when each level owns its layer. When any level reaches into the one below it, alignment breaks and execution stalls. The most common failure mode at scale: leaders do not define clear Goals, so teams cannot define meaningful Priorities — and leaders then engage at the operational level, believing nothing is getting done. The problem is not execution. It is the absence of direction.
| Level | Owner | Role |
|---|---|---|
| Goal | Executive leader | Define direction. Secure resources. Review Priorities — not define them. |
| Priority | Priority owner — middle manager, senior, delivery lead | Define HOW the Goal gets achieved. Own and drive delivery. |
| Deliverable | Expert | Define WHAT, WHY, HOW, and WHEN at execution level. |
| Task | Expert or junior | Execute the HOW. |
Every metric sits on two axes.
Output vs. outcome. Lead vs. lag. Confusing them is the most common way the hierarchy breaks down in practice.
Map them explicitly. Park what you can't start.
A dependency is any point where one Priority or Deliverable cannot proceed until another is complete. Unmapped dependencies surface only when a deadline passes — by which time they are no longer dependencies, they are problems.
| Prerequisite | Dependent | Shared resource | Risk if blocked |
|---|---|---|---|
| Migrate CRM data | Launch onboarding automation | Engineering capacity | Onboarding Priority blocked |
| Define health-score criteria | Build calculation logic | Backend engineer | Deliverable B cannot start |
When a Deliverable has an unresolved upstream dependency, it moves to Parked rather than active execution. Parked is not delayed work — it is a deliberate decision that protects the team from invisible bottlenecks. A Deliverable moves from Parked to active only when the upstream dependency is confirmed resolved.
One pass/fail check per level.
Run this after the chain is filled in. If anything fails, fix it before the session closes — a correction at review is the method working, not a failure.
Validation questions
- Does it capture the full value exchange — both sides?
- Is it expressed as a rate?
- Does removing it make the business model meaningless?
- Is this an outcome?
- Is there one metric?
- Is the WHY explicitly stated?
- Is the output clearly scoped?
- Can the causal link to the Goal be stated in one sentence?
- Are all four scoping elements defined?
- Is it demonstrable?
- Does it have a single owner?
- If it serves more than one Priority, is it documented as a dependency?
- Is it completable within days?
- Does it have a single owner?
- Does it connect to a Deliverable?
- Has effort been estimated in hours?
- Output or outcome?
- Lead or lag?
Each level has a failure that looks like progress.
The chain feels complete. The meeting ends. Work begins. The problem surfaces weeks later — when it costs more to fix. Catch them in the room, not after the deadline.
Goal · Delivery as Goal
Pattern
The Goal describes a team output, not a change in reality. “Launch the onboarding flow.” “Release v1.0.” These are deliveries — they belong at the Priority level.
Real-time redirect
Ask: what changes in the world outside my team when this is delivered? That answer is the Goal.
Priority · Missing mechanism
Pattern
The Priority is named, the owner is assigned, the date is set — but the causal-link sentence cannot be completed. The team knows what they will deliver. They cannot explain how it moves the Goal.
Real-time redirect
Complete the sentence out loud. If you cannot, pause. Either identify the mechanism or find a different Priority. Do not move to Deliverables until the sentence is complete.
Deliverable · Shared ownership
Pattern
Two names are attached. Both feel necessary. Neither is fully accountable. When it is late, the conversation begins with: I thought they were handling that part.
Real-time redirect
Ask: if this is not complete on time, who is the one person I hold accountable? That person is the owner. If the answer requires two names, the Deliverable has two parts — split it.
Task · The estimate that isn't
Pattern
Tasks are estimated in days, “a few days,” or “shouldn't take long.” When the work begins, it takes three times as long — and no one is surprised.
Real-time redirect
Convert to hours. If you cannot estimate in hours, the task is a Deliverable in disguise. Break it down until each part can be estimated.
The method only works once you apply it.
Open the Builder to walk one chain on your own work, or schedule a conversation to explore running GPDT inside your organization.