---
name: 01-inbound-triage
description: Run on the weekly inbound pile. Trigger - "run 01" plus the raw list of requests. Clusters them, runs the twenty test, drafts the declines unsent, surfaces at most two worth a real look.
---

# TASK 01 — INBOUND TRIAGE AND THE NO

## INPUT
The week's inbound, pasted raw and unsorted. Podcast
pitches, sponsor enquiries, guest post offers,
speaking, advisory-for-equity, intro requests,
partnership decks, people asking me to share things.
Roughly two hundred a week. About 99.9% get declined.

## PROCESS
1. Cluster before reading closely. Most of the pile is
   five or six shapes of request wearing different
   logos. Name each shape and count it.
2. Run the TWENTY TEST on the cluster, not the email.
   If I said yes to this one, how many
   indistinguishable versions arrive next month, and
   would I say yes to all of them. If not, the whole
   cluster declines on a template.
3. Auto-decline anything that puts me in a room.
   Travel, in-person recording, stage time, studio
   production. The only exception is the Summit.
4. Auto-decline anything that needs me before 3pm,
   whatever its merit, unless I have written down an
   exception for that person.
5. Promote at most two to LOOK CLOSER. The bar is not
   that it is good. The bar is that it teaches my
   readers something nobody else can teach them, and
   the person did the thing rather than advised on it.
6. Pull out the RELATIONSHIP cases and stop. Requests
   from people who helped me early, past guests, people
   I owe. These are not merit decisions, the twenty
   test does not apply, and I decide them myself.
7. Draft one decline per cluster. Personalise the first
   line only. Give no reason that opens a negotiation.

## OUTPUT
CLUSTERS with counts / DECLINE ALL with the template
per cluster / LOOK CLOSER, two maximum, each with the
one question to ask before I decide / RELATIONSHIP,
for me, undecided / WATCH LIST / NOT SENT confirmation.

## RULES
- Never accept on my behalf, and never send a decline
  before I have read it.
- No decline explains itself past one sentence. A
  reason is an invitation to argue.
- Never tell anyone I am too busy. I am not too busy, I
  am declining.
- Never promote a pitch because the company is famous.
  Fame is not a reason and I will notice.
- No declined sender's name appears anywhere outside
  this sheet.

## EDGE CASES
- The pitch is genuinely good and the sender also wants
  to sponsor. Sponsorship and editorial never ride in
  the same decision. Split the reply, route the sponsor
  ask to the normal process, and decide the editorial
  ask without it, so nobody thinks the two were traded.
- A cluster of one, with no precedent, so the twenty
  test cannot run. Do not default to no. Say the test
  does not apply and give me one line for and one line
  against.

## GOOD LOOKS LIKE
"DECLINE ALL (58): 'we just raised our Series B and
would love to share the story.' A raise is not
something a PM can use on Monday, and fifty-eight more
land next month. Template B. // LOOK CLOSER (1): she
ran pricing end to end at two companies and has the
numbers on both sides. Ask her one thing first: do the
numbers go on the record. If no, it's a nice
conversation and it's a no."

---
name: 02-pick-the-next-post
description: Run when I need to choose what to write. Trigger - "run 02" plus the Coda topic list and what has shipped recently. Picks the next two or three and names what to delete from the list.
---

# TASK 02 — PICK THE NEXT POST

## INPUT
My Coda list of about fifty topics I want to write
about, what I have published in the last eight weeks,
what keeps coming up in the Slack community and my
inbox, and what the last three posts actually did.

## PROCESS
1. Check every candidate against my own archive and
   podcast transcripts first. I have often already
   answered it, or a guest answered it on tape and I
   forgot. Say which, with the link.
2. Score each one on four things and show the scores.
   Can I get named operators who did it. Is there a
   number or a document nobody has published. Would a
   PM change something on Monday because of it. Do I
   have a real opinion, or would I be pontificating.
3. Kill anything that only scores on interest. Being
   interesting is not the bar.
4. Split the survivors by cost. Ten to fifteen hour
   posts and hundred-hour guides are different
   decisions and must not be compared to each other.
5. Give me the next two or three in order, with the
   first sentence of the argument for each, so I can
   tell whether I believe it before I commit the hours.
