Park, Don't Kill: What to Do When Your Kill Criterion Comes Due and the Experiment Never Actually Ran

Draft only. Publishing = CEO approval (public content). Sixth SEO asset, written as a direct sequel to

SSK-SEO-004 (kill criteria). That post assumes the deadline arriving with zero traction is a clean verdict. This one is the case where I hit that exact deadline myself, on a real project, and the honest read wasn't "kill" — it was "the test never actually happened." Grounded in a live, ongoing situation (not hypothetical), generalized enough not to expose internal specifics. Value-first, product mention only in the closing paragraph.

Park, don't kill: what to do when your kill criterion comes due and the experiment never actually ran

I wrote a kill criterion before I launched a side project: zero sales by a fixed date, kill it. The date arrived. Zero sales. By my own rule, that's a kill. I almost wrote the kill notice — then I looked at what actually happened over those weeks and realized the criterion had measured something true but not the thing I meant to measure. Traffic showed up. Nobody who saw the page had ever heard of it from a source I controlled. The one lever that would have told me whether the offer failed — putting it in front of even one person who actually fits the audience — never got pulled. Zero sales after zero real attempts isn't "no demand." It's "no attempt," wearing the costume of a verdict.

Here's the distinction that saved the project from a wrong kill, and the pattern I use now.

1. A kill criterion is only honest if the experiment it's measuring actually ran

"Zero sales by day 30" is a fine rule if day 30 means 30 days of the offer being seen by the people it was built for. It's a different thing entirely if day 30 means 30 days of anonymous, untraceable traffic that never included a single attributed touch — a share, a targeted post, a warm intro — to anyone who matches the buyer. Before you honor a kill date, ask the one-sentence question the date itself can't ask for you: did the real test run, or did the clock just run?

2. "No signal" and "no attempt" look identical in the data — and only one of them means anything

This is the trap. Both show up as the same flat line: zero conversions, zero replies, zero interest. But "no signal" means you showed the right people and they said no — that's information, and it's exactly what a kill criterion exists to catch. "No attempt" means the clock ran out before anyone who could say yes ever saw it — that's not a verdict, it's an unrun experiment wearing a verdict's clothes. Confusing the two means you either kill something that was never fairly tested, or you keep funding something that genuinely failed because you can't tell the difference. The only way to tell them apart is to check, explicitly, whether anything you'd call an attributed at-bat happened at all.

3. Park is a real third option, and it needs the same rigor as kill

Most founders only have two states in their head: keep going, or shut it down. Add a third: parked — not dead, not actively worked, sitting at zero cost until a specific, named condition is met. A park decision is worthless if it's vague ("check back sometime"), so give it the same discipline you'd give a kill criterion:

• An unpark condition — a single concrete event, not a vibe. Mine is one attributed touch: put the offer in

front of one real prospect, tagged so I can see what happens.

• A real kill criterion for after that touch happens — if the one fair test also comes back at zero, that's

the verdict, and now you kill it for the right reason.

• A park-date — a point where, if the unpark condition still hasn't happened, you write down explicitly that

it never got a fair test, instead of letting it drift in limbo forever pretending to be "still deciding."

4. Announcing a change of pace doesn't enforce it — check where the check actually lives

I told myself (and the agents working the project) that daily re-checking was over — from now on, only check when something real happens. The next scheduled run fired anyway. Twice. The announcement lived in a document; the thing doing the firing was a scheduler that had never read it. The fix wasn't writing the announcement again, louder — it was moving the boundary to the layer that actually executes: an alert wired directly to the condition, so re-checking becomes something a machine does for free instead of something a tired future-you has to remember not to do. If you catch yourself re-stating a decision because the old cadence keeps firing anyway, the decision is in the wrong place.

5. When the deadline lands on an unfair test, act on that fact — don't just measure it again

Once you've established the test never ran fairly, the productive move isn't a longer writeup explaining that again next week. It's small and concrete: lock in the park decision as a fact (not a pending debate), write the one unpark condition down where it can be checked later, and stop paying attention on the old schedule. The discipline that matters here is the same one that makes kill criteria work in the first place — write the boundary down once, in a place a future check can read, and then actually let it govern what happens next instead of re-litigating it every time the clock ticks.

---

The point

A kill criterion protects you from the sunk-cost trap of a project that quietly never dies. But a criterion that fires on a deadline without asking whether the underlying test actually ran protects you from the wrong thing — it kills unrun experiments instead of failed ones. Park-not-kill is the missing middle state: cheap to hold, honest about why it's paused, and specific about the one fact that would resolve it either way. The rule isn't "never kill anything." It's "make sure the test ran before you trust its result" — the same rule, really, as never trusting a metric you haven't checked is measuring what you think it's measuring.

This exact distinction — separating "no demand" from "no fair test," and giving a parked project a numeric unpark condition and a park-date instead of an indefinite maybe — is one of the decision patterns packaged into the [Founder OS Kit] alongside the constitution, approval-gate, budget-envelope, and kill-criteria files. If a deadline you set is about to land on a project that technically failed but was never actually tried, park it on purpose instead of killing it by accident.

asset ideas

• Diagram: two-by-two grid — {test ran / test didn't run} × {zero signal / real signal} — with "kill" only in

the top-right cell (test ran, zero signal) and "park" in the bottom-right (test didn't run, zero signal).

• Screenshot: a real (sanitized) park spec — unpark condition, numeric kill-after criterion, park-date — as a

three-line block, the same visual format as the kill-criteria post's "number and a date" example.

• Internal-link to SSK-SEO-004 (kill criteria) as the direct prequel, and SSK-SEO-003 (budget envelopes) for the

"write the boundary before you need it" thesis this post extends into a third state.