The Feature Your Users Never Asked For

Early in my product career I kept a spreadsheet of every feature request that came in. Customer calls, support tickets, sales feedback, NPS comments - all of it, logged and tallied. The logic was simple: if enough people ask for the same thing, that’s what you build next. Democratic product management. The people have spoken.

It took me a couple of years to realize that this approach, while not wrong exactly, misses the things that actually matter most.

Users describe solutions, not problems

When someone says “I wish I could export this as a CSV,” they’re not asking for CSV export. They’re telling you that they need to get data out of your product and into somewhere else, and CSV is the only mechanism they can picture. Maybe the real answer is CSV export. But maybe it’s a direct integration with the tool they’re exporting to. Or maybe it’s a dashboard that eliminates the need to export anything at all.

The request is a symptom. The problem is underneath it.

This sounds like Product Management 101, and it is. Everyone knows you’re supposed to ask “why” five times and find the root cause. But knowing it and doing it are different things, especially when you have a backlog full of specific, concrete requests and a team that wants to know what to build next. A CSV export ticket is actionable. “Rethink how users get value from their data” is not. One ships in a sprint. The other is a quarter-long investigation that might not lead anywhere.

So the specific requests win, over and over, and the deeper problems stay buried.

The pattern I keep seeing

The features that moved the needle most in my career were almost never on the request list. They came from watching people use the product and noticing something they’d stopped complaining about - not because it was fixed, but because they’d given up.

There’s a category of friction that users just absorb. They route around it. They build workarounds. They accept it as “how the product works” and stop thinking about whether it could be different. These are the most valuable problems to solve because the user has already proven they care enough to stick around despite the friction. Remove it and the effect is immediate.

But nobody writes a ticket for a workaround they’ve internalized. You only find these by watching.

I’ve seen this in every product I’ve worked on. The thing that increased engagement wasn’t the feature the sales team was pushing for. It was removing three steps from a flow that everyone had learned to tolerate. The thing that reduced churn wasn’t the new dashboard the top accounts requested. It was fixing the notification timing so people actually came back before they forgot about the product.

Small, unsexy, never requested. But disproportionately impactful.

Why feedback boards mislead

Feature request boards have a structural bias: they over-index on vocal power users and under-index on everyone else. The people who fill out feedback forms, join beta programs, and get on calls with your product team are not representative of your user base. They’re the most engaged, most opinionated, most invested segment. Building for them feels responsive and data-driven, but it’s actually building for a loud minority.

The silent majority doesn’t request features. They either use the product as-is or they leave. You don’t hear from them because they’ve already made their decision. The feedback board can’t capture the experience of someone who signed up, hit a wall in the first five minutes, and closed the tab.

This is why I’ve learned to weight observation over feedback. What people do in the product tells you more than what they say about the product. Where do they hesitate? Where do they click something, wait, and click it again? Where do they start a flow and abandon it? These behaviors are feedback - they’re just not labeled as such.

The hard part is conviction

Here’s the thing nobody tells you about building features users didn’t ask for: you have to be right, and you won’t know if you’re right until after you’ve built it.

When you build a requested feature, the worst case is that it doesn’t move metrics much but users are satisfied because they got what they asked for. When you build something nobody asked for, the worst case is that it doesn’t move metrics and everyone wonders why you wasted a sprint on it instead of building the thing they wanted.

The downside is asymmetric. Requested features have social cover. Unrequested features require conviction - you have to believe in your read of the problem strongly enough to spend resources on it despite nobody asking for it. And you have to be able to explain why, clearly, before you have results to point to.

This is where most product teams default back to the request list. It’s safer. It’s defensible. “We built what customers asked for” is an easy story to tell, even if the impact is modest. “We built something nobody asked for because we believed it would matter” is a much harder story to tell, especially if it doesn’t work out.

When the request is exactly right

I don’t want to overstate this. Sometimes users ask for exactly the right thing. Sometimes CSV export is genuinely what they need. Sometimes the feature they’re requesting is obvious and correct, and the product team’s job is simply to build it well and ship it fast.

The skill isn’t ignoring user requests. It’s knowing which requests to take at face value and which ones to dig beneath. A few signals I’ve learned to watch for:

Take it at face value when the request is about a concrete workflow gap - something they literally cannot do today that they need to do. These are usually straightforward and high-value.

Dig deeper when the request is about making something “easier” or “better.” These words are doing a lot of work. What does easier mean, specifically? Better compared to what? The request is pointing at a problem but the solution they’re proposing might not be the best one.

Pay attention when the same request comes from multiple unrelated users. One person asking for something is an anecdote. Three people who don’t know each other, using the product in different ways, all hitting the same wall? That’s a pattern. The more independent the sources, the more likely you’ve found something real.

The thing I come back to

After fifteen years of building products, the lesson I keep relearning is this: the most important problems are the ones nobody is telling you about. Not because they’re hidden or mysterious, but because people adapt. They find workarounds. They lower their expectations. They stop noticing the friction.

Your job isn’t to build what’s requested. It’s to see what’s tolerated. The gap between those two things is where the best product work lives.