You Said You Needed It. So Why Is Nobody Using It?

Bottom Line

The feature requested most forcefully is often the one used least after launch. Across 18 years and dozens of products, that pattern has held almost without exception. So before I build anything, I ask one thing: "Are you actually going to use this?"

The Loudest Feature in the Room

When you take on outsourced work, you sit through requirements meetings. The founder, or the product person, sketches screens and stacks features one by one. "We need a filter here, and favorites, and a separate notification settings page. Oh, and dark mode."

I write it all down. I price it. Hours come out. Money comes out. I build it. We ship.

A month later, I check the logs. That filter? Never clicked. Favorites? A tiny fraction of users tried it once. The settings page? Almost nobody even navigates to it. The features that were loudest in the meeting room are the quietest in the data.

This isn't a once-in-a-while thing. It happens every time.

The Question I Wanted to Ask Out Loud

Honestly, I've often thought: "You're not going to use this. So why did you ask me to build it?"

But after 18 years, I understand. The client wasn't lying. In that moment, they genuinely believed it was necessary. The problem is that the belief comes from anxiety, not from user behavior.

The real source of the request was almost always one of these three:

• "Just in case" — in case we need it later. But later rarely comes.
• "Our competitor has it" — because not having what others have feels risky. But that competitor didn't validate the feature with data either.
• "An investor might ask" — because the demo might look thin. But investors look at whether users actually use the thing, not at the feature count.

All three are reasonable feelings. And all three have nothing to do with why a user would press that button.

An Unused Feature Isn't Free

It's tempting to think, "Just build it — if it's not used, no harm done." But an unused feature doesn't stop costing you the moment it ships.

It takes time to build, and that time goes straight onto the estimate (with my pricing, work hours are the cost). And it doesn't end there. The feature takes up screen space, makes other features harder to find, and becomes baggage you have to test with every future update. There's even the cost of someone opening the code six months later and pausing to ask, "Wait, why is this here?"

In an MVP, a feature is closer to a liability than an asset. Borrow only as much as you're confident you can pay back.

So I Ask Before I Build

When I get a requirements list, I don't just transcribe it. For each feature, I ask one thing back:

"If we don't see users touching this in the first week after launch, can we drop it?"

That single question clears up a lot. Any feature that gets a "Sure, we can look at that later" is cut from the MVP. Only the features that get "No — the service doesn't work without it" stay. The latter is your real MVP.

A good outsourced developer doesn't say "I'll build all of it." They have to be able to say, "This one — let's not build it right now." That one sentence saves the client money and time, and spares them the complexity they'd face after launch.

Of course, a cut feature might genuinely become necessary later. Then we build it. When the data says "now we need it," that's not anxiety — it's evidence. Features built that way don't die.

Closing

"You said you needed it — so why is nobody using it?" I no longer use that line to blame clients. It's a question we should check together before building. Nobody wants to spend money on a feature no one will use.

If you're preparing an MVP, bring your feature list. We'll go through it together and honestly split it into "build now" and "can wait." Building less, shipping faster, and spending money on what actually gets used — that's my job.