When should you kill a product experiment?

When it hits the kill criteria you set before you started — typically: no signal (nobody's using or wanting it), no pull (you're pushing it uphill with no organic interest), and no plausible path to it mattering. The key is deciding what 'not working' looks like in advance, while you're still objective, so you can act on it later when you're attached. An experiment that's earning no signal, no pull and has no path forward should die quickly so the attention goes to what's working.

Why decide kill criteria before you start?

Because once you've built something, you're attached to it, and attachment makes you rationalize keeping a dead product alive ('it just needs one more feature'). Deciding in advance what failure looks like — while you're still objective — gives you an honest test to apply later, when you can't trust your own judgment. It turns killing a product from an emotional, agonizing decision into checking whether a pre-agreed line was crossed. Kill criteria are a promise your objective self makes to your attached future self.

How do you know when to stop working on a side project?

Stop when it's failing the criteria you set at the start and there's no path to changing that. Concretely: it's getting no genuine signal or pull despite a fair effort, you're the only one who cares, and you can't see how it becomes something people want. Left running, a project like that doesn't just waste its own time — it quietly drains attention from things that could work. Killing it cleanly, and keeping what you learned, is how you free that attention.

My Kill Criteria for Product Experiments

I decide when to kill a product experiment before I start it — by writing down what "not working" looks like: no signal, no pull, no path to mattering. This sounds cold, but it's the opposite: it's what lets me start things at all, and it's what makes running several experiments survivable for one person. Without kill criteria set in advance, weak products linger — kept alive by attachment and "one more feature" — quietly draining the attention that should go to what's working. Kill criteria are a promise my objective self makes to my attached future self.

The attachment problem

Here's the trap: the moment you build something, you're attached to it. Not because it's working — because it's yours. And attachment is a terrible decision-maker. It rationalizes: "it just needs marketing," "one more feature and it'll click," "it's too early to tell." A dead product can absorb months of that reasoning, because the person deciding whether to kill it is exactly the person least able to judge it honestly.

So I don't trust my future, attached self to make the call. I make it in advance, while I can still see straight.

Decide before you start

Before I ship an experiment, I write down what would tell me it's not working — the specific conditions under which I'll stop. It's a simple act with a big payoff: later, killing the product isn't an agonizing emotional decision, it's just checking whether a line I already drew got crossed. The objectivity is borrowed from the past, when I had it.

Kill criteria written after you're attached are just excuses waiting to happen. Written before you start, they're the only honest judge you'll have when it matters.

What "not working" looks like

My criteria come down to three signals, and their absence:

No signal — nobody's using it, nobody's asking for it, nothing organic is happening.
No pull — I'm pushing it uphill; every bit of interest requires me to manufacture it, and nothing pulls back.
No path — I can't see, honestly, how it becomes something people want. Not "it's hard," but "I don't have a route."

One of these might be early days. All three, after a fair effort, is a dead product. The fair-effort part matters — kill criteria aren't an excuse to quit at the first quiet week; they're a line for after you've genuinely given it a real shot.

The sunk-cost trap

The reason kill criteria have to be pre-committed is sunk cost. The more you've put in, the harder it is to stop — which is exactly backwards, because what you've already spent is gone either way. The only honest question is forward: from here, is this worth more of my attention than the alternatives? Attachment can't answer that; a line drawn in advance can.

Killing cleanly

Killing isn't deleting and pretending it never happened. I archive it honestly — the status label is part of the point — and I keep what I learned. Often the problem was real even though this solution wasn't, and that learning feeds the next idea's go/no-go filter. A killed experiment that taught you something isn't a failure; it's cheap tuition. The failure is the one you didn't kill, that quietly ate a year.

What usually goes wrong

No criteria at all. Deciding to stop by feel, which means never, because attachment never feels ready.
Setting criteria after you're attached. Too late — you'll write them to be passable.
Quitting too early. The opposite error: killing before a fair effort, so nothing ever gets its real shot.
Killing without learning. Deleting the evidence instead of keeping what the experiment taught you.

Write your kill criteria before you start, give each experiment a fair effort, then apply the line honestly — no signal, no pull, no path means stop — and keep what you learned. It's the discipline that makes a studio of small products possible instead of a graveyard of half-tended ones. It's the last rule of my operating system, and the one that protects all the others.

Part of Building AI Products. See also my product operating system and how I decide whether an AI product idea is worth building. The newsletter sends one practical build lesson every two weeks.