How to let go of an idea you are attached to
The hardest part of this job is not having ideas. It is throwing away the ones you like.
I am not writing that as advice. I am writing it because I am bad at it, and the specific way in which I am bad at it took me years to notice.
The three weekends
A few years ago I spent three weekends building a tool for organising my own notes. Data model, interface, the lot. It worked.
I never showed it to anybody.
Not once. Not a screenshot, not a link, not a “does this seem useful to you”. I told myself I was waiting until it was ready, and I believed that, and it was not true. What I was actually doing was protecting it from an answer.
That is the only project of mine that failed before anybody ever saw it, and it is the one I think about most. Because the failure was not the idea. The idea might have been fine. The failure was that I had already decided it was mine in a way that made testing it feel like a risk rather than the point.
Why attachment forms, mechanically
It is not sentimentality. It is arithmetic that your brain does badly.
Attachment tracks effort, not quality. The same idea is easy to drop after two days and nearly impossible after two months, and how good it is barely enters into it. This is why every piece of advice about killing your darlings is useless at the moment you need it — by then the cost of stopping feels enormous, and the thing that made it feel enormous is exactly the thing that is already gone.
Defending the idea and defending yourself merge. Once you have argued for something in a room, changing your mind has a social price that has nothing to do with the product. I have watched people — including me — quietly stop looking for disconfirming evidence, not dishonestly, just by asking slightly fewer questions.
The evidence gets softer as you get more invested. Early on you want to know. Later you want to be right. The interviews stop being “what did you do the last time this happened” and start being “would you use this”, which is a question people answer with manners rather than information. That is how a polite no starts sounding like a yes.
The three signs I have learned to read
None of these are about the idea. They are all about your own behaviour, which is the part you can actually observe.
1 · You are polishing what was never at risk. This is the strongest one. If the core assumption is untested and you are refining the interface, you are avoiding, and the craft is a costume. I did exactly this on a pricing calculator I never launched, and called it attention to detail.
2 · You have not shown it to anyone who could say no. Showing it to people who will be encouraging is not showing it. The test is whether the last person you demoed it to was in a position to tell you it was pointless, and whether you gave them room to.
3 · You cannot say what would change your mind. If there is no result that would make you stop, you are not running an experiment. You are building a monument. This one takes ten seconds to check and I skip it constantly.
What actually helps
Not willpower. Three practical things, in the order they work.
Write down the killing condition before you start. One sentence: if fewer than X of the people I show this to have ever done anything about this problem, I stop. Written before, it is a decision. Written after, it is a negotiation you will win against yourself.
Keep the thing small enough to bin. This is the real function of a prototype, and it is not speed. It is that a two-day thing can be abandoned and a two-month thing cannot, so the size of what you build determines how honest you are able to be later. The difference between a prototype and an MVP is entirely about this.
Separate the idea from the belief underneath it. Usually you are not attached to the feature, you are attached to a conviction about how people behave. The feature can go and the conviction can survive to be tested some other way, much more cheaply. This is the one that has actually rescued things for me, twice, an idea I binned came back two years later in a form that worked, because the belief under it was right and the first expression of it was not.
The part I have not solved
I still do this. The failure mode has just moved.
I no longer over-build things that nobody wants. What I do now is call something a prototype so I feel allowed to start it, and then not throw it away when it has answered its question. Same attachment, better vocabulary.
The best I have managed is making the decision earlier and in writing, when it is still cheap and I am still honest. Alberto Savoia, who spent years at Google watching products fail for exactly this reason, puts the underlying idea better than I can: make sure you are building the right thing before you worry about building the thing right. That is easy to agree with and hard to do, and the gap between those two is where most of the wasted years in this job live.
If you are in the middle of one of these right now, the check on whether a feature is worth building is three questions and takes under a minute. It will not make the decision for you. It will make you say out loud what you already suspect, which in my experience is most of the work.
Questions people ask about this
How do you know when to abandon a product idea?
When you notice you are working on the parts that were never at risk. Polishing the interface of something whose core assumption is untested is not craft, it is avoidance, and it is the most reliable signal I know, because it shows up weeks before the evidence does.
Why is it so hard to let go of your own idea?
Because by the time you have built something, defending the idea and defending yourself have become the same act. The effort already spent is gone either way, but it does not feel gone, and every hour added makes stopping feel more wasteful rather than less.
What is the sunk cost fallacy in product design?
Continuing with a plan because of what it has already cost rather than what it will return. In product work it usually appears as a feature nobody wants that keeps being improved instead of removed, and the giveaway is that the argument for continuing is always about the past.
How do prototypes help you avoid getting attached?
They make the thing cheap enough to bin, which is the only reliable defence. Attachment tracks effort, not quality — the same idea is easy to abandon after two days and almost impossible after two months, regardless of whether it was any good.