Task Breakdown

---
name: task-breakdown
description: Turns a task that feels too big to start into an ordered list of steps you could finish in one sitting each, beginning with a first step small enough to do in the next ten minutes. Use when something has been sitting untouched, when a task is vague enough that step one is unclear, or when a plan keeps stalling.
---

# Task Breakdown

You are the person who makes the first step small enough that starting stops being a decision. Everything else in this skill serves that.

## Diagnose before you break anything down

Tasks stall for different reasons, and the wrong fix does nothing. Ask what is actually in the way before writing any steps.

| Why it is stuck | The signal | What actually helps |
|---|---|---|
| Too big | "I don't know where to start" | Work backwards from done, then cut to one-sitting pieces |
| Too vague | Cannot say what finished looks like | Define done first; that is the real first step |
| Needs a decision | Every path leads back to an unmade choice | Make the decision its own early step |
| Waiting on someone | Real work exists but is blocked | Send the request today; the rest schedules around the reply |
| Dreaded | Known, small, still untouched for weeks | The smallest possible first step, plus naming why it is unpleasant |
| Not actually theirs | Resentment in how it is described | Ask whether the task should be handed off or declined |

Name the diagnosis out loud in one line before the steps. A person who understands why they were stuck starts faster than one handed a list.

## Workflow

1. **Write "done looks like" in one concrete sentence.** If the user cannot say it, defining it is step one and everything else waits.
2. **Ask what is in the way** using the table above.
3. **Work backwards.** What has to be true immediately before it is done? And before that? Backwards produces the real order; forwards produces a wish list.
4. **Cut to one-sitting pieces.** Fifteen to sixty minutes each. Anything longer is still a project and gets broken again.
5. **Order by dependency**, not by importance. Nothing may sit behind a step that comes later.
6. **Separate what they control from what waits on other people**, and put every request to another person as early as possible.
7. **Make the first step tiny.** Under ten minutes, no new information needed, doable right now.
8. **Total it honestly** and say what the number means.

Copy this checklist into your working notes and tick it as you go:

```text
Breakdown checklist
[ ] "Done looks like" written as one concrete sentence
[ ] Diagnosis named: too big / vague / needs a decision / blocked / dreaded / not theirs
[ ] Worked backwards from done, not forwards from now
[ ] Every step is a concrete action starting with a verb
[ ] No step longer than one sitting
[ ] Steps ordered so nothing is blocked by a later step
[ ] Requests to other people scheduled as early as possible
[ ] Decisions written as their own steps
[ ] First step under ten minutes and needs nothing new
[ ] Honest total, with what it implies
```

## The first step

This is the part that matters most, and the part most plans get wrong. Three tests:

- **Under ten minutes.** Long enough to be real, short enough that there is no reason not to.
- **Needs nothing you do not already have.** No login to find, no file to locate, no answer to wait for. If it needs any of those, finding them is the first step.
- **Produces something.** A written line, a sent message, an opened document with a heading in it. "Think about the structure" is not a step; "write three bullet points for the structure" is.

The classic wrong first step is the biggest one. "Write the report" is not a first step, it is the task. "Open a document and write the five section headings" is a first step, and it makes the second one obvious.

## Writing a step

- Start with a verb: draft, send, call, list, book, decide, check.
- One outcome per step. If it contains "and", it is two steps.
- Attach a time estimate, and be honest rather than optimistic.
- Name the thing precisely. "Email Priya to ask for the Q3 numbers" beats "get the numbers".
- If a step still feels heavy, break it again. Two thirty-minute steps beat one ninety-minute step that never gets started.

## Decisions are steps

When a task stalls on an unmade choice, every downstream step is fiction. Pull the decision out and give it its own line, early, with what is needed to make it:

> 2. Decide whether this is a half-day workshop or a full day. (15 min - you need the attendee list and the budget figure, both of which you have.)

If the decision needs someone else, it becomes a request step instead, and it goes first because everything is behind it.

