Your customers are asking for the wrong thing — and you're building it anyway

The most dangerous words in product management are customers keep asking for this. Because what customers ask for and what they actually need are almost never the same thing.

Here's a scenario that plays out in product teams every day.

A handful of customers submit the same feature request. Sales starts echoing it on calls. It lands on the roadmap. Six months later the feature ships — and almost nobody uses it.

It's not that the customers were lying. It's that you asked the wrong question.

🛣️ The feature request trapLink to this section

When a customer asks for bulk export, the instinct is to build bulk export. Request received. Ticket written. Done.

But bulk export isn't a feature request. It's a symptom. What it's really saying is: there's something I need to do that your product isn't helping me with.

That's a retention problem — and shipping the export feature doesn't fix it. It just makes it easier to leave.

Customers are experts at describing their pain. They are not experts at designing your product.

🎯 Start with the right questionsLink to this section

Before you write a single line of spec, you need to understand what's actually happening. That starts with asking better questions.

• Why are you exporting all of this data? What process is happening outside the product after you export it? Where does this fit in your workflow — is this a daily task, a monthly report, a one-time migration?
• Is this a data problem — incomplete, inaccurate, hard to access? Is there a report that lives in two different places and never quite tells the full story? Are there other people on the team who need this data but don't have access to it?
• Is there a third-party tool this data is flowing into — and if so, why isn't that integration already built? Where is the data going, and where is it coming from?

These questions reframe the conversation entirely. You're no longer scoping a feature. You're diagnosing a workflow gap.

📊 Then let the data confirm itLink to this section

Good research tells you what customers say. Usage data tells you what they actually do. You need both — especially when they contradict each other.

If customers are asking for bulk export, pull the data. How often are mass imports and exports happening today? Are there reports being built on this data that customers are reviewing externally? Is data being lost or dropped somewhere in the middle of a workflow?

Are customers able to get their questions answered inside the product — or are they hitting a wall and going elsewhere? Are the same personas showing up repeatedly in the export logs? Are there usage patterns that point to a broader workflow the product was never designed to support?

When the qualitative and quantitative line up, you have conviction. When they diverge, you have your next discovery question.

🔍 Prioritize the problem, not the requestLink to this section

Once you understand the real problem, the prioritization question changes too.

Is this a one-off for a single customer — or does the pattern show up across your base? Are there several different complaints that are all symptoms of the same underlying gap? How much time, effort, and cost could you eliminate for customers by solving this properly?

And then the bigger questions: Is this a workflow that opens up an entirely new persona you haven't been serving? Is there a business line here you haven't built yet? What's the market potential if you solve the whole problem instead of the surface request?

A bulk export request answered well might lead you to a native integration that eliminates churn, unlocks a new buyer, and expands the product into a category you weren't competing in before.

The feature request is the door. The job behind it is the room. Most teams never walk through.

✅ What this looks like in practiceLink to this section

The teams that consistently build products people love share one habit: they treat every request as the beginning of a discovery process, not the end of one.

They ask why before they ask how. They match what customers say to what the data shows. They look for the pattern across customers before they size the solution. And they build to the job — not the feature — which means the solution is more complete, more sticky, and more defensible.

Better questions lead to better data. Better data leads to better decisions. Better decisions lead to products that retain customers, expand revenue, and solve problems people actually have.

It starts with not taking the request at face value.