Pursue, park, or kill

Every project on the shelf gets exactly one of three verdicts — pursue, park, or kill — because deciding later is not a fourth option, it’s just a slower kill.

Every project on the shelf now has an honest inventory and some evidence of whether anyone would pay for it, and at least one of them has a maintenance number you actually measured in hours per month. That is a shelf inventory, a demand signal, and one real cost figure sitting there, unused, because nothing has been decided yet. This lesson forces the decision — including the part where you decide with a measured number for one project and honest estimates for the rest.

Three verdicts, not two

The natural way to think about an unfinished project is binary: keep going, or admit it failed. That framing is why most of the shelf has sat untouched for months — every project on it fails the “keep going” test on a bad day and passes it on a good one, so nothing ever moves.

Annie Duke’s argument in Quit is aimed at exactly this paralysis, and the mechanism is kill criteria: the specific, measurable conditions under which you will walk away, decided while you can still think clearly about them, not in the moment you are staring at the decision. She pairs a state — an objective condition, hit or missed — with a date: if by (date) I have not reached (state), I quit. The reasoning behind the timing is hers too: it is hard to make a good call about walking away when you are the one currently facing the decision to walk away. Decide earlier, while you are not.

That mechanism is genuinely useful here, and this lesson borrows it directly for the kill verdict. But Duke’s own framework, in both of the sources this lesson is drawn from, presents exactly two paths: continue, or quit. The third verdict below — parked — is not Duke’s idea. It is this course’s own addition, built because “continue or quit” turns out to be the wrong shape for a shelf of side projects specifically: some of them are not failing, they are just not the two you have room for right now, and calling that a kill would be dishonest in the other direction.

What “parked” means, concretely

Parked is not “I’ll think about it later.” That sentence, unfollowed by a date, is how a project quietly becomes the fourth kind of outcome this lesson exists to eliminate: abandoned — a kill nobody wrote down. The domain renewal still charges the card. The half-finished code still shows up when you search your own repositories. The occasional user email still arrives and still doesn’t get answered. Nothing about the project changed by not deciding; you just stopped being the person who decided it.

Parked, done properly, has three parts:

A verdict — an explicit statement that this project is not being worked on right now, made once, not re-litigated every time you open the folder.
A reason it isn’t a kill — one sentence on what would have to be true for it to be worth picking back up: a platform launched, a cost dropped, your own available hours changed. If you can’t write that sentence, it isn’t parked, it’s a kill you’re avoiding.
A dated revisit, which is the part that separates this from abandoned and is covered next.

A finished, traffic-free site built for a subject you’re no longer excited about is a reasonable park if the reason is “SEO for this niche takes eighteen months and I’m not starting that clock yet” — and a reasonable kill if the honest reason is “I don’t want this to exist.” The verdict has to match the sentence, not the mood you’re in when you write it.

Where people get burned

Watch for the tell: if writing “parked” feels like relief instead of a decision, check whether you actually wrote a date. Relief without a date is abandonment wearing a nicer word.

The dated revisit is what makes parking honest

This is the same states-and-dates mechanic Duke describes for kill criteria, pointed at a different question. Instead of if by (date) I haven’t reached (state), I quit, a park verdict reads: if by (date) (state) still hasn’t changed, this becomes a kill. A half-built app for a young audience that depends on a platform review process might read: “Parked until app review turnaround drops under two weeks, revisit March 1 — if unchanged, kill.”

Without the date, “parked” costs you nothing to say and means nothing when said. With it, the project either gets picked back up on schedule or gets a real kill verdict when the date arrives and nothing changed — no relitigating, because you already decided the condition while you could still think clearly about it, which is the entire point Duke is making about kill criteria in the first place. The date is what lets you say “not now” honestly instead of using it to say “never” quietly.

Retrieval check

A project has been parked for over a year with no revisit date ever set. What verdict does it actually hold, and why?

Check your answer

It’s abandoned, not parked — regardless of what anyone called it at the time. Parked requires a dated revisit; without one there is no mechanism forcing the decision to ever happen again, which is functionally identical to a kill that was never written down. The label doesn’t change what’s actually happening: money and attention are still leaking out of a project nobody is deciding about.

The WIP constraint: at most two in “pursue”

Pursue is the smallest bucket on purpose, capped at two. The number is small because pursue is not a feelings category — it’s a claim about where the hours per month from the maintenance-cost work actually go, and one person’s evening hours divide badly across more than two live commitments before every one of them starts missing support requests and dependency updates.

The cap is also what makes the other two verdicts honest. If pursue has no ceiling, everything mediocre gets labeled pursue by default, because saying so costs nothing right now. A hard cap of two forces an actual ranking: of everything that could plausibly be worked on, which two are worth the hours this month, specifically — and everything else, including projects you still like, gets a park or a kill instead of a comfortable non-decision.

