The Checklist I Run Before I Kill a Product
4 min read
I’ve pulled two product lines off Gumroad this year: three n8n templates in July, five SaaS boilerplates in August. Both times I wrote a post explaining the reasoning after the page already changed. Neither time did I have a checklist before I made the call. I noticed a pattern, then acted on it, then wrote about it once it was done. That’s a fine way to make one decision. It’s a bad way to make the same decision twice without knowing if I’m applying the same standard or just repeating a mood.
So here’s the checklist, built backward from the two calls I already made, so the third one (if there is one) isn’t just a feeling I trust because the first two turned out fine.
Signal one: is there a channel, or just a page
The question that actually did the work both times wasn’t “is this selling.” It was “is there anything, anywhere, other than me, that would put this in front of a stranger who wants it.” For the n8n templates, the honest answer was no. n8n.io has its own template library and I never did the separate work of getting listed in it properly, so the templates existed only as a Gumroad link I’d shared a handful of times. Same story for the boilerplates: no directory, no marketplace, no community feed, just a checkout page waiting for traffic I had to personally generate every time. A product with a real channel underneath it, the Obsidian plugins, riding the plugin directory, or the Etsy shop, riding Etsy’s own search, gets to fail or succeed on its own merits. A product with no channel is just waiting for me, specifically, to keep showing up for it forever.
Signal two: have I personally stopped pushing it
This one is less flattering to write down. Both times, by the point I made the call, I hadn’t manually promoted the product in weeks. Not because I’d decided to stop, just because attention drifted to whatever I was building next. Since neither product had a channel of its own, “I stopped pushing it” and “it stopped getting found” were the same sentence. That’s uncomfortable to sit with, because it means the retirement wasn’t really “this didn’t work,” it was closer to “I got bored of being its only distribution channel and eventually admitted that out loud.”
The signal I don’t have, and stopped waiting for
Neither retirement came with a real sales verdict. I never let the n8n templates run long enough, with enough traffic, to know if the problem was the product or the platform. Same with the boilerplates. I could frame that as a weakness in the checklist, and it is one, but demanding a clean sales number before acting on the other two signals would mean never acting until a product has already absorbed months of quiet neglect. At some point “I don’t have proof it’s dead” stops being caution and starts being an excuse not to make a call I can already see coming.
Where this checklist gets used as an excuse
I wrote recently about noticing that I reach for building something new instead of fixing distribution once I’ve diagnosed a product’s real problem. This checklist sits right on top of that habit, and I don’t think it fully escapes it. “No channel, no recent push, no proof either way” is a clean-sounding set of criteria, but it’s also exactly the set of criteria that lets me close a tab and start something new without doing the harder work of building the channel I said was missing. I used it honestly for the boilerplates and the n8n templates. I can’t promise I’ll use it as honestly the third time, once it’s a known move instead of a hard conclusion I fought my way to.
What the checklist is actually for
Not to make killing a product feel good, and not to make the decision automatic. It’s there so the next time I catch myself wanting to quietly stop maintaining something, I have to answer three specific questions instead of one vague feeling: is there a channel here, have I actually kept showing up for it, and am I retiring this because it’s dead or because building something new is easier than fixing the one thing that’s actually wrong with it. I can still get the answer wrong. At least now I’ll know which question I skipped.