How to Kill a Feature Idea Before It Costs You Weeks
How to kill a feature idea before it eats your evenings: find the assumption, set the stop rule first, read results like a sceptic and write the obituary.
Kill a feature idea by testing its riskiest assumption cheaply, deciding in advance what result means stop, and then actually stopping. Write down what you learned so the idea can't sneak back in six months. Every idea you kill returns weeks of evenings.
How to kill a feature idea
Nobody is going to throw you a party for the feature you didn't build.
That's the problem. When you ship, there is a changelog, a tweet, a small hit of pride. When you kill an idea, there is silence. You're alone, so there's nobody to celebrate with, and the decision goes unrecorded. Over a few months, discovery starts to feel unproductive next to all that visible shipping.
It isn't. Killing the right idea is often the most valuable thing your week produces. It hands you back weeks of evenings, and evenings are the one budget a one-person business can't refill.
So learn to do it on purpose. Here is the method.
Why ideas are so hard to kill
Because you've already built it in your head.
You can see the screen. You've named the button. You know which customers will love it. By the time you "evaluate" the idea, you're not judging a guess. You're defending a plan.
And AI has made this worse. It used to be that building the wrong thing took months and a developer, so cost forced you to be careful. Now it takes a weekend. The temptation is to skip the question and go straight to a beautiful answer. Cost no longer protects you. You have to protect yourself on purpose.
A feature you killed in an afternoon is a weekend you kept.
Free guide · 21 pagesDiscovery and delivery, one person.The Dual-Track Playbook: how to keep discovering while you keep building.Get the free guide →Step one: strip the solution, find the assumption
An idea arrives as a feature. "Add a dashboard." "Build the new onboarding." That is a solution, and solutions can't be tested. Assumptions can.
So turn it around. Ask what must be true for this to work:
- People actually have the problem.
- They will change their behaviour to use the fix.
- They will understand it.
- They will pay, or at least value it enough to matter.
Rank those by which would hurt most if wrong. Then go after that one. Not the comfortable one. Most of us test whether the thing is usable, because usable is measurable and pleasant. Whether anyone cares is the assumption that actually kills ideas, and it tends to go untested until launch. Our post on finding the riskiest assumption shows how to spot it.
Step two: decide what "dead" looks like before you test
This is the step that makes the rest honest.
Before you run the test, finish this sentence in writing: "If I see ___, I will drop this."
Then ask the real question. If this comes back negative, will I actually stop?
If the honest answer is no, don't run the test. Build the thing. At least that is honest. A test you would ignore is worse than no test: it costs you an evening and manufactures false confidence.
If the answer is yes, you've got a real kill switch. Now choose the cheapest test that could move you. A conversation. A page with a price on it. A rough prototype. Doing it by hand for one person. Or looking at data you already have. The post on cheap tests goes through the options.
Step three: read the result like a sceptic
When the result is bad, your brain starts bargaining. "They didn't understand the question." "Wrong week." "Maybe with a better design."
Sometimes that's true. Most of the time it's the part of you that wanted to build, filing an appeal.
Use this table to stay honest.
| What your brain says when you kill a feature idea | What is probably true | What to do |
|---|---|---|
| "People loved it in the chat." | Enthusiasm is cheap. People are generous in conversation. | Look for commitment, not compliments |
| "The test wasn't fair." | You didn't define fair before you started | Check your written bar. If it said stop, stop |
| "I'll just build a small version." | A small version of an unwanted thing is still unwanted | Ask what the small version proves that the test didn't |
| "It's already half designed." | That is sunk cost talking | Evenings you haven't spent are the only ones worth protecting |
| "Maybe later." | "Later" is how dead ideas return with no memory of why they died | Record it, with the reason |
Look at the second row again. If you wrote the bar down first, this argument ends in one line. That is the whole value of writing it down.
Step four: write the obituary when you kill a feature idea
Four lines. That's all.
- What I asked or assumed.
- What I did to test it.
- What I found.
- What I decided, and why.
Keep it somewhere you can find in six months. Not in your head. Not in a chat thread you'll never reopen.
There are two reasons. First, it protects your discovery work from your own accusation that it produces nothing. A list of killed ideas is output. It proves the filter works. Second, it stops the same idea coming back. Without a record, the identical suggestion will return in six months, feel fresh, and cost you the same test again.
Before starting anything that feels familiar, check the record. It might already be dead.
Free assessmentHow trapped are you, really?Take the Corporate Suffocation Index, the free solopreneur readiness assessment.Take the assessment →Step five: refuse the zombie
The idea you killed will try to return in a different costume.
It comes back as a "lite" version. As an experiment. As something a customer casually asked about. When it shows up, run it through the same gate as anything new: what is the assumption, what would make me drop it, what did the record say?
If new evidence has appeared, good. Reopen it. If nothing has changed except your mood, it stays dead.
One note on customers. A single request is a data point, not a mandate. Treat it as a reason to ask about their past behaviour, using the habits in talking to customers without leading them. Don't treat it as a spec.
What you get when you kill a feature idea
Say you sell a productised service on your own. A feature idea lands on a Tuesday. It would take most of a month of evenings to build. You spend two conversations and a look at the data you already have, and the idea fails the bar you set. What did that cost? An evening or two. What did it return? A month. A month you can now spend on something with better evidence behind it. Every idea killed for two conversations is a month of evenings redirected. That is the economics of the whole practice. Building is by far the most expensive way to test an assumption. Discovery exists to answer cheaply what you would otherwise answer in evenings. A kill is the cleanest proof that it worked.
There is a quieter benefit too. Working alone, uncertainty has nowhere to go. You either build the thing you doubt or argue with yourself at eleven at night and lose. A kill process gives you a third option: this is a real question, here is the cheap test, I'll know by Friday. An anxious loop becomes a question with a date on it.
Free guide · 21 pagesDiscovery and delivery, one person.The Dual-Track Playbook: how to keep discovering while you keep building.Get the free guide →How to tell if you are killing enough
Here is a blunt check. Look back over your last few months of discovery. How many decisions not to build did it produce?
If the answer is none, discovery isn't a filter. It's an approval process. Your build list is being fed unexamined, with a few extra meetings attached. That happens most when you put pre-decided features into the discovery track: validating a solution you already chose reliably produces the confirmation you went looking for.
A healthy track kills things. Not everything, and not out of habit. But regularly, and visibly. Count it. Put the killed ideas next to the shipped ones and see which list is longer. If you want to know whether your idea ever clears the bar, the validation post covers it from the other side.
Free assessmentHow trapped are you, really?Take the Corporate Suffocation Index, the free solopreneur readiness assessment.Take the assessment →Frequently asked questions
How do I know an idea is worth killing rather than testing further?
If the riskiest assumption has been tested and came back below the bar you wrote down in advance, kill it. If you never tested the dangerous assumption, only the comfortable one, test again before you decide either way.
What if a customer asks for the feature?
Treat it as a lead for a conversation, not an instruction. Ask what they do about the problem today, when they last hit it and what they tried. Past behaviour is evidence. A request is a prediction.
Should I record ideas I only thought about for a minute?
Record the ones you tested or seriously weighed. Four lines is enough. The goal is that nobody, including future you, wastes another evening relearning the same thing.
Can I come back after I kill a feature idea?
Yes, if the evidence changed. The record tells you what you assumed and why you stopped, so you can see whether anything is genuinely different. If only your enthusiasm has changed, leave it alone.
Doesn't it make me less ambitious to kill a feature idea?
No. It points your limited evenings at the ideas with the best evidence behind them. Building the wrong thing beautifully is the unambitious choice, because it feels like progress and isn't.
The full method, with the checklists, is in The Dual-Track Playbook, a free 21-page playbook.
How trapped are you, really?
Take the Corporate Suffocation Index, the free solopreneur readiness assessment.