What Happened When We Killed Our Most-Requested Feature

The short version

We funded "Advanced Scheduling" for a full quarter based on 247 Salesforce requests. We shipped it in February. Three months in, fewer than 50 of 4,000 customers were using it. Twenty customer calls revealed the truth: customers couldn't articulate a specific use case. They'd seen the feature in competitor demos and asked for it by name. What they actually needed was existing features they couldn't find. We renamed "Template Operations" to "Batch Scheduling," moved it to the Operations section, and added contextual prompts. Adoption jumped to 600 customers in six weeks. Platform-wide activation lifted 15%. Then we deleted the Advanced Scheduling code entirely. The lesson: requests are not requirements. Behavior is.

Here's how I knew something was wrong: the feature had 247 Salesforce requests, we'd funded it for a full quarter, and the moment we shipped it, almost nobody used it.

The feature was "Advanced Scheduling" - the ability for customers to create complex, recurring templates for batch operations across environments. Sounds sensible. Sounds valuable. It had everything going for it.

Except nobody wanted it.

Well, that's not quite right. Two hundred forty-seven somebodies said they wanted it. But when we shipped it in February, the feature was used by under 5% of the accounts asking for it. Three months post-launch, it was being used by under 50 active customers out of 4,000. In a system where even our most niche features hit 20%+ adoption, this was a signal flare.

So we killed it. And in the process of killing it, we found what customers actually needed.

The Setup

Before we killed it, we had to understand why it was broken. And by "broken," I mean: why did 200+ customers want something they don't actually use?

This is where the playbook intersected with panic. Sales was using it as a reason for lost deals. "Competitor X has advanced scheduling." The CEO had mentioned it in an all-hands. The team had shipped it. It should have been a win.

Instead, we had a ghost feature: technically present, functionally absent.

I didn't want to rip it out without understanding why. That's a different kind of stupid - learning nothing while shipping nothing.

So I did what the continuous discovery playbook says: I went to customers.

The Discovery

I started with the customers who'd requested it but weren't using it. Twenty calls, structured around a simple question: "Talk me through how you'd use Advanced Scheduling in your workflow."

Here's what I learned: almost none of them could articulate a specific use case. They knew other platforms had it. They'd been in demos where competitors showed it. But when I asked them to describe what they'd actually do with it, the answers went vague.

But I kept digging. "What problem are you trying to solve when you think about Advanced Scheduling?"

That's where the real answer emerged: they wanted to spend less time managing repetitive operations.

So I asked: "Show me exactly what you're doing today that feels repetitive."

And they showed me. Most of them had the same workflow: they'd go to Section A (basic operations), repeat the same step four or five times weekly, copy data from one place to another, and apply it to different environments.

They didn't want Advanced Scheduling. They wanted existing features they couldn't find.

They wanted operations templating, which we already had, two sections over, with a name that made sense to engineers and zero sense to the person doing the operations.

The Moment of Truth

I brought this back to the team on a Wednesday. The feature was live. We'd shipped it. There was no narrative where "nobody wants this" looks good.

But there's another narrative: what if 200+ customers were telling us something other than "build this feature"?

What if they were saying "I'm struggling with repetitive work" and we heard "I want advanced scheduling" because that's what the competitor demo showed them?

What if the problem wasn't a lack of features, but that our discoverability was broken?

The team was resistant. "We already fixed this. We shipped it. Now we're supposed to kill it because adoption is low?" There's an ego piece here, and it's real. But we were also three months from the next planning cycle, and if this pattern held (high requests, low adoption) we'd build the wrong thing again.

So here's what I proposed. Keep the feature code, kill the feature narrative. Instead of promoting Advanced Scheduling, make the scheduling features we already had findable.

Three moves over two weeks. We renamed "Template Operations" to "Batch Scheduling," still functionally identical, but the name now matched what customers were actually searching for. We moved the feature to the Operations section where customers were already looking, instead of burying it in the Advanced menu where nobody looked. And we added contextual prompts: when a user did the same action twice in one week, the UI would suggest "Want to make this a scheduled batch?" A flag that said we see what you're trying to do, and here's a faster way.

We didn't build anything new. We disclosed what was already there.

What Happened Next

Adoption of the Batch Scheduling feature (the renamed, relocated, contextualized version of what customers already had) went from under 50 customers to 600 customers in six weeks.

But the bigger win was what happened to overall activation. When customers could find what they needed - without asking support, without watching demos - their activation improved by 15% across the platform.

Why? Because customers who could find one feature started finding other features they didn't know existed. The product became less of a treasure hunt and more like a system.

By Q2 planning, we'd also killed the Advanced Scheduling feature entirely. It took 30 minutes to remove the code. It had cost us one engineer, three months.

What I Learned

There's a thing that happens when you have a lot of customer requests: you treat them like votes. More votes = more legitimacy. Two hundred forty-seven requests feels like "this is real" even when the actual behavior says "this is phantom demand."

The playbook calls this an OST (Underlying Strategic Tension). The tension here wasn't "should we build advanced scheduling?" It was "are customers telling us they want a feature, or are they telling us they can't find what they need?"

I almost missed it because the team, me included, wanted to believe the feature would work. Shipped features that don't get used feel like failure. Ripping it out felt worse, until we realized we weren't ripping it out. We were reorganizing it.

This is the part of the playbook that took actual discipline: going to customers after shipping. Not before (we did that for discovery), not after the launch metrics look good (we did that for validation). Going to them to understand failure.

The feature that 247 customers requested saved our next two quarters of roadmapping by teaching us one thing. Requests are not requirements. Behavior is. For the framework that catches this earlier, see Your First OST and the weekly discovery playbook.

By killing the ghost feature, we learned to read what customers were actually saying underneath the requests. And that's worth one engineer's quarter, every time.