6. Name three topics to delete from the list
   permanently, with the reason. The list only stays
   useful if it shrinks as often as it grows.

## OUTPUT
ALREADY ANSWERED, with links / SCORED SHORTLIST /
NEXT 2-3, in order, with the one-line argument /
DELETE THESE THREE / one line on what the list is
currently over-weighted toward.

## RULES
- Never propose a topic where I cannot name at least
  three operators who would talk to me.
- Never argue for a topic on trend or traffic grounds.
- Do not propose a hundred-hour guide in a week I have
  a recording backlog. Say when the calendar says no.
- No topic goes on the list without a deletion.

## EDGE CASES
- Everything scores the same because the whole list
  lives in one zone. Break the tie on a different
  question: which of these will I still care about at
  hour forty. The other scores do not survive hour
  forty and that one does.
- A topic is hot right now and the archive says I
  covered it eighteen months ago. An update is only
  worth it if the answer changed. Name the specific
  thing that changed, with a date, or kill it.

## GOOD LOOKS LIKE
"NEXT: 'what actually happens to a roadmap when
engineering triples its output.' Argument in one line:
everyone is writing about the eng speedup and nobody
has asked the six PMs living downstream of it what
broke. DELETE: 'the future of product management.' It
has been on the list fourteen months, there is no
operator to call, and it is the exact shape of thing
that sounds true and isn't."

---
name: 03-deep-research-pass
description: Run before a big essay or a definitive guide. Trigger - "run 03" plus the topic and the question. Produces a source pack, never prose.
---

# TASK 03 — DEEP RESEARCH PASS

## INPUT
The topic, the question I think I am answering, and any
sources I already have. Assume this is a post that will
cost me ten to fifteen hours, or more than a hundred if
it is a guide.

## PROCESS
1. Sharpen the question until it has one answer and a
   wrong answer. If the question can be answered
   "it depends", it is not ready and the research is
   wasted.
2. Search my own archive and podcast transcripts before
   anything external. Quote what I or a guest already
   said, with the date. Half the work is usually done.
3. Build the operator list: eight to twelve people who
   personally did the thing, not consultants, not
   people who wrote a post about it. For each, one line
   on what only they can tell me and how to reach them.
4. Write the interview guide, five questions per
   person, each one specific to that person.
5. Collect the numbers. Every one gets a source, a date
   and the method behind it. A number with no method is
   a rumour and gets marked as one.
6. Build the ARGUMENT AGAINST. Find the strongest case
   that my thesis is wrong and the person who would
   make it. If you cannot find one, the thesis is too
   safe to be worth a hundred hours.
7. Flag every claim in the pack that sounds true and is
   not sourced. That list goes at the top.

## OUTPUT
THE QUESTION, sharpened / WHAT I ALREADY SAID, with
links / OPERATOR LIST with the ask for each / INTERVIEW
GUIDE / NUMBERS with sources and dates / ARGUMENT
AGAINST / SOUNDS TRUE, UNSOURCED. No draft prose.

## RULES
- Do not write the post. Not the intro, not an outline
  in my voice, not "a rough version to react to".
- No framework without an operator who ran it.
- No number without a link, a date and a method.
- Never smooth a disagreement between two sources. The
  disagreement is usually the post.

## EDGE CASES
- Every source agrees. That means the question is too
  easy. Go find the case where the same approach
  failed, and the person it failed for. If nobody
  failed at it, there is no post.
- The best source will only talk off the record. Get
  them to approve a de-identified version in writing,
  or drop them entirely. Never launder an off-record
  quote into anonymous authority, because that is
  exactly the thing that sounds true and cannot be
  checked.

## GOOD LOOKS LIKE
"ARGUMENT AGAINST: three of the twelve say this only
worked because they had a founder who would overrule
the data, which means the framework is downstream of
a person, not a process. [NAME] will say that on the
record. That objection is stronger than the thesis and
it should open the post, not sit in a caveat near the
end."

---
name: 04-podcast-guest-and-prep
description: Run when choosing a guest or preparing for a confirmed one. Trigger - "run 04" plus the shortlist or the guest plus everything they have published. Virtual recording only.
---

# TASK 04 — PODCAST GUEST AND PREP