Writing the verdict down where you will see it again

A verdict decided in your head and not written anywhere has the same problem as an unwritten kill criterion: the next time you’re looking at the project, you’re back to deciding from scratch, in whatever mood you’re in that day. This lesson writes the Verdict field — pursue, park, or kill, with a dated revisit where relevant — into learning/monetizing/PORTFOLIO.md, next to the inventory, the demand evidence, and whatever maintenance figures are recorded there — the measured one and the estimates alike. One place, one record, checked on a schedule rather than reconstructed from memory under whatever pressure prompted you to open the file this time.

Now apply it: verdict on all seven

Hands on

Assign a verdict to every project on the shelf

Done when: All seven projects in PORTFOLIO.md carry a verdict. At most two are “pursue.” Every “park” has a dated revisit. Every “kill” names what happens to its users and its domain. Every maintenance figure a verdict leaned on is either the one you measured or explicitly marked as an estimate.

Open learning/monetizing/PORTFOLIO.md and read what is actually recorded: an inventory line and a demand-evidence value for every project, plus the one maintenance number you measured.
For every project without a measured maintenance number, write a one-line estimate now, anchored to the project you did measure, and label it as an estimate. You are going to decide with these numbers, so the thing that has to be visible on the page is which of them were counted and which were guessed.
For each project, write one verdict: pursue, park, or kill. Decide from the record on the page, not from which project you feel best about today.
Count the pursues. If there are more than two, that is not a reporting error — it means you have not actually decided yet. Cut down to two before moving on, even if it means demoting a project you like.
For every park, write the state-and-date condition: what has to change, and by when, before it becomes a kill. No date means it is not parked yet.
For every kill, name concretely what happens to its users and its domain — a redirect, a shutdown notice, a data export, a transfer, letting the registration lapse. “I’ll deal with it” is not an answer this step accepts.
Bring the seven verdicts into the chat. I’ll push on any pursue past the cap, any park missing a real date, any kill whose users and domain plan is still vague, and any verdict resting on an estimate that is carrying more weight than an estimate can bear.

What this does not cover

Triage is done: every project has a verdict, and the ones worth real hours are capped at two. What triage does not tell you is how those two are actually supposed to make money — starting from the assumption that quietly wrecks most first attempts at pricing: the person using a thing and the person paying for it are not always the same person, and treating them as one is why the pricing page never converts.

Pursue, park, or kill

Every project on the shelf gets exactly one of three verdicts — pursue, park, or kill — because deciding later is not a fourth option, it’s just a slower kill.

Three verdicts, not two

What “parked” means, concretely

Parked, done properly, has three parts:

A verdict — an explicit statement that this project is not being worked on right now, made once, not re-litigated every time you open the folder.
A reason it isn’t a kill — one sentence on what would have to be true for it to be worth picking back up: a platform launched, a cost dropped, your own available hours changed. If you can’t write that sentence, it isn’t parked, it’s a kill you’re avoiding.
A dated revisit, which is the part that separates this from abandoned and is covered next.

Where people get burned

Watch for the tell: if writing “parked” feels like relief instead of a decision, check whether you actually wrote a date. Relief without a date is abandonment wearing a nicer word.

The dated revisit is what makes parking honest

Retrieval check

A project has been parked for over a year with no revisit date ever set. What verdict does it actually hold, and why?

Check your answer

The WIP constraint: at most two in “pursue”

Writing the verdict down where you will see it again

Now apply it: verdict on all seven

Hands on

Assign a verdict to every project on the shelf

Open learning/monetizing/PORTFOLIO.md and read what is actually recorded: an inventory line and a demand-evidence value for every project, plus the one maintenance number you measured.
For every project without a measured maintenance number, write a one-line estimate now, anchored to the project you did measure, and label it as an estimate. You are going to decide with these numbers, so the thing that has to be visible on the page is which of them were counted and which were guessed.
For each project, write one verdict: pursue, park, or kill. Decide from the record on the page, not from which project you feel best about today.
Count the pursues. If there are more than two, that is not a reporting error — it means you have not actually decided yet. Cut down to two before moving on, even if it means demoting a project you like.
For every park, write the state-and-date condition: what has to change, and by when, before it becomes a kill. No date means it is not parked yet.
For every kill, name concretely what happens to its users and its domain — a redirect, a shutdown notice, a data export, a transfer, letting the registration lapse. “I’ll deal with it” is not an answer this step accepts.
Bring the seven verdicts into the chat. I’ll push on any pursue past the cap, any park missing a real date, any kill whose users and domain plan is still vague, and any verdict resting on an estimate that is carrying more weight than an estimate can bear.