Here is how I knew something was wrong: a feature had 247 Salesforce requests, we had funded it for a full quarter, and the moment we shipped it almost nobody used it. The feature was Advanced Scheduling. Three months post-launch it had under 50 active customers out of 4,000, in a system where even niche features hit 20% adoption. So we killed it, and in the process we found what customers actually needed.
Understand the failure before you rip it out
I did not want to rip it out without understanding why. That is a different kind of stupid, learning nothing while shipping nothing. So I went to the customers who had requested it but were not using it. Twenty calls, one structured question: "Talk me through how you would use Advanced Scheduling in your workflow."
Almost none of them could articulate a specific use case. They knew competitors had it. They had seen it in demos. But when I asked what they would actually do with it, the answers were vague. So I kept digging: "What problem are you trying to solve?" The real answer emerged. They wanted to spend less time on repetitive operations. They did not want Advanced Scheduling. They wanted existing features they could not find.
Reorganize before you delete
I brought this back to a resistant team. There is a real ego piece: shipped features that do not get used feel like failure. So I proposed keeping the code and killing the narrative. Over two weeks we did three things. We renamed Template Operations to Batch Scheduling so the name matched what customers searched for. We moved it to the Operations section where customers were already looking. And we added a contextual prompt: when a user did the same action twice in a week, the UI suggested making it a scheduled batch. We did not build anything new. We disclosed what was already there.
Adoption went from under 50 to 600 customers in six weeks. Platform-wide activation lifted 15%, because customers who could find one feature started finding others. By Q2 planning we deleted the Advanced Scheduling code entirely. It took 30 minutes.
The forward question that beats sunk cost
The best product decision of my career was also a kill, one I made sure never shipped. The room always wants to ship, because people poured months in. The only thing that cuts through is one forward question: knowing what we now know, would we start this today? The months already spent are not a reason to finish. They are a reason it is hard to think clearly.
This week, pick the one feature you would not start today, run discovery on its non-adopters, and separate the sunk cost from the forward value in writing. If the fresh answer is no, reorganize or kill it, and tell customers what to use instead.