## INPUT
Either a shortlist of possible guests, or one confirmed
guest and everything they have said in public. Research
runs two to ten hours depending on how much of that
there is.

## PROCESS
1. Do the circuit check first. List every other podcast
   and long interview this guest has done in the last
   two years and the questions they were asked. Those
   questions are now banned. Show me the banned list so
   I can see the hole in the middle of it.
2. Find the thing they have not been asked. Usually it
   is the decision that went badly, the year before the
   thing they are famous for, or the number they have
   mentioned once and never explained.
3. Draft questions in three different interviewer
   registers, then throw away the register and keep
   only the questions that survive being asked plainly.
4. Cut every question longer than its likely answer. I
   would rather hear the guest talk than hear me.
5. Write the pre-interview note: three questions sent
   to the guest ahead of time to surface what they are
   actually excited to say. Their answers reshape the
   list, they do not just confirm it.
6. Name the ONE story I want in this episode and the
   exact question that opens it. If I get nothing else,
   I get that.
7. Logistics: virtual only, no travel, no studio. Check
   their time zone against the 3pm rule and flag any
   conflict before the invite goes out.

## OUTPUT
BANNED QUESTIONS, with sources / THE UNASKED THING /
QUESTION LIST in order, cut to size / PRE-INTERVIEW
NOTE to send / THE ONE STORY and its opener / TIME ZONE
AND 3PM CHECK.

## RULES
- Never propose a question this guest has already
  answered on another show.
- Never book a guest for reach alone. Audience size is
  not a reason and I will notice.
- No in-person recording, ever, including "we'll be in
  town anyway".
- No question that requires the guest to praise
  themselves to answer it.

## EDGE CASES
- The guest is a superb operator and a poor talker.
  Framework questions will kill the episode. Open with
  a specific scene instead, a day, a room, a decision,
  and let the framework come out sideways.
- The guest is a friend or a repeat. The risk is an
  hour of pleasant agreement. Write the one
  uncomfortable question, put it at minute twenty, and
  tell me to ask it anyway.

## GOOD LOOKS LIKE
"BANNED: the founding story (asked on four shows), the
pivot (three), 'what would you tell your younger self'
(all of them). // THE UNASKED THING: she has said twice
that they shipped the wrong thing for eleven months and
nobody has asked what the team was told during those
eleven months. Open there. That is the episode."

---
name: 05-guest-post-edit
description: Run on a guest post draft. Trigger - "run 05" plus the draft. Fixes the argument and the evidence without sanding off the author's voice. Iteration runs over weeks, not one pass.
---

# TASK 05 — GUEST POST EDIT

## INPUT
A guest post draft, plus which round of edits this is.
These take months and several rounds. Treat each round
as one round, not a rewrite.

## PROCESS
1. First read: find the ONE claim. Write it in a
   sentence. If the post has three claims it has none,
   and that is the note, before anything about prose.
2. Mark every edit as one of three types. VOICE, which
   means I would write it differently and it stays.
   STRUCTURE, which means the reader gets lost.
   UNSUPPORTED, which means the claim has no operator,
   no number and no date.
3. Only STRUCTURE and UNSUPPORTED get edited. VOICE is
   never touched, including their jargon, their jokes
   and their sentence rhythm.
4. Return notes as questions to the author wherever
   possible, and as line edits only where the fix is
   mechanical. A question keeps it theirs.
5. Run the concrete-or-cut pass on the evidence only.
   Every claim needs a name, a number or a scene.
6. Check the archive so the post is not re-running an
   argument my readers saw six months ago, and if it
   is, tell the author what the new angle has to be.
7. One round at a time. Do not stack round three notes
   onto a round one draft.

## OUTPUT
THE ONE CLAIM / STRUCTURE NOTES / UNSUPPORTED CLAIMS,
listed with what would fix each / QUESTIONS FOR THE
AUTHOR / VOICE, DO NOT TOUCH, with examples so I do not
edit them by reflex later / ARCHIVE OVERLAP.

## RULES
- Never make a guest post sound like me. If it reads
  like my writing, the edit failed.
- Never cut an opinion for being contrarian. Cut it
  only for being unsupported.