## Output shape

- **Done looks like** - one concrete sentence.
- **Why this has been stuck** - one line, the diagnosis.
- **First step** - the ten-minute one, stated so it could be done immediately.
- **The steps** - numbered, each with a verb and a time estimate.
- **Waiting on others** - the steps that depend on someone else, with what was requested and when.
- **Rough total** - the honest sum, and one line on what it means.

## Example

**Input from the user**

> I have to sort out the new pricing page. It has been on my list for six weeks. Every time I look at it I do something else.

**Done looks like:** the new pricing page is live, with the three tiers, and sales have been told what changed.

**Why this has been stuck:** it is not too big, it is a decision wearing a task's clothes. Every step depends on what the middle tier costs, and that has not been decided. Six weeks of avoidance is what an unmade decision looks like from the outside.

**First step (8 minutes):** open a document and write the three tier names with the two prices you have already settled. Leave the middle one blank. That single blank is the whole project.

**The steps**

1. Write the three tier names and the two settled prices. (8 min)
2. List the three options for the middle tier price, one line each on who it wins and who it loses. (20 min)
3. Send those three options to Ravi and ask him to pick or push back by Thursday. (10 min) - *waiting on Ravi*
4. Write the feature list for each tier while you wait. It does not depend on the price. (45 min)
5. Draft the page copy: headline, three tier cards, and the frequently-asked block. (60 min)
6. Once Ravi replies, fill in the middle price and check the three tiers still read as a sensible ladder. (15 min)
7. Build the page. (90 min - if this is more than one sitting, split it into layout and content)
8. Write the note to sales: what changed, what to say to customers already on the old pricing. (25 min)
9. Publish, then send the sales note the same hour so nobody hears it from a customer first. (10 min)

**Waiting on others:** step 3 goes to Ravi today, and steps 6 onward sit behind it. Sending it today rather than after the copy is written is the difference between waiting two days and waiting a week.

**Rough total:** about four and a half hours of your own work, spread across whatever Ravi's reply does to the schedule. It is one focused day, which is worth knowing after six weeks of it feeling like a month.

Notice that the diagnosis changed the plan. Treated as a big task, this becomes ten steps that all stall at the same place. Treated as an undecided price, the first real move is a ten-minute message to one person.

## Rules

- Every step is a concrete action, not a topic. "Draft the introduction", never "introduction".
- Make the first step tiny. Starting is the expensive part; remove the friction there and the rest follows.
- Order by dependency. A plan that blocks itself gets abandoned at step three.
- Requests to other people go as early as possible, even when they feel out of order.
- If a step needs a decision, the decision is an earlier step.
- Estimate honestly. A plan that only works if everything goes perfectly is not a plan.
- Do not pad. Six real steps beat fourteen that include "gather thoughts".
- If the whole thing is under about half an hour, say so and hand the time back rather than producing a plan.

## Edge cases

- **They cannot say what done looks like.** Stop. Defining it is the task, and everything after it would be guesswork. Ask what someone else would need to see to agree it was finished.
- **It is genuinely a project, not a task.** More than about fifteen steps or two weeks. Break out the first phase only and name the rest as later phases, or the list becomes another thing to avoid.
- **Every step waits on someone.** Then the task is chasing, not doing. Say that plainly, and build the plan around when each request goes out and what happens if it is not answered.
- **They are avoiding it for a reason** - a difficult conversation, a mistake to admit, work they resent. Name it once, without lecturing, and make the first step the smallest possible piece of the unpleasant part rather than a comfortable adjacent task.
- **The task is not really theirs.** If it should be handed off or declined, say so before breaking it down. A well-organised plan for work someone should not be doing is not help.
- **The deadline makes the honest total impossible.** Say so immediately, and give two options: what to cut, or who to ask for more time. Do not compress the estimates to make the arithmetic work.
- **They have already started.** Ask what is done, mark it, and start the numbering from where they actually are. Nobody follows a plan that begins by ignoring three days of their work.
- **The task recurs.** After the breakdown, offer to turn it into a written procedure so the next time is not a fresh problem.

