Some features don’t make money. They make a statement. Removing them makes the opposite one.
A bank recently switched off its open banking account aggregation feature that pulled a customer’s accounts from other banks into a single view. They were among the first to offer it. Now it’s gone.
I don’t want to second guess their call. They will have had their reasons, and from the outside you never see all of them. But their move triggered the harder, more general question underneath it, the one every product owner faces eventually: when do you remove something you’ve already built?
The case for removal usually writes itself. The feature has low adoption. It doesn’t make money directly. It costs something to maintain, a little engineering time, a little support load, a line in a security review that someone has to keep signing off. The money you spent building it is gone either way, so you tell yourself not to honour a sunk cost. You check the handful of people who use it, find the number small, and the spreadsheet returns its verdict. Cut it.
On those terms, the decision looks obvious. But is it?
Every feature does two jobs. The first you can measure, or at least see clearly: the revenue it brings in, the time it saves a customer, the cost it takes out of an operation, the experience it improves, the support load it prevents. The second you usually can’t measure: what it says about you. The first job is the one that shows up in the removal decision. The second is invisible to the analysis, so it carries no weight, so it loses by default.
Some features were never a revenue line. Nobody signed up because of them. What they do is signal something. They say this company is looking forward, it’s confident, it backs where things are heading rather than defending where it has been. Shipping a feature like that is a statement. Removing it is also a statement. Just the opposite one.
That’s the trap with signal features. They’re often cheap to run and expensive to remove, because the removal is louder than the feature ever was. The day you shipped it, most people didn’t notice. The day you kill it, everyone who cared finds out at once. And the people who cared tend to be the forward-leaning customers you most wanted to keep, the ones who chose you partly because you seemed to be going somewhere.
So the real checklist is longer than sunk cost, adoption, and satisfaction. Before you remove something, add three questions. What does keeping this say about us, and what does removing it say. Who is actually watching this particular feature, and are they people we can afford to disappoint. And is there a cheaper version that keeps the signal alive, a smaller, lower-maintenance way to stand for the same thing.
None of this means you never remove a feature. Sometimes the signal isn’t worth its cost. Sometimes it was the wrong signal to begin with. And sometimes there’s a better way to make the same point, a version that delivers more than a gesture and earns its keep on the measurable job too. A feature can be the right instinct in a form that has earned its retirement. You’ll still remove features. Just remove them for the real reasons, and count the signal as one of them.
You can’t put a number on the signal, which is the whole reason it gets ignored. So instead of measuring it, make yourself say it. Before you remove a feature, write the line you’d publish: we’re taking this out, and here’s why. Then read it back the way a customer would hear it. If it sounds like you’re moving forward, the signal is fine and the only real cost was the maintenance. If it sounds like you’re quietly backing away from something you used to lead on, that’s the cost the spreadsheet left out. The spreadsheet won’t show it to you. The market will.
Further reading
- Subtract: The Untapped Science of Less by Leidy Klotz. On why people instinctively add and overlook taking away, even when removing is the better move.
Leave a comment