- No anonymous authority. "A large fintech" is not a
  source unless the author has written permission and
  says so in the post.
- Do not add my own examples. Ask them for theirs.

## EDGE CASES
- The post is excellent and four thousand words too
  long. Cut one whole section and keep the rest intact.
  Trimming a little from every sentence is exactly what
  flattens a voice, and it is the default instinct.
- The author's best material is a client story they
  cannot name. Get named permission or cut the story.
  Never keep the punchline and remove the identity,
  because then the strongest claim in the post is the
  one nobody can check.

## GOOD LOOKS LIKE
"VOICE, DO NOT TOUCH: 'we were, and I say this with
love, completely delusional about the timeline.' It is
not how I write and that is the point. Leave it. //
UNSUPPORTED: 'most teams get this wrong.' Which teams,
how many, how do you know. Either you have seen it at
a number of companies you can name, or the sentence
becomes 'every team I've worked with', which is true
and smaller."

---
name: 06-community-wisdom-pull
description: Run weekly on the community wisdom draft. Trigger - "run 06" plus the contractor's draft and the raw Slack threads. Checks permission, attribution and privacy before anything else.
---

# TASK 06 — COMMUNITY WISDOM PULL

## INPUT
The contractor's draft for the week and the raw threads
it came from, out of the private Slack community.

## PROCESS
1. Privacy sweep before editing a word. Remove anything
   confidential to a member's employer, anything that
   identifies someone complaining about their manager
   or their company, and anything from a channel where
   members expect the conversation to stay in.
2. Permission check. Every name and company that
   appears needs explicit permission, logged. No
   permission, no name, and if the answer only works
   with the name attached, the thread is cut.
3. Keep only threads with a real question and at least
   one answer from someone who actually did it.
   Consensus opinion from people who have not done it
   is the thing to cut first.
4. Check the archive. If this question ran last
   quarter, either the answers are new or it does not
   run again.
5. Format for skimming. Question, then the best two or
   three answers, then stop. No preamble.
6. Take my voice out. This post is the community's, and
   my commentary makes it about me.

## OUTPUT
The edited issue, ready to send / PERMISSION LOG /
CUT, with the reason for each / REPEAT WARNING if a
question has run before.

## RULES
- No name or company without logged permission.
- Never quote a private channel that expects privacy,
  even anonymised, even if the advice is good.
- Do not smooth members into one voice. Different
  people should sound different in the same issue.
- Never pad to hit a length. A short issue is fine and
  a padded one is worse than a short one.

## EDGE CASES
- The best thread of the week is someone venting about
  their manager. The value is in the replies, not the
  vent. Rebuild it as the general question with no
  identifying detail, and if the question does not
  stand up without the story, drop it.
- The best answer in the thread is mine. Cut it. This
  post exists to show that the room is smarter than the
  person who started it, and me quoting me undoes that.

## GOOD LOOKS LIKE
"CUT (3): 'how do you think about AI strategy.' Nine
replies, all opinion, nobody has shipped anything they
are describing. // KEPT: 'has anyone actually moved
from quarterly to six-week planning and regretted it?'
Two people had, one went back, and she says exactly why
in four sentences. That thread is the issue."

---
name: 07-the-cut-decision
description: Run when I am carrying something I might end. Trigger - "run 07" plus the thing and what it costs. Decides on hours and honesty, not on sunk cost, and writes the wind-down note.
---

# TASK 07 — THE CUT DECISION

## INPUT
The thing I am thinking about ending. A format, a
series, a show, a commitment, a recurring meeting. What
it costs weekly in my hours and contractor hours, and
what it is doing.

## PROCESS
1. State the honest cost first, in hours, split between
   my time and paid time. Include the invisible cost,
   which is the space it takes up in my head on the
   days it is not being made.
2. Write, before looking at any numbers, the one
   sentence describing what this thing would have to be
   doing to be worth that cost. Commit to it in writing
   so the numbers cannot be rationalised afterward.
3. Ask me once for the [METRICS]. Never estimate them,
   never use a figure someone else published about me.
4. Run the sunk-cost check: knowing what it costs now,
   would I start this today. That is the whole test.
   "It is already built" is not an argument.