## Files

- `references/examples.md` - three tasks broken down end to end: an event with many small parts, a slow administrative process full of waiting, and a vague work task where the first step turned out to be a decision. Read it to see how the diagnosis changes the shape of the plan.

# Worked breakdowns

Three stuck tasks taken apart. In each one the diagnosis, not the list, is what unsticks it.

## Contents

- [Example 1: many small parts](#example-1-many-small-parts)
- [Example 2: mostly waiting](#example-2-mostly-waiting)
- [Example 3: vague, and hiding a decision](#example-3-vague-and-hiding-a-decision)
- [What the three have in common](#what-the-three-have-in-common)

---

## Example 1: many small parts

### The request

> I have to organise the team offsite and I have no idea where to start. Twelve people, two days, sometime in the autumn. My manager keeps asking how it is going and I keep saying "getting there".

### The breakdown

**Done looks like:** twelve people spend two days at a booked venue in the autumn, with an agenda they received in advance and food arranged.

**Why this has been stuck:** genuinely too big, and everything appears to depend on everything else. It does not. The dependency chain is short - dates, then venue, then everything else - and the rest is parallel work that feels blocked but is not.

**First step (10 minutes):** open the team calendar and write down three candidate date pairs that avoid the obvious clashes. Do not check with anyone yet.

**The steps**

1. Write three candidate date pairs from the calendar. (10 min)
2. Send the three options to the team and ask for hard clashes only, replies by Friday. Say you will pick on Monday. (10 min) - *waiting on the team*
3. Confirm the budget with your manager, including whether it covers travel and dinner. (15 min) - *waiting on your manager*
4. While waiting, list what the two days are actually for. Three outcomes, not a wish list. (30 min)
5. Monday: pick the date. If two options are equally clear, pick the earlier one; venues fill up. (10 min)
6. Shortlist three venues that fit twelve people and the budget. (45 min)
7. Enquire with all three at once, asking for availability, cost per head and whether food is included. (20 min) - *waiting on venues*
8. Book the venue. (30 min)
9. Draft the agenda against the three outcomes from step 4. (60 min)
10. Arrange food, including checking dietary requirements with the team. (30 min)
11. Send the agenda and the practical details at least a fortnight before. (20 min)

**Waiting on others:** three separate waits, and they can all run at once. Steps 2, 3 and 7 are the ones that decide whether this takes two weeks or six. Send each the moment it is possible.

**Rough total:** about four and a half hours of your own work, spread over roughly three weeks because of the waits.

**Why it is shaped this way:** the three requests are pushed as early as the plan allows and are explicitly flagged as parallel. The step most people put first - looking at venues - is sixth, because a venue enquiry without a date wastes both the enquiry and the reply. Step 4 is deliberately placed inside the waiting period, since it depends on nobody.

---

## Example 2: mostly waiting

### The request

> Applying for a business loan. I started three weeks ago, got as far as downloading the form, and have not touched it since. The form wants things I do not have to hand.

### The breakdown

**Done looks like:** the completed application is submitted with every required document attached, and you have the reference number.

**Why this has been stuck:** it is not one task, it is a collection of requests to other people wearing one form as a disguise. Nothing about it is difficult; the form simply cannot be finished in one sitting, so every attempt ends in the same feeling of failure. Once the requests are out, the work is short.

**First step (10 minutes):** open the form and read only the document checklist. Write a two-column list: what you already have, and what you need to ask someone for. Do not fill anything in.

**The steps**

1. Read the checklist and split it into "have" and "need to ask for". (10 min)
2. Email your accountant for the accounts and any tax documents on the list, in one message rather than three. (15 min) - *waiting on your accountant*
3. Request the bank statements for the period the form asks for. (10 min) - *waiting on the bank*
4. Fill in every section that needs no documents: business details, ownership, contact information. (40 min)
5. Write the "what the money is for" section. This is the only part that needs real thought - draft it badly first, then fix it. (60 min)
6. Chase anything not received after five working days. (10 min)
7. Attach the documents as they arrive, ticking them off the checklist. (20 min)
8. Read the whole form once, in order, as if you were the person assessing it. (30 min)
9. Submit, and save the reference number somewhere you will find it again. (10 min)

**Waiting on others:** steps 2 and 3 both go out today. They are the only reason this takes weeks rather than a day, and they have been sitting unsent for three weeks. Sending them is worth more than anything else on the list.

**Rough total:** about three and a half hours of your own work, over one to two weeks depending on how fast the documents arrive.

**Why it is shaped this way:** the first step is deliberately not "start filling in the form". It is a ten-minute sorting task that produces the two requests, because those requests are the bottleneck and everything else can happen while they run. Step 5 is separated out and given permission to be bad first, since it is the only part requiring judgement and therefore the part most likely to stall the whole form again.

---

## Example 3: vague, and hiding a decision

### The request

> "Improve onboarding" is on my objectives for this quarter. I have written it in three different weekly plans and done nothing about it. It is now week six.

### The breakdown

**Done looks like:** cannot be stated yet. That is the finding, not a failure of the request.

**Why this has been stuck:** it is not a task at all. It is a heading. Nobody can start "improve onboarding" because there is no version of it that is finished, so every attempt turns into thinking rather than doing. Six weeks of rewriting it in a plan is the symptom.

**The first step is to make it a task.** That means one decision: which part of onboarding, for whom, and what would count as better.

**Step 0 (25 minutes):** write down the three most plausible interpretations of "improve onboarding", one line each, and what each would look like when finished.

> - **Faster setup:** a new customer is live in two days instead of nine.
> - **Fewer support tickets in week one:** the first-week ticket rate halves.
> - **Better first impression:** the welcome experience is redesigned, measured by whether people complete it.

Now the decision is visible, and it takes ten minutes rather than six weeks.

**Then, assuming "fewer support tickets in week one" is chosen:**

**Done looks like:** the three most common first-week support questions are answered before customers have to ask, and the first-week ticket rate is measured before and after.

**The steps**

1. Pull the last quarter's first-week tickets and count them by topic. (45 min)
2. Write down the top three topics and what proportion of tickets they account for. (20 min)
3. Decide for each one whether the fix is a product change, a document, or a message at the right moment. (30 min)
4. Send the top three to whoever owns the product surface involved, asking whether any are already being worked on. (15 min) - *waiting on them*
5. Write the content for the two you own outright. (90 min, likely two sittings)
6. Put each piece where the customer will actually meet it. A help article nobody is pointed to changes nothing. (45 min)
7. Note the current first-week ticket rate today, with the date. Without this number you cannot show anything worked. (15 min)
8. Set a calendar reminder for six weeks out to re-measure. (5 min)

**Rough total:** about four and a half hours, plus a six-week wait to know whether it worked.

**Why it is shaped this way:** the breakdown refuses to produce a step list for the task as stated, because any list would have been invented. Step 0 converts a heading into a decision, and the decision converts it into work. Step 7 is placed before the change rather than after it, which is the step people skip and then cannot demonstrate any improvement.

---

## What the three have in common

- The diagnosis is stated before any steps, and in every case it changed the plan: parallel waits in the first, unsent requests in the second, an undefined objective in the third.
- Requests to other people are pushed as early as the dependencies allow, and are marked so the user can see what the real timeline is made of.
- The first step is under ten minutes, needs nothing the user does not already have, and produces something visible.
- Work that genuinely does not depend on the waiting is placed inside the waiting period, so the plan does not idle.
- Honest totals are given in hours of the user's own work, separated from calendar time. Those are different numbers, and confusing them is why plans feel like failures.