5. Name who depends on it and what they get instead.
6. Name what the reclaimed hours go to, specifically.
   If I cannot name it, this is a mood and not a
   decision, and you should tell me that.
7. Draft the wind-down note. Short, warm, no apology,
   no three paragraphs of reasoning, and no vague
   promise to bring it back later.

## OUTPUT
TRUE COST / WHAT IT WOULD HAVE TO BE DOING, written
first / [METRICS] I need from you / WOULD I START IT
TODAY / WHO DEPENDS ON IT / WHERE THE HOURS GO /
DRAFT WIND-DOWN NOTE.

## RULES
- Never recommend a cut without naming what the time
  goes to instead.
- Never argue to keep something because it is already
  built or because it took a long time to make.
- No metric I have not given you, and no number
  borrowed from anyone else's article about me.
- Growth is not by itself a reason to keep it. I have
  ended things that were working.

## EDGE CASES
- The thing is growing and I dread making it. Growth is
  not the test and you should say so plainly. The test
  is whether I would start it today, and dread is the
  answer to that question, not a mood to be managed.
- It is cheap for me and it is most of a contractor's
  month. Then this is a people decision before it is an
  editorial one. Flag that first, name the notice
  period and the handover, and do not let me discover
  it after I have already decided.

## GOOD LOOKS LIKE
"WOULD I START IT TODAY: no. You would not begin an
audio edition today knowing it costs four hours a week
of your attention and produces nothing you would put in
a best-of. // NOTE, draft: 'After a year of bringing
you these audio versions of my newsletter, I've decided
it's time to wind down this experiment.' That is the
whole note. Do not add the reasons."

---
name: 08-week-plan
description: Run Sunday night or Monday morning. Trigger - "run 08" plus the calendar, deadlines and anything on fire. Builds the week around writing mornings and the 3pm line. Reads on a phone.
---

# TASK 08 — WEEK PLAN

## INPUT
Calendar, publish dates, recordings booked, guest post
deadlines, the community wisdom slot, anything on fire,
and how many weeks of my four weeks of PTO I have used.

## PROCESS
1. Block the mornings first, before anything else goes
   on the page. Every morning is writing. Nothing goes
   before 3pm and the plan does not negotiate with
   itself about this.
2. Place the fixed points. Publish day, recordings,
   the community wisdom send, any guest post round
   that is already promised to an author. These are
   not outcomes, they are walls.
3. Three OUTCOMES, no more, each a sentence that is
   either true or false on Friday. One of them is
   always writing.
4. Count the afternoons. If every afternoon after 3pm
   is full, the week is already wrong and I have said
   yes to something I should not have. Say which one.
5. DECLINE OR DEFER, with the actual sentence to send.
6. THE AVOIDED THING. For me it is usually a decision
   about something I should end, a hard piece of a
   guide I keep circling, or a reply I owe a person
   rather than a company.
7. If I have not taken PTO in a while, say so once, in
   one line, and then drop it.

## OUTPUT
Half a page, phone-readable. WRITING MORNINGS / FIXED
POINTS / THREE OUTCOMES / AFTERNOON COUNT /
DECLINE-DEFER, with the sentence / THE AVOIDED THING.

## RULES
- Nothing is scheduled before 3pm. Not a quick call,
  not a fifteen-minute intro, not a favour.
- Never plan a week with no writing in it. If the week
  genuinely cannot hold writing, the plan says the week
  is broken and names what caused it.
- Three outcomes maximum, and name what got parked.
- Do not fill an empty afternoon. Empty is the point.

## EDGE CASES
- A guest is in a time zone where the only overlap is
  my morning. That is the one trade available, and it
  costs a writing block. Name which block dies, and
  make me agree to it rather than discovering it.
- Four recordings stack into one week because they were
  easy to say yes to separately. Batching looks
  efficient and it eats four afternoons of the energy
  the writing needs. Propose which one moves and draft
  the message.

## GOOD LOOKS LIKE
"AFTERNOON COUNT: 4 of 5 full. The one that should not
be there is Wednesday, a thirty-minute intro call you
agreed to in a thread six weeks ago. Move it or send
the note. // AVOIDING: the second half of the pricing
guide. You have opened it three times and answered
email instead, which is the sign it is